Jak to zwykło się mawiać w świecie IT: ludzie dzielą się na te osobniki, które robią backup i te, co backup robić będą. Jakiś czas temu pochyliłem się nad zagadnieniem czy smartfon z Androidem bez Google Play Services ma sens. Poruszyłem tam problem tworzenia kopi zapasowej danych użytkownika zgromadzonych w telefonie. W tym podlinkowanym artykule zostało przestawione jak przy pomocy TWRP dokonać pełnego backupu całego systemu urządzenia i o ile pod względem technicznym takie podejście było jak najbardziej w pełni do zaakceptowania, to jednak to rozwiązanie miało dość istotną wadę, tj. na czas backup'u trzeba było wyłączyć smartfon. Parę dni temu natrafiłem na narzędzia OAndBackupX, które jest w stanie zrobić kopię zapasową wszystkich zainstalowanych w Androidzie aplikacji (oraz ich ustawień), wliczając w to nawet appki systemowe. OAndBackupX jest o tyle lepszym rozwiązaniem w stosunku do TWRP, że można przy jego pomocy robić kopię danych pojedynczych aplikacji, a nie od razu całego ROM'u, co nie tylko jest czasochłonne ale również zjada sporo miejsca na dysku komputera, czy gdzie ten backup zamierzamy przechowywać. Niestety OAndBackupX wymaga uprawnień root, zatem na stock'owym ROM'ie producenta naszego telefonu nie damy rady z tego narzędzia skorzystać. Jeśli jednak mamy alternatywny ROM na bazie AOSP/LineageOS, to przydałoby się rzucić okiem na ten kawałek oprogramowania, bo zdaje się ono być wielce użyteczne, zwłaszcza w przypadku osób mojego pokroju, czyli linux'iarzy, którzy o backup swoich danych chcą zatroszczyć się tylko i wyłącznie we własnym zakresie, zaprzęgając do pracy choćby Syncthing.

Raczej już nikogo nie dziwią różne moduły elektroniczne implementowane w smartfonach pokroju żyroskopu, akcelerometru, magnetometru czy też i innych czujników realizujących pewne określone funkcje. Te wszystkie rzeczy potocznie zwykło nazywać się sensorami i na dobrą sprawę zdążyły się one zadomowić na dobre w tych naszych telefonach i to do tego stopnia, że nawet sobie nie zdajemy sprawy, że w ogóle one istnieją i non stop działają w tle. Przekopując ostatnio ustawienia Androida, natknąłem się w opcjach deweloperskich na dość enigmatycznie brzmiącą opcję Sensors Off , która była ukryta pod Quick settings developer tiles . Zaznaczenie tej opcji sprawiło, że do dyspozycji użytkownika został oddany dodatkowy kafelek (dostępny z poziomu górnej belki), którego zadaniem jest sterowanie dostępem aplikacji do sensorów smartfona (nie tylko tych wymienionych wyżej ale też do kamery mikrofonu, czy nawet GPS). Postanowiłem się trochę pobawić tym mechanizmem i zobaczyć czy można z niego zrobić jakieś użyteczne narzędzie w kontekście ochrony prywatności.

Wiele osób nie pozostawia suchej nitki na mechanizmie geolokalizacji zaszytym w smartfonach z Androidem na pokładzie. No i faktycznie w sporej części przypadków zastrzeżenia jakie są kierowane pod adresem lokalizacji/GPS w kwestii permanentnego śledzenia nas przez Google nie są przesadzone. Niektórzy spierają się, że wystarczy włączyć tryb samolotowy (Airplane Mode) w telefonie i nasza pozycja przestaje być rejestrowana w czasie rzeczywistym ale nie jest to prawdą. Jakiś czas temu świat obiegła informacja, że Android rejestruje dane geolokalizacji nawet, gdy tryb samolotowy jest włączony, a telefon nie ma włożonych kart SIM i to przy jednoczesnym wyłączeniu WiFi i BT. Jak to do końca jest z tą lokalizacją i czy faktycznie nie da się jej wyłączyć w Androidzie? A może powinniśmy pójść w drugą stronę i zamiast starać się wyłączać lokalizację, to spróbować oszukać system przez jej pozorowanie? Taki zabieg jest możliwy ale wymagana jest zewnętrzna aplikacja do pozorowania lokalizacji, np. Fake Traveler, którą trzeba określić w ustawieniach deweloperskich Androida. Czy ten zabieg wpłynie pozytywnie na lokalizację w kontekście naszej prywatności? Czy może lepiej jest jednak zostawić telefon w domu i pójść na niejawne spotkanie bez tego urządzenia?

