Część użytkowników smartfonów z Androidem na pokładzie żyje w głębokim przekonaniu, że instalowanie aplikacji spoza sklepu Google Play nie jest zbyt rozważnym posunięciem. Nie chodzi tutaj tylko o szeroko rozumiane alternatywne źródła aplikacji, np. serwis apkmirror ale również o Yalp/Aurora Store czy też repozytoria F-Droid. Zdaniem tych osób pobieranie aplikacji z zewnętrznych źródeł może skompromitować bezpieczeństwo systemu oraz zagrozić naszej prywatności. No jakby nie patrzeć wgrywanie czegokolwiek bez zastanowienia się co tak naprawdę instalujemy w systemie nie jest zbyt mądre. Dlaczego zatem nie weryfikujemy aplikacji obecnych w oficjalnym sklepie Google? Co chwila przecież można usłyszeć w mediach o syfie, który udało się co prawda z tego sklepu usunąć ale też jakaś większa liczba użytkowników taką aplikację zdążyła już zainstalować i używała jej przez dłuższy lub krótszy okres czasu. Rozumowanie na zasadzie, że aplikacje ze sklepu Google Play są bezpieczne, bo są obecne w sklepie Google Play, daje nam jedynie fałszywe poczucie bezpieczeństwa, które jest gorsze od całkowitego braku bezpieczeństwa, bo w tym drugim przypadku człowiek przynajmniej jest świadom czyhających na niego niebezpieczeństw i włącza myślenie. Jak zatem odróżnić aplikacje, które są w stanie nam wyrządzić krzywdę od tych, które tego nie mają na celu i czy faktycznie pobieranie aplikacji na Androida z innego źródła niż oficjalny sklep Google Play jest takie niebezpieczne?

Jakiś czas temu natknąłem się na artykuł chwalący Google Play Services i sugerujący zarazem, że nasz smartfon bez tych usług (i appek zależnych od nich) na niewiele się zda człowiekowi. Nie jest to jednak do końca prawdą i postanowiłem pokazać na żywym przykładzie jak wygląda operowanie na telefonie z Androidem pozbawionym jakichkolwiek usług czy aplikacji własnościowych od Google. W rolach głównych wystąpi mój smartfon LG G4C, który jest już dość leciwy ale można na niego wgrać LineageOS (lub też inny ROM na bazie AOSP). Po wgraniu ROM'u, w telefonie znajduje się jedynie garstka podstawowych aplikacji (przeglądarka, galeria, itp), które po pierwsze są opensource, a po drugie można je bez problemu wyłączyć jeśli nie zamierzamy z nich korzystać. Z telefonu można dzwonić, przeglądać net (WiFi/LTE), robić zdjęcia i używać tego urządzenia do różnego rodzaju multimediów. W zasadzie czego oczekiwać więcej od telefonu? Niektórzy jednak chcieli by mieć możliwość używania, np. nawigacji. No i tu już zaczynają się schody, bo na takim w pełni otwartoźródłowym Androidzie, GPS nie zadziała OOTB i potrzebna nam jest jakaś alternatywa w postaci pośrednika między aplikacjami a GPS. Standardowo w Andkach tym zadaniem zajmują się właśnie te usługi Google. Jak więc zatem zmusić GPS do poprawnej pracy nie chcąc przy tym wgrywać sobie tego rozbudowanego w uprawnieniach szpiega od Google? Problemów naturalnie może być więcej, a to czy doświadczymy któregokolwiek z nich zależy głównie od odpowiedniej konfiguracji systemu. Niniejszy artykuł postara się zebrać wszystkie te niezbędne informacje mające na celu zaimplementowanie w naszym smartfonie otwartoźródłowej alternatywy dla Google Play Services w postaci microG.

