Parę dni temu na mój telefon Xiaomi Redmi 9 (lancelot/galahad/shiva/lava) została wypuszczona aktualizacja ROM'u crDroid, który bazuje na AOSP/LineageOS. Ten update nie tylko miał uwzględnione najnowsze poprawki bezpieczeństwa ale również podbijał wersję Androida z 11 na 12. Problem w tym, że TWRP/SHRP recovery ma problemy z obsługą sposobu szyfrowania partycji /data/ , który najwyraźniej uległ przeobrażeniu w Androidzie 12. Efektem braku wsparcia dla szyfrowania w TWRP/SHRP jest naturalnie brak możliwości wgrywania danych na partycję /data/ . Niestety niesie to za sobą przykre konsekwencje w postaci uniemożliwienia użytkownikowi przeprowadzenia procesu patch'owania obrazu partycji /boot/ z poziomu trybu recovery, czego efektem jest brak możliwości zainstalowania Magisk'a w systemie smartfona. Bez Magisk'a nie damy rady ukorzenić systemu, tj. uzyskać w nim praw administratora root. Na szczęście nie wszystko stracone. Magisk'a można zainstalować w telefonie ręcznie przy pomocy ADB oraz trybu bootloader'a (fastboot) eliminując tym samym potrzebę przełączenia się w tryb recovery. Niniejszy artykuł ma na celu pokazanie jak zainstalować Magisk'a bez odwoływania się do trybu TWRP/SHRP recovery.

Gdy zapytamy użytkowników smartfonów z Androidem o to, czy taki sprzęt jest w stanie pracować z pominięciem układu baterii, zapewne wiele z tych osób odpowiedziałoby, że nie ma takiej opcji, bo przecież w tych telefonach od lat baterii się już nie da wyciągnąć. Nawet w tych starszych modelach, po wyjęciu baterii i podłączeniu ładowarki, system w takim urządzeniu nie chciał się uruchomić. Okazuje się jednak, że nie trzeba wyjmować akumulatora ze smartfona, by to urządzenie było w stanie działać z pominięciem układu baterii, tj. w tzw. trybie bezczynności baterii (battery IDLE mode), coś na wzór rozwiązania stosowanego od dekad w laptopach. Niemniej jednak, takiej funkcjonalności zwykle nie uświadczymy w stock'owych Androidach. Możemy się jednak o nią postarać ale do tego celu niezbędne będzie nam uzyskanie praw administratora systemu root, choć lepiej wgrać sobie na smartfon ROM na bazie AOSP/LineageOS. Bez ukorzenionego Androida nie mamy nawet co podchodzić do implementacji tego mechanizmu. Dodatkowo będzie nam potrzebny zaawansowany kontroler ładowania baterii ACC (w postaci modułu do Magisk'a) i opcjonalnie też graficzna nakładka ACCA (do pobrania z F-Droid). W poniższym artykule postaramy się odpowiedzieć na pytanie czy takie rozwiązanie na bazie IDLE mode w przypadku baterii w smartfonach z Androidem ma w ogóle sens i czy może nam się ewentualnie do czegoś przydać.