Czy przytrafiła może wam się taka sytuacja, w której to ktoś dzwonił do was z niewiadomego numeru i przy tym nie był to nikt, kto by zasługiwał na jakąś większą uwagę z waszej strony? Zwykle, gdy mam do czynienia z kimś takim, to nawet nie odbieram telefonu. Niemniej jednak, najwyraźniej jeden z moich numerów ostatnio stał się celem ataku jakiegoś spamera z bliżej nieokreślonego call center i ten czteroliterowy osobnik wydzwania do mnie od kilku dni średnio co 20 minut i to z wielu różnych numerów. Do tej pory spamerzy w zasadzie omijali mnie szerokim łukiem ale zachowanie tej dość nieuprzejmej osoby sprawiło, że postanowiłem opracować jakieś rozwiązanie na wypadek, gdyby takich osobników z gatunku "brakującego ogniwa ewolucji Homo sapiens" było więcej. Po chwili wertowania netu udało mi się znaleźć appkę, co się zwie Yet Another Call Blocker (YACB), która w zasadzie jest tym, czego standardowo brakuje w każdym smartfonie z Androidem na pokładzie, tj. dość zaawansowanego filtra rozmów przychodzących realizowanych w przestarzałej już technologi GSM, czyli w zwykłych rozmowach telefonicznych na komórkę. Jako, że ten YACB jest bardzo ciekawym kawałkiem oprogramowania i do tego w pełni OpenSource (dostępnym w repozytorium F-Droid), to postanowiłem napisać o nim kilka słów, bo jest to wręcz nieocenione narzędzie w walce z wszelkim syfem pokroju różnych spamerów z call center.

Ostatnio na polskim forum linux mint pojawił się wątek, w którym jeden z użytkowników miał problem z ogarnięciem podświetlania klawiatury. Chodzi generalnie o start komputera z włączonym backlight'em klawiatury, przez co trzeba to podświetlenie manualnie wyłączać za każdym razem po uruchomieniu się systemu. W przypadku mojego laptopa Lenovo ThinkPad T430, taka sytuacja co prawda nie występuje i system uruchamia się naturalnie ze zgaszoną klawiaturą. Niemniej jednak, zainteresował mnie ten problem tyle, że w drugą stronę -- chodzi o możliwość startu systemu z włączonym podświetleniem klawiatury, bo ustawienia BIOS/EFI/UEFI mojego laptopa tego aspektu pracy komputera nie są w stanie w żaden sposób skonfigurować. Okazało się, że zaimplementowanie tego typu funkcjonalności nie jest jakoś specjalnie trudne i można bez większego trudu ogarnąć backlight klawiatury przy pomocy prostej reguły dla UDEV'a.

Odblokowanie bootloader'a w smartfonie Xiaomi Redmi 9 (Galahad/Lancelot) mamy już z głowy. Podobnie sprawa wygląda z wgrywaniem na partycję recovery obrazu TWRP i uzyskiwaniem praw administratora systemu root za sprawą Magisk'a. Te dwa kluczowe procesy otworzyły nam drogę do nieco bardziej zaawansowanych prac jeśli chodzi o konfigurację samego urządzenia. W tym artykule nie będziemy się jeszcze bawić we wgrywanie alternatywnych ROM'ów na bazie AOSP/LineageOS ale za to zainteresujemy się nieco bardziej procesem ładowania samej baterii w takim telefonie. Chodzi generalnie o fakt przedłużenia żywotności baterii smartfona za sprawą limitowania maksymalnej wartości, do jakiej można taką baterię podładować podłączając telefon czy to do portu USB komputera, czy też do pełnowymiarowej ładowarki. Taki stopień konfiguracji można osiągnąć zaprzęgając do pracy zaawansowany kontroler ładowania (Advanced Charging Controller, ACC), który manipuluje niskopoziomowymi ustawieniami kernela linux. W standardowym Androidzie tego typu funkcjonalności nie uświadczymy, przez co bateria zużywa się parokrotnie szybciej niż powinna, co przekłada się na wymianę urządzenia na nowe po niecałym roku czy dwóch jego użytkowania. Jeśli nie uśmiecha nam się wydawać hajsu co roku na nowy telefon tylko dlatego, że nie można w nim wymienić baterii, to powinniśmy rozważyć rozwiązanie jakie nam daje ACC.

Parę dni temu udało mi się odblokować bootloader w moim smartfonie Xiaomi Redmi 9 (galahad/lancelot). Nie licząc błędnego URI przy logowaniu na konto Mi wewnątrz appki XiaoMiTool, nie było zbytnio problemów z tym procesem. Takie odblokowanie bootloader'a w telefonie w zasadzie nic nam samo z siebie nie daje, no może poza ściągnięciem z niego zabezpieczeń, co ułatwia dostanie się syfu na Androida, no i też ułatwia złodziejom robotę, bo gdy takie odblokowane urządzenie wpadnie w ich łapki, to mamy praktycznie pozamiatane. Niemniej jednak, odblokowany bootloader daje nam możliwość wgrania custom recovery, np. TWRP, co z kolei otwiera nam drogę do uzyskania praw administratora systemu root, np. za sprawą zainstalowania Magisk'a. Mając dostęp do root, będziemy mogli takim urządzeniem dowolnie zarządzać. Naturalnie, TWRP daje nam też możliwość wgrania alternatywnych ROM'ów na bazie AOSP/LineageOS ale w tym artykule skupimy się jedynie na wrzuceniu TWRP recovery na tego Xiaomi Redmi 9 i ukorzenimy jego Androida przy pomocy wspomnianej już aplikacji Magisk.

