Interfejs API Fabricated Overlay w Androidzie 12 przywraca motywy bez rootowania

Pełna stajnia Androida 12 wydanie jest tuż za rogiem, a Google już to zrobił opublikował kod źródłowy do swojego repozytorium AOSP. Jest wiele nowości w Androidzie 12, w tym dodatek do nakładek zasobów o nazwie Sfabrykowane nakładki. Co miało oznaczać interfejs API pomagający systemowi zarządzać dynamicznymi zmianami używanymi w Materialny Ty a monety mogą zamienić się w coś znacznie większego – przynajmniej do czasu premiery Androida 13.

Tło

Mishaal Rahman odkrył ten nowy interfejs API i zwrócił mi na niego uwagę. Używał do tego polecenia Shell, aby bez konieczności testowania różnych wartości zasobów w systemie Android 12 do ręcznego kompilowania nakładkowych plików APK i pomyślał, że może to być ciekawy pomysł na aplikację dla urządzeń zrootowanych. Kiedy zwrócił mi na to uwagę, dokładnie przyjrzałem się kodowi źródłowemu Androida 12 i zauważyłem coś, co wydało mi się całkiem interesujące. Przetestowałem to, co znalazłem, i oto jesteśmy – jak się okazuje, API Fabricated Overlay może zostać użyte do przywrócenia motywów bez rootowania. Zanim za bardzo zagłębię się w to, co się tutaj dzieje, wyjaśnię, czym właściwie są sfabrykowane nakładki.

Czym są gotowe nakładki?

Fabricated Overlays to nowa funkcja wprowadzona w systemie Android 12. Są podobne do klasycznych nakładek zasobów wykonawczych (RRO), które Android ma już od kilku lat. Zarówno RRO, jak i sfabrykowane nakładki mogą zastąpić różne zasoby dla różnych zastosowań. Możesz zmienić wartość logiczną z fałszywej na prawdziwą (lub odwrotnie), ustawić, jak duży ma być pasek stanu i tak dalej.

Sfabrykowane nakładki różnią się jednak pewnymi zauważalnymi różnicami od RRO. Po pierwsze, nie musisz generować nakładki APK, a następnie ją instalować. Zamiast tego po prostu mówisz Androidowi, które wartości chcesz zmienić dla której aplikacji, a on zajmuje się rejestrowaniem twoich zmian jako nakładki, którą możesz następnie włączyć.

Są też nieco bardziej ograniczone niż RRO. Przed Androidem 11 RRO mogły zastąpić praktycznie każdy zasób: wartości logiczne, liczby całkowite, wymiary, atrybuty, układy, a nawet surowe pliki danych. W Androidzie 11 wprowadzono pewne zmiany w działaniu RRO, przez co zastępowanie układów stało się już niewykonalne, chociaż ogólnie rzecz biorąc, RRO stało się bardziej stabilne.

Z drugiej strony, sfabrykowane nakładki mogą przesłaniać tylko wartości, które można przedstawić jako liczby całkowite. Obejmuje to liczby całkowite (duh), wymiary, wartości logiczne i kolory. Nie można ich używać do zastępowania nieprzetworzonych zasobów danych, układów, ciągów lub tablic – przynajmniej nie jest to łatwe. Jest to w pewnym sensie arbitralne ograniczenie interfejsu API: akceptuje ono tylko wartości całkowite i kategorie zasobów zdefiniowane przez klasę TypedValue. TypedValue tak wsparcie strings i inne typy zasobów, ale tylko w celu odniesienia się do ich zasobów, a nie do przechowywania ich rzeczywistych danych.

Jednak te ograniczenia nie są zbyt duże, biorąc pod uwagę zamierzony cel sfabrykowanych nakładek: Materialny Ty i efekty pieniężne. Sfabrykowane nakładki ułatwiają systemowi generowanie i stosowanie nakładek kolorów i wymiarów na bieżąco, bez konieczności ponownego uruchamiania lub czekania na skompilowanie pliku APK.

Zwykle byłby to po prostu kolejny fajny interfejs API, z którego mogą skorzystać osoby posiadające zrootowane urządzenia. Jeśli nie ma luki stworzonej przez producenta (takiej jak ta, którą Synergy wykorzystuje na urządzeniach Samsung), nakładki mogą instalować wyłącznie strony trzecie z uprawnieniami roota. Ale to jest najlepsze – Google zapomniał załatać dziurę w Androidzie 12.