Właściciele smartfonów mają zwykle podpisane umowy ze swoimi operatorami GSM na świadczenie usług telefonicznych. Pakiety rozmów oferowane przez tych operatorów już od dłuższego czasu są nielimitowane, co z kolei zachęca abonentów do głosowego komunikowania się przy pomocy tych małych lecz przy tym bardzo zaawansowanych technologicznie komputerów. Nie ma obecnie chyba sprawy, której nie można załatwić telefonicznie, a że coraz dłużej wisimy na słuchawce, to też sporo informacji z takich rozmów nam bezpowrotnie ucieka, np. imię i nazwisko osoby, z którą rozmawialiśmy, nie wspominając o całej masie innych rzeczy, które mogą paść podczas choćby negocjowania/przedłużania jakiegoś kontraktu. Gdy w późniejszym czasie zorientujemy się, że coś jest nie tak, to możemy mieć poważny problem z udowodnieniem swoich racji, np. że zostaliśmy celowo wprowadzeni w błąd. Gdybyśmy dysponowali nagraniem z takiej rozmowy, to bez problemu można by się do niego odnieść i nikt by nie miał wątpliwości po czyjej stronie byłaby racja. Niemniej jednak, smartfony z Androidem mają ogromny problem z nagrywaniem dźwięku audio podczas tego typu konwersacji, czego efektem jest brak możliwości niezależnego rejestrowania rozmów telefonicznych. Jeśli jednak posiadamy ukorzenionego Androida (dostęp do praw administratora root), to możemy te obostrzenia obejść zaprzęgając do pracy aplikację Call Recorder.

