Użytkownicy Androida do przeglądania serwisu YouTube używają z reguły tej dedykowanej aplikacji od Google. Problem z tą appką jest taki, że serwuje ona całą masę reklam, których to nie można wykroić stosując popularne rozwiązania na bazie Blokada czy AdAway. Niektórzy starają się korzystać z innych aplikacji pokroju NewPipe czy SkyTube ale one mają swoje ograniczenia, np. nie można pisać komentarzy czy też nie działają powiadomienia push. Kiedyś by rozwiązać ten problem reklam w appce YouTube korzystałem z Magisk'a i jego modułu YouTube Vanced ale to rozwiązanie od jakiegoś czasu nie jest już wspierane, choć w dalszym ciągu można z niego korzystać. Jako, że od paru miechów nie zaglądałem na stronę YouTube Vanced, to postanowiłem sprawdzić czy coś w tej kwestii się zmieniło. Wygląda na to, że jednak coś drgnęło, bo teraz dostępny jest Vanced Manager, który to jest w stanie tak skonfigurować nasz telefon, by aplikacja YT Vanced działała bez problemu nawet na nieukorzenionym Androidzie (nie trzeba mieć root'a). Możemy zatem zachować całą funkcjonalność serwisu YouTube pozbywając się przy tym reklam oraz segmentów sponsorowanych, no i też nie musimy nic kombinować z telefonem, tj. odblokowywać bootloader'a czy wgrywać TWRP. Problematyczne może być jednak zainstalowanie YouTube Vanced, bo czasami powiadomienia (notyfikacje push) mogą nam nie działać poprawnie. Właśnie dlatego postanowiłem napisać parę słów na temat instalacji tej aplikacji z wykorzystaniem Vanced Manager w Androidach bez root, by uniknąć tego jak i innych problemów.

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.

Analizując sobie fabryczny podział przestrzeni flash w TP-LINK'owych smartfonach, a konkretnie w modelach Neffos C5 i C5 MAX, doszedłem do wniosku, że producent tych urządzeń nieco zaszalał przeznaczając aż 4 GiB przestrzeni na partycję /system/ . W zasadzie ROM w tych telefonach zajmuje około 2 GiB. Zatem pozostałe 2 GiB zwyczajnie się marnuje i przeciętny użytkownik smartfona nie będzie w stanie tego obszaru w żaden sposób wykorzystać. Można by zatem inaczej przepartycjonować ten flash, tak by nieco skurczyć samą partycję /system/ , przeznaczając jednocześnie odzyskane miejsce na powiększenie partycji /data/ . W tym wpisie postaramy się właśnie taki zabieg zmiany rozmiaru partycji /system/ przeprowadzić dla tych dwóch wyżej wymienionych modeli smartfonów.

Jakiś czas temu opisywałem proces ukorzeniania (root) smartfonów Neffos, a konkretnie były to modele C5, C5 MAX, Y5 i Y5L. Od tamtego czasu zdążyłem się nieco bardziej zagłębić w struktury Androida i udało mi się ze źródeł OMNI ROM zbudować natwyne obrazy TWRP dla każdego z tych ww. telefonów. Oczywiście TP-LINK ma w swojej ofercie jeszcze modele C5L, Y50, X1 oraz X1 MAX ale póki co nie będę w stanie przygotować obrazu TWRP i opisu jak ukorzenić Androidy w trzech z tych czterech smartfonów. Chodzi o to, że C5L został wycofany z produkcji i raczej nie wpadnie on w moje łapki. Natomiast modele Y50 oraz X1 MAX nie są jeszcze dostępne w polskiej ofercie TP-LINK'a, przez co minie trochę czasu zanim uda mi się do nich dobrać. Postanowiłem napisać świeży artykuł dotyczący procesu root w smartfonach Neffos C5, C5 MAX, Y5, Y5L oraz X1. Po co pisać kolejny artykuł o ukorzenianiu Androida w Neffos'ach? Generalnie rzecz biorąc, w tych poprzednich wpisach było bardzo dużo informacji zbędnych z punktu widzenia przeciętnego użytkownika, który chce zrootować system w swoim telefonie. Teraz, gdy dysponuję natywnymi obrazami TWRP własnej roboty i zdobyłem nieco wiedzy z zakresu operowania na Androidzie, to proces root jest o wiele prostszy i właśnie dlatego przydałoby się to wszystko opisać na nowo.