Sfabrykowane nakładki bez korzenia

W systemie Android 8 wprowadzono nowy interfejs API usługi Overlay Manager Service (lub OMS) i ludzie dość szybko odkryli, że nakładki APK można instalować jak zwykłe aplikacje, a następnie włączać za pomocą ADB. Niestety Google załatało to w Androidzie 9 i od tego czasu dynamicznie instalują się tylko nakładki podpisane tym samym kluczem co system.

Jak się okazuje, sfabrykowane nakładki w Androidzie 12 mają lukę przypominającą tę z Androida 8: nie wymagają dostępu do konta root ani uprawnień na poziomie podpisu. Potrzebują tylko czegoś działającego jako użytkownik powłoki (tj. ADB), aby je zarejestrować.

Jest całkiem jasne, że Google zamierzył, aby sfabrykowane nakładki były dostępne tylko dla użytkowników root i systemu. Istnieje implementacja poleceń ADB do ich tworzenia, która nie zostanie uruchomiona, jeśli użytkownik wykonujący nie jest rootem. Luka polega na tym, że kontrola odbywa się tylko w poleceniu, a nie w rzeczywistym interfejsie API, co oznacza, że ​​możemy z tego skorzystać przy odrobinie pracy.

ADB na urządzeniu

Od dłuższego czasu Android ma bezprzewodową funkcję ADB. Dzięki temu komputer (lub cokolwiek z plikiem binarnym ADB i dostępem do sieci) może połączyć się z urządzeniem bezprzewodowo. Jest przeznaczony głównie dla urządzeń z Androidem, które nie mają dostępnych dla użytkownika połączeń USB, np smartwatche i telewizory. Co więcej, przed Androidem 11 do aktywacji potrzebne było przewodowe połączenie ADB Tryb Bezprzewodowy.

Android 11 oficjalnie wprowadził bezprzewodowe ADB na telefony i tablety. Jest nieco bardziej skomplikowany niż klasyczny bezprzewodowy ADB, z kodami parowania i uwierzytelniania, ale użytkownik może go aktywować całkowicie na urządzeniu, tak długo, jak urządzenie jest podłączone do Wi-Fi. Oznacza to, że można połączyć się z urządzeniem za pośrednictwem ADB z poziomu urządzenia, a wszystko, czego potrzebujesz, to Wi-Fi połączenie.

Korzystanie z podwyższonych interfejsów API w aplikacji

Istnieje wiele powodów, dla których możesz chcieć używać w swojej aplikacji ograniczonych interfejsów API. Zwykle dzieje się tak dlatego, że zapewniają one jakąś specjalną funkcjonalność, której potrzebujesz. Dopóki potrzebny interfejs API ma implementację poleceń powłoki, korzystanie z niego z poziomu aplikacji jest całkiem łatwe. Wszystko, co musisz zrobić, to utworzyć proces powłoki jako root (lub ADB), uruchomić odpowiednie polecenie i przeanalizować wynik, jeśli taki istnieje.

Co się stanie, jeśli interfejs API nie ma implementacji powłoki lub w implementacji powłoki brakuje czegoś, czego potrzebujesz? Jeśli korzystasz z zrootowanego urządzenia, możesz użyć czegoś takiego libRootJava. Biblioteka libRootJava umożliwia interakcję z interfejsami API platformy Android tak, jakby aplikacja działała jako użytkownik root. Jest to wygodniejsze i znacznie szybsze niż uruchamianie poleceń powłoki, ponieważ wszystko jest w tym samym języku i nie musisz się martwić ręcznym analizowaniem ciągów znaków. Ma pewne ograniczenia, ale w większości działa świetnie.

Interfejs API libRootJava jest dość elastyczny. Można go dostosować do działania jako użytkownik powłoki zamiast root. Na szczęście nie trzeba, bo ktoś już to zrobił i to się nazywa Shizuku. Shizuku jest prawie jak połączenie Magisk Managera i libRootJava.