Ostatnio próbowałem zaktualizować obraz TWRP recovery dla jednego z moich telefonów. Ja generalnie buduje te obrazy ze źródeł OMNI ROM, a tam jest dostępnych szereg gałęzi, np. 6.0, 7.1, 8.1 , etc, które naturalnie pasują do odpowiadających im wersji Androida. Do tej pory budowałem w oparciu o gałąź 7.1 ale po wydaniu polecenia repo sync , szereg aktualizacji w stosunku do repozytorium bootable/recovery zostało pobranych, w tym też i jedna trefna, która uwalała proces kompilacji. Ostatecznie udało się problem namierzyć i zlikwidować ale w międzyczasie próbowałem zbudować obraz TWRP recovery z gałęzi 8.1. Wygląda na to, że im nowszy Android, tym obrazy recovery rosną w objętość i 16M, które u mnie jest limitem, zostało przekroczone o jakieś 500K i to przy najbardziej okrojonej funkcjonalności trybu recovery. Czy istnieje jakieś rozwiązanie, które by umożliwiło zmniejszenie rozmiaru obrazu ramdisk-recovery.img , co przełożyłoby się również na wagę pliku recovery.img ? Tak, trzeba tylko zmienić rodzaj kompresji z domyślnego gzip na lzma.

Jeśli mamy smartfon z Androidem na pokładzie, to zapewne każdy za nas zadawał sobie pytanie, czy da radę z takiego telefonu pozbyć się szeregu aplikacji, z których praktycznie nie korzystamy na co dzień. Część z tych programów można wyłączyć w ustawieniach systemowych ale są też i takie aplikacje (głównie producenta telefonu, czy też operatora GSM albo te od Google), których standardowo nie da się wyłączyć z poziomu działającego Androida. Nawet jeśli wymusimy zatrzymanie stosownych usług, to za chwilę (lub po restarcie urządzenia) one i tak nam automatycznie wystartują. Im więcej zbędnych aplikacji działa w tle, tym częstsze wybudzanie telefonu, a więc i szybsze wyczerpywanie się baterii. Dlatego też jeśli nie korzystamy z wbudowanego w ROM bloatware, to przydałoby się go usunąć lub chociaż trwale wyłączyć. Co ciekawe, tego typu proces nie musi odbywać się za sprawą administratora systemu (root), bo w zasadzie każda aplikacja w Androidzie może zostać zainstalowana/odinstalowana dla konkretnego użytkownika w systemie. Nie potrzebujemy mieć zatem nawet ukorzenionego Androida, by pozbyć się tego całego syfu z systemu, który naszemu urządzeniu spędza sen z powiek i nie daje mu się przy tym porządnie wyspać.

Do tej pory zbytnio nie interesowałem się zagadnieniami dotyczącymi mechanizmu SafetyNet, który ma na celu utrudnić nieco życie użytkownikom smartfonów z Androidem lubiącym posiadać pełny dostęp do systemu swoich urządzeń za sprawą uzyskania praw administratora (root). To co się zmieniło na przestrzeni ostatnich paru miesięcy, to fakt, że coraz więcej aplikacji polega na tym całym SafetyNet, a przynajmniej ja zaczynam coraz częściej korzystać z tego typu oprogramowania. Jeśli jednak nasze urządzenie nie przejdzie testów SafetyNet, to funkcjonalność aplikacji polegających na tym mechanizmie może zostać dość znacznie ograniczona. Przykładem może być appka Revolut i jej odblokowanie za pomocą czytnika linii papilarnych. Bez SafetyNet trzeba podawać PIN za każdym razem, gdy się do tej aplikacji będziemy próbowali zalogować. Zwykle do obejścia SafetyNet używa się Magisk'a ale w pewnych sytuacjach, nawet i on nie jest w stanie z tym zdaniem sobie poradzić, przynajmniej nie bez dodatkowej konfiguracji. Jeśli na co dzień korzystamy z opcji debugowania ADB/USB, to może nas spotkać nie lada dylemat -- ADB/USB debug vs. SafetyNet. Okazuje się, że można pogodzić te dwie rzeczy.

Parę dni temu dowiedziałem się o projekcie /e/. Z racji, że ten ROM jest dostępny na mój smartfon LG G4C (jeszcze nieoficjalnie), to postanowiłem go sobie wgrać i zobaczyć jak się będzie sprawował. Podczas testów nowego oprogramowania spróbowałem zaszyfrować partycję /data/ . Problem w tym, że po automatycznym zresetowaniu się systemu, urządzenie już nie chciało się uruchomić. Przez dłuższy czas widniało logo LG, a po chwili pojawił się czarny ekran z informacją "Kernel Crash" lub niebieski ekran z informacją "Subsystem Crash". Czy telefon w takiej sytuacji nadaje się jedynie do wyrzucenia?