Po uszkodzeniu jednego z moich smartfonów TP-LINK i skasowaniu na nim wszystkich danych na partycji /system/ trzeba było pomyśleć nad przywróceniem tego urządzenia do życia. Jednym z rozwiązać było binarne wgranie obrazu systemowej partycji bezpośrednio na flash przy pomocy narzędzia dd. Co jednak w przypadku, gdy nie mamy dostępu do backup'u lub tez zwyczajnie go nie zrobiliśmy? Co w takiej sytuacji uczynić i czy jest jakaś nadzieja dla naszego telefonu? Odpowiedź jest naturalnie twierdząca ale wymagane są dwie rzeczy: działający tryb recovery (najlepiej TWRP) ze wsparciem dla trybu "ADB sideload" oraz paczka update.zip z firmware, którą można pobrać bezpośrednio ze strony TP-LINK/Neffos. By ulżyć nieco osobom, które do mnie piszą z zapytaniem o pomoc w przypadku skasowania danych na partycji /system/ (czy uszkodzenia jej w jakiś sposób), postanowiłem napisać krótkie howto na temat używania trybu ADB sideload. W tym artykule w rolach głównych weźmie udział Neffos Y5 ale bez problemu można te kroki przeprowadzić chyba na każdym innym smartfonie.

Zawsze mnie zastanawiało jak to jest możliwe, by przez przypadek można było usunąć dane na jeden z kluczowych partycji w smartfonie jaką jest partycja /system/ . Ostatnio wiele osób do mnie pisało z tego typu problemami i zapytaniem "jak odratować w takiej sytuacji telefon". Odpowiedź wydawała mi się prosta: wystarczy wgrać uprzednio zrobiony backup wyczyszczonej partycji via fastboot . Problem w tym, że po usunięciu danych z partycji /system/ , fastboot nie działa. A skąd to wiem? Ano "przez przypadek" usunąłem sobie dane na tej partycji. W sumie to tylko testowałem ficzer w TWRP zwany ADB Sideload, który niby ma za zadanie wgrać ROM z paczki .zip . Coś poszło nie tak i w zasadzie zostałem z pustą partycją /system/ . Przy odpalaniu telefonu w takim stanie, ten w zasadzie jedynie się resetuje co kilka chwil. Może i fastboot nie działa ale można wbić do trybu recovery. Jeśli tylko mamy wgrany TWRP, to jest spora szansa na odratowanie smartfona. W tym artykule w rolach głównych wystąpi Neffos Y5L, który ma SoC od Qualcomm'a, zatem nie damy rady się pobawić SP Flash Tool i całą robotę trzeba będzie odwalić ręcznie.

Każdy nowszy smartfon z Androidem oferuje możliwość zaszyfrowania wszystkich danych użytkownika zlokalizowanych na partycji /data/ . Cały proces można przeprowadzić w bardzo prosty sposób i bez większych problemów. Raz zaszyfrowanego telefonu nie da rady cofnąć do stadium przed szyfrowaniem i w zasadzie to zabezpieczenie można zdjąć jedynie przez przywrócenie urządzenia do ustawień fabrycznych. My tutaj jednak nie będziemy zajmować się samym szyfrowaniem smartfona i skupimy się bardziej na hasłach zabezpieczających mających stać na straży dostępu do naszych cennych danych, które mamy w telefonie. Większość z nas wykorzystuje krótkie hasło do odblokowania ekranu. To samo hasło z kolei jest wykorzystywane do zaszyfrowania klucza używanego w procesie szyfrowania/deszyfrowania danych na flash'u smartfona. W ustawieniach Androida nie ma jednak opcji rozdzielenia tych haseł i można by pomyśleć, że wykorzystanie czterocyfrowego kodu PIN jako zabezpieczenie mija się z celem. Na pewno w części smartfonów tak ale niekoniecznie we wszystkich modelach. Tak się składa, że akurat leży u mnie nieużywany Neffos Y5 od TP-LINK, to postanowiłem przyjrzeć się nieco bliżej tej kwestii haseł i sprawdzić czy jest się czego obawiać stosując krótkie hasła w zaszyfrowanych Androidach.