Przeglądając ostatnio opcje deweloperskie w swoim telefonie z Androidem 11, wpadła mi w oczy pozycja WebView implementation . Nie ukrywam, że trochę mnie ona zainteresowała i zacząłem się zastanawiać czym tak naprawdę jest ten cały WebView. Mój smartfon działa aktualnie pod kontrolą crDroid (ROM na bazie AOSP/LineageOS) i nie jest on sprzęgnięty z usługami od Google (brak jakichkolwiek GAPPS'ów). Dlatego też w tym przypadku w implementacji WebView widnieje w zasadzie tylko jedna opcja, tj. Android System WebView. W przypadku stock'owych ROM'ów producentów telefonów będziemy mieli zaś do czynienia z Google System WebView. Jakby nie patrzeć, zarówno Android/AOSP System WebView, jak i Google System WebView pochodzą od Google, który niezbyt troszczy się o naszą prywatność. W mojej głowie pojawiło się zatem pytanie na temat tego czym te dwie implementacje się od siebie różnią, no i naturalnie też czy są jakieś alternatywne implementacje WebView, z których można by skorzystać zastępując te domyślnie preinstalowane?

Przeglądając jakiś czas temu oficjalną stronę Xiaomi w poszukiwaniu nowszych wersji oficjalnego ROM'u na mój smartfon Redmi 9, zauważyłem, że są tam dostępne instrukcje na temat wgrania takiego oprogramowania za pomocą trybu fastboot. Trochę się zdziwiłem, bo przecie ROM'y dostarczane są w paczkach .zip , przez co nie są one przeznaczone do wgrywania w tym trybie. Tak czy inaczej, zgodnie z informacją, która widnieje na tamtej stronie, te linki do obrazów fastboot jeszcze nie zostały wypuszczone, przynajmniej oficjalnie. Nieoficjalnie zaś można je pobrać ze strony xiaomifirmwareupdater.com. To, co się rzuca od razu w oczy, to rozmiar takiego pliku, bo standardowo pliki z ROM'em MIUI ważą około 2,2 GiB. ROM'y fastboot mają rozmiar około 4,5 GiB. Kolejna sprawa, to rozszerzenie samego pliku. W przypadku standardowego ROM'u mamy .zip , a ROM'y fastboot mają już rozszerzenie .tar.gz lub .tgz . Nie mogłem przejść obojętnie obok tej zagadki i postanowiłem sprawdzić, co taka paczka w sobie zawiera i do czego ewentualnie ona może nam się przydać w kontekście alternatywnego oprogramowania wrzucanego na telefon.

Te bardziej szanujące się marki produkujące smartfony zwykle zapewniają wsparcie dla swoich urządzeń przez co najmniej dwa lata (a czasem nawet i dłużej) od momentu ich wypuszczenia na rynek. Po wgraniu sobie alternatywnego ROM'u na nasz telefon, oprogramowanie w nim może być aktualizowane przez opiekuna czy dewelopera takiego ROM'u znacznie dłużej niż producent przewidział. W ten sposób nie musimy wydawać pieniążków na nowy sprzęt, oczywiście zakładając, że mu nic nie dolega, np. pod względem wydajności, czy też ewentualnie nie zużył on się nam jakoś bardziej podczas eksploatacji. Jedną rzeczą, o której posiadacze smartfonów z Androidem zapominają po wgraniu custom ROM'ów na bazie AOSP/LineageOS, to fakt, że o ile ROM faktycznie dostaje aktualizacje czy to bezpieczeństwa, czy też upgrade do nowszej wersji Androida, o tyle sam firmware zwykle pozostaje nietknięty. W przypadku mojego modelu smartfona Redmi 9, Xiaomi od czasu do czasu wypuszcza aktualizacje firmware do tego urządzenia i przydałoby się ten firmware co jakiś czas zaktualizować. Na szczęście nie trzeba w tym celu powracać do stock'owego oprogramowania, a cały proces możemy przeprowadzić z poziomu dowolnej dystrybucji linux'a.

Przyszła pora pozbyć się w końcu tego stock'owego oprogramowania, które zostało wgrane na mojego smartfona Xiaomi Redmi 9 (lancelot/galahad) przez producenta tego urządzenia. Przez ostatnich parę tygodni testowałem różne wersje ROM'ów na bazie AOSP/LineageOS, z których bardziej użyteczne okazały się PixelPlusUI, Pixel Extended oraz crDroid Anadroid. Niestety nikt jeszcze nie opracował LineageOS na ten telefon, więc pozostaje w zasadzie wgranie jednej z tych trzech powyższych pozycji, jako że Xiaomi Redmi 9 jest oficjalnie przez te ROM'y wspierany. Obecnie Pixel Extended ma jednak problemy z hostowaniem swoich plików i od paru miesięcy nie miał praktycznie żadnej aktualizacji, przez co wybór został ograniczony do dwóch pozostałych ROM'ów. Powodem, dla którego zdecydowałem się wgrać crDroid Android, jest fakt, że nie ma on zintegrowanych aplikacji od Google (GAPPS). Oczywiście można po instalacji samego ROM'u wgrać także Open GAPPS ale naturalnie nie jest to wymagane, przez co można sobie skonfigurować cały telefon według własnego uznania wykorzystując jako bazę początkową microG. W tym artykule zostanie przedstawiony sposób wgrania ROM'u crDroid Android na smartfon, tak by czasem nie uszkodzić tego urządzenia.

Jeśli mamy wgranego w miarę nowego Androida (9+) na naszego smartfona i korzystamy aktywnie z tego urządzenia, to zapewne zdążyliśmy się już przyzwyczaić, że co kilka dni musimy wpisywać ręcznie hasło do blokady ekranu i to nawet pomimo aktywnej biometrii w ustawieniach systemu. Co ciekawe, w stock'owych ROM'ach producentów telefonów (nawet w moim Xiaomi Redmi 9), nie ma żadnej opcji, która byłaby w stanie skonfigurować czas, po którym taki monit z hasłem ma wyskakiwać. Przyznam, że trochę mnie ten ficzer denerwował ale nie mogłem z nim w zasadzie nic zrobić i trzeba było nauczyć się go tolerować. Do niedawna nawet nie wiedziałem, że takie pytanie użytkownika o hasło bierze się z faktu przejścia telefonu w jeden ze jego trybów pracy, tj. tryb lockdown, w który telefon jest przełączany automatycznie zwykle co 72 godziny (3 dni). Ludzie mówią, że ten tryb ma chronić użytkownika smartfona na wypadek utraty urządzenia. Z racji, że aktualnie wgrałem sobie custom ROM na bazie AOSP/LineageOS, to postanowiłem sprawdzić czy jakieś opcje konfiguracji tego trybu są w nim dostępne. Przy okazji chciałem nieco bardziej zapoznać się z tym mechanizmem lockdown'u i zweryfikować na ile może on być użyteczny.

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.

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.