Nie bawiłem się ostatnio Neffos'ami ale w końcu udało mi się doprowadzić szyfrowanie w X1 Max (i pewnie X1 też) do ładu. Dla przypomnienia, to w tych modelach najwyraźniej system zapomniał by pytać użytkownika o hasło podczas konfiguracji, a że partycja z danymi użytkownikami jest zaszyfrowana w standardzie (bez możliwości zmiany), to ustawiane jest domyślne hasło tj. default_password . W ten sposób z technicznego punktu widzenia wilk jest syty i owca cała, no bo użytkownik nie jest dręczony dodatkowym hasłem przy uruchamianiu systemu (obok hasła blokady ekranu), no i dane są zaszyfrowane, no chyba, że ktoś wpisze ten nieszczęsny default_password .

Gdy kupujemy smartfon, to jego producent daje nam na ten sprzęt gwarancję i przez pewien okres czasu możemy nie martwić się o koszty ewentualnej naprawy. Niestety żyjemy w takich czasach, że sprzęt elektroniczny potrafi nam paść sam z siebie i to do tego jeszcze w niewyjaśnionych okolicznościach. Cześć wad jest fabrycznych (zwykle fizycznych) i te z reguły są oczywiste i łatwe do zdiagnozowania przez support producenta sprzętu, który nabyliśmy. Niemniej jednak, czasami wady są natury czysto programowej i tu z kolei ustalenie, gdzie dokładnie leży problem może już sprawiać kłopoty. Dlatego też producenci telefonów zabezpieczają się przed zmianą firmware przez użytkownika. W ten sposób wgrywając, np. TWRP recovery czy przeprowadzając proces root Androida, zwykle pozbawiamy się gwarancji i mamy problem, gdy telefon w późniejszym czasie popsuje się nie z naszej winy. Nawet jeśli wgramy stock'owe oprogramowanie, to i tak producent sprzętu jest w stanie ustalić czy coś w firmware mieszaliśmy. Zastanawialiście się może zatem skąd producent smartfona wie czy firmware takiego urządzenia został w jakiś sposób przez nas zmieniony?

Eksperymentując ostatnimi czasy ze smartfonami mającymi na pokładzie system Android nie zdarzyło mi się jeszcze, by jakoś poważniej taki telefon uszkodzić. Oczywiście wiele razy złapałem soft brick'a (bootloop i inne takie) ale w zasadzie bez większego problemu szło z takiej sytuacji wybrnąć. Dziś jednak sprawa była nieco bardziej poważna, bo mój Neffos X1 nie chciał się po prostu uruchomić, a konkretnie to pojawiało się logo TP-LINK i Android i telefon na tym ekranie startowym się zwyczajnie zawieszał. Pikanterii dodaje jeszcze fakt, że przed sprawdzeniem czy telefon działa poprawnie, zablokowałem bootloader przez fastboot oem lock . Naturalnie bootloader można odblokować też przy użyciu fastboot ale po zresetowaniu urządzenia, ta opcja, którą się przełącza w ustawieniach deweloperskich automatycznie wraca do pozycji zablokowanej. W taki sposób, by odblokować bootloader ponownie, trzeba wejść w te opcje jeszcze raz i tam ściągnąć pierw blokadę OEM, a dopiero później można mówić o bawieniu się fastboot . A jak niby mamy wejść w te ustawienia jeśli system nie chce wystartować, a my mamy stock'owy firmware producenta smartfona? Czy taki stan rzeczy oznacza trwałe uszkodzenie telefonu?

Stosunkowo niedawno do polskiej oferty TP-LINK trafił smartfon Neffos X1. To urządzenie było dostępne już dłuższy czas na rynku (zaprezentowane w Berlinie na targach IFA we wrześniu 2016) ale do Polski trafiło ono z dość mocnym opóźnieniem. Tak czy inaczej, ten telefon można już nabyć w sklepach, przez co wypadałoby rzucić na niego okiem i przyjrzeć się mu nieco bliżej. Dzięki uprzejmości TP-LINK Polska, Neffos X1 trafił do mnie na testy i postanowiłem napisać krótką recenzję tego sprzętu w kontekście pozostałych smartfonów Neffos, którymi miałem okazję się bawić w przeszłości, tj. modelami C5, C5 MAX, Y5 i Y5L. Czy Neffos X1 jest nas w stanie czymś zaskoczyć w stosunku do wcześniejszych modelów tych TP-LINK'owych smartfonów?