Aplikacja Shizuku Manager prowadzi Cię przez konfigurację procesu działającego jako użytkownik powłoki, do którego Shizuku może uzyskać dostęp. Bibliotekę API Shizuku można zaimplementować w aplikacjach, aby umożliwić im dostęp do systemowych interfejsów API tak, jakby były użytkownikiem powłoki. Jest to znacznie bardziej scentralizowany proces niż libRootJava, ponieważ Shizuku trzeba skonfigurować tylko raz, zanim każda aplikacja implementująca bibliotekę Shizuku API będzie mogła z niego korzystać. Jeśli interesuje Cię, jak działa Shizuku i jak możesz zintegrować go ze swoją aplikacją, Mam tu poradnik na ten temat.

Shizuku i gotowe nakładki

Prawdopodobnie już widać, dokąd to zmierza. Możemy skorzystać z usługi takiej jak Shizuku, aby uzyskać dostęp do interfejsu API Fabricated Overlays jako użytkownik powłoki, a także możemy skorzystać z bezprzewodowej funkcji ADB systemu Android 11, aby uzyskać dostęp na poziomie powłoki, a wszystko to na urządzeniu. Ponieważ ograniczenie użytkownika root występuje tylko w poleceniu powłoki Fabricated Overlays, a nie w rzeczywistym interfejsie API, do bezpośredniego użycia wystarczy uruchomienie jako użytkownik powłoki.

Implementacja: Biblioteka i przykładowa aplikacja

A co ze szczegółami wdrożenia? Cóż, w tym też cię zabezpieczę.

Przygotowując się do tego, zrobiłem zarówno a bibliotekę i w pełni funkcjonalną przykładową aplikację korzystając z tej biblioteki.

Sama biblioteka służy głównie wygodzie. Obejmuje niektóre ukryte interfejsy API systemu i udostępnia kilka wygodnych metod obsługi uprawnień Shizuku. Jest także elastyczny, więc możesz udostępnić własną instancję API IOverlayManager, jeśli masz inny sposób na jej pobranie.

Przykładowa aplikacja pokazuje, jak można wdrożyć bibliotekę przy użyciu Shizuku. To także w pełni funkcjonalna i przydatna aplikacja. Strona główna wyświetla aktualnie zarejestrowane sfabrykowane nakładki, które zostały za jej pośrednictwem utworzone, pogrupowane według aplikacji docelowej. Możesz je także włączać, wyłączać i usuwać z tego miejsca.

Kliknięcie przycisku „Dodaj nakładkę” u dołu powoduje wyświetlenie listy wszystkich aplikacji, które można nakładać. Wyszukaj lub przewiń, aby znaleźć ten, którego potrzebujesz, i dotknij go. Następnie możesz nacisnąć przycisk „Dodaj” u dołu ekranu, aby wyświetlić listę zasobów, które można zastąpić w tej aplikacji. Wybierz zasób, ustaw jego wartość i powtórz tę czynność dla dowolnej liczby wartości, które chcesz zmienić. Naciśnij przycisk „Zapisz”, wprowadź nazwę, potwierdź, a zostaniesz przeniesiony do ekranu głównego, pokazującego nową nakładkę, gotową do włączenia.

Oto kilka zrzutów ekranu z aplikacji, dzięki Mishaalowi Rahmanowi.

Na marginesie, mam także ogólną aplikację do zarządzania nakładkami o nazwie... Menedżer nakładek. Sama prekompilowana aplikacja jest dostępne tylko na moim Patreonie, ale kod źródłowy jest swobodnie dostępny każdemu, kto chce go skompilować lub zmodyfikować.

Wniosek

Nowy interfejs API Fabricated Overlays w Androidzie 12 jest całkiem niezły, głównie dlatego, że nie wymaga rootowania. Może nie jest tak wyrafinowany jak pełny pakiet APK RRO, ale zapewnia znacznie większą elastyczność bez dostępu do roota.

Sprawdź aplikację Fabricate Overlay w serwisie GitHub

Jeśli masz urządzenie z systemem Android 12 i chcesz spróbować, sprawdź repozytorium GitHub, do którego link znajduje się powyżej. W sekcji Wersje będzie dostępny plik APK do pobrania i użycia. Biblioteka powinna być łatwa do dołączenia do własnej aplikacji przy użyciu JitPack.

Oczywiście nie należy oczekiwać, że ta funkcja będzie działać długo. Google naprawdę nie lubi nakładek innych firm, więc prawie na pewno zostanie to naprawione po wydaniu Androida 13. Tymczasem jednak cieszcie się nim, póki trwa!