Jakiś czas temu wpadł w moje łapki smartfon Xiaomi Redmi 9 (galahad albo lancelot, bo w różnych częściach systemu jest to inaczej określone), który miał preinstalowanego Androida 10 oraz MIUI 11. Przez parę miesięcy używania telefonu, dostał on dwa albo trzy większe update całego ROM'u, wliczając w to aktualizację MIUI do 12.0.1 ze stanem zabezpieczeń na dzień 2021-01-05. Zatem ostatnia aktualizacja zabezpieczeń tego telefonu miała miejsce zaraz na początku Stycznia. Od tego czasu cisza. Niby w przypadku tego modelu telefonu aktualizacje miały być wydawane co trzy miesiące do roku 2023 ale najwyraźniej coś jest nie tak i urządzenie od ponad pół roku nie dostało żadnych aktualizacji. Niby pod tym linkiem można wyczytać informację, że planowana jest aktualizacja do Androida 11 ale prawdę mówiąc jestem nieco zawiedziony opieszałością Xiaomi. Tak się złożyło, że przez przypadek trafiłem w to miejsce na forum XDA, gdzie z kolei znalazłem m.in. ten wątek. Zatem alternatywne ROM'y na mój smartfon istnieją i tego faktu nie byłem świadomy, bo w zeszłym roku jeszcze nic nie szło znaleźć. Postanowiłem zatem odblokować bootloader w swoim Xiaomi Redmi 9 i spróbować wgrać na niego TWRP i jeden (a może nawet kilka) przykładowy ROM na bazie AOSP/LineageOS. Proces odblokowania bootloader'a w urządzeniach Xiaomi nie wymaga zbytnio wysiłku i da się go przeprowadzić w całości pod linux korzystając czy to z XiaoMiTool, czy też przy pomocy maszyn wirtualnych na bazie QEMU/KVM. Ten proces nie do końca jest dla każdego taki oczywisty, dlatego postanowiłem go dokładnie opisać.

Z okazji wypuszczenia parę dni temu nowego Debiana, przeglądałem sobie notki dla wydania stabilnego pod kątem aktualizacji z buster (10) -> bullseye (11). Niby ja i tak korzystam cały czas z unstable/experimental i zwykle jestem na bieżąco ze zmianami wprowadzanymi w tej dystrybucji linux'a ale też zawsze coś może umknąć uwadze z perspektywy wielu miesięcy czy nawet kilku lat (a dokładnie 25 miesięcy). Sporo z tych rzeczy, które w tych podlinkowanych notatkach wyczytałem, miałem już załatwione wcześniej ale zapomniałem rozprawić się z repozytoriami APT. Konkretnie chodzi tutaj o odejście od apt-key , czyli narzędzia, które w Debianie używane jest do dodawania kluczy GPG do systemowego keyring'a APT. Te klucze zwykle wykorzystywane są do weryfikacji sygnatur złożonych pod zewnętrznymi repozytoriami, a że ja mam ich sporo, to musiałem się nieco zagłębić w temat i ustalić w jaki sposób od następnego wydania Debiana (bookworm/12) będzie się te klucze GPG od takich repozytoriów ogarniać. No i właśnie o tym będzie ten poniższy kawałek artykułu.

Zapewne każdy użytkownik linux'a tworzył na dysku HDD/SSD partycje sformatowane systemem plików EXT4. Prawdopodobnie też zastanawiało nas pytanie odnośnie ilości zajmowanego miejsca przez strukturę samego systemu plików, zwłaszcza w przypadku dysków o sporych rozmiarach (setki GiB, czy nawet kilka TiB). Jako, że musiałem ostatnio zmigrować kolekcję filmów ze strych dysków na jeden większy, który miał zostać podłączony pod Raspberry Pi z działającym Kodi na bazie LibreELEC, to przy okazji postanowiłem ten dysk sformatować w taki sposób, w jaki powinno się do tego zadania podchodzić wiedząc, że ma się do czynienia z dużym dyskiem, na którym będą przechowywane głównie duże pliki. Celem tego artykułu jest pokazanie jakie błędy przy tworzeniu systemu plików EXT4 można popełnić przez posiadanie niezbyt wystarczającej wiedzy z jego zakresu, oraz jak te błędy wyeliminować przed rozpoczęciem korzystania z tak nie do końca poprawnie przygotowanego do pracy dysku twardego