Gdy zamierzamy zbudować sobie własny ROM na smartfon z Androidem, np. LineageOS (CyanogenMod nie jest już rozwijany) czy nawet jedynie obraz recovery (TWRP albo CWM), to potrzebne nam jest stosowne urządzenie oraz odpowiedni kod źródłowy. Skoro chcemy budować te ww. rzeczy, to prawdopodobnie nasz telefon nie jest przez to oprogramowanie jeszcze wspierany lub też sam soft nie jest regularnie aktualizowany przez dewelopera. W zasadzie zarówno pełne ROM'y jak i obrazy recovery są budowane ze źródeł Androida. Niemniej jednak, oficjalny kod dostarczany przez Google budzi czasem wiele kontrowersji i ci nieco bardziej zaawansowani użytkownicy zmieniają go, np. czyniąc go w pełni OpenSource czy też implementując w nim pewną niestandardową funkcjonalność. Tak powstają Custom ROM'y, które w późniejszym czasie z racji swojej popularności przestają być "Custom" i zaczynają żyć swoim własnym życiem obok tego Góglowskiego Androida. W przypadku budowania obrazu recovery nie są nam potrzebne całe źródła konkretnego ROM'u. Jakby nie patrzeć, potrafią one zajmować trochę miejsca, a poza tym proces ich budowania jest stosunkowo czasochłonny. Tak czy inaczej, jakieś źródła trzeba pozyskać i przygotować je do dalszej pracy. W tym artykule nie będziemy sobie jeszcze budować całego ROM'u i skupimy się na zbudowaniu od podstaw jedynie obrazu TWRP recovery ze źródeł OMNI ROM. Ten proces zostanie pokazany na przykładzie smartfona Neffos Y5 od TP-LINK przy wykorzystaniu systemu linux, a konkretnie dystrybucji Debian.

Bawiąc się ostatnio trochę mechanizmami szyfrującymi w moich smartfonach Neffos podesłanych przez TP-LINK, po raz kolejny coś nieopatrznie uszkodziłem. Tym razem sprawa wygląda nieco bardziej poważnie, bo uwalony został cały moduł szyfrujący urządzenie. Chodzi generalnie o to, że w Androidzie w wersji 4.4/5.0 została wprowadzona możliwość zaszyfrowania wszystkich danych użytkownika, tj. informacji przechowywanych na partycji /data/ . Do odszyfrowania tej partycji potrzebny jest klucz szyfrujący. Problem w tym, że Android musi gdzieś ten klucz trzymać i to w taki sposób, by proces Factory Reset był w stanie ten klucz usunąć, choćby na wypadek zapomnienia hasła i próby odzyskania w takiej sytuacji władzy nad smartfonem. Pech chciał, że akurat na moim Neffos Y5 mam wgrane TWRP recovery i z jakiegoś powodu nie mogłem zresetować ustawień telefonu do fabrycznych przez ten tryb i posłużyłem się narzędziem fastboot . Ono najwyraźniej nieco inaczej formatuje partycję /data/ i w ten sposób uwala cały mechanizm szyfrowania oferowany przez Androida. Czy da radę jakoś poprawić ten problem, a jeśli tak to w jaki sposób?