Jakiś czas temu Disqus wprowadził reklamy w swoim systemie komentarzy i bez mojej świadomej oraz dobrowolnej zgody serwował je użytkownikom odwiedzającym mojego bloga. W tamtym czasie nie miałem za bardzo informacji jak te komentarze zastąpić na statycznej stronie renderowanej przy pomocy Hugo. Jako, że sporo osób narzekało na to, że tutaj nie ma komentarzy, przez co liczba maili, które do mnie docierały, była trochę ponad moje moce przerobowe. Postanowiłem zatem zaimplementować system komentarzy oparty o GitHub Issues, czyli ten mechanizm, z którym prawdopodobnie każdy z nas miał już styczność zgłaszając bug'a (czy też inne zapytanie) twórcom swoich ulubionych linux'owych projektów OpenSource. Okazało się, że przy pomocy API GitHub'a można w dość prosty sposób te komentarze pokazać na blogu ale problem pojawił się w przypadku stron mających setki czy nawet tysiące wpisów już opublikowanych. Jak zatem na takich blogach wdrożyć komentarze GitHub'a, tak by przy okazji nie wyskoczyć z okna o 5 nad ranem?

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.

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.