Jeśli podczas bocznego pobierania aktualizacji aplikacji Aparat lub Rejestrator Google pojawia się błąd „nieudana weryfikacja”, przeczytaj ten artykuł, aby dowiedzieć się dlaczego.
Kiedy w październiku Google wypuściło na rynek Pixela 5, nie mogliśmy się doczekać, kiedy dotrzemy do jego nowych aplikacji. (Sam telefon jest całkiem fajne.) Wraz z premierą Pixela 5 pojawiły się nowe wersje Aparat Google I Rejestrator Google aplikacje, które udostępniliśmy społeczności. Jednak gdy wielu użytkowników starszych urządzeń Pixel próbowało odsunąć aktualizacje, pojawiał się błąd (pokazany powyżej). Co dziwne, nie wszyscy mieli problemy z instalacją aktualizacji. Niektórym udało się je zainstalować poprawnie, podczas gdy inni musieli przywrócić ustawienia fabryczne, aby móc zainstalować nowe wersje. Ze względu na pozornie losowy charakter tego problemu, wielu uznało go za błąd. Jesteśmy już niemal pewni, że przyczyną tego problemu nie jest błąd, ale raczej użycie przez Google nowego interfejsu API w systemie Android 11 w celu blokowania aktualizacji z boku.
Jeśli spróbujesz odsunąć aparat Google 8.0 lub nowszy albo Rejestrator Google 2.0 lub nowszy na urządzenie Pixel z systemem Android 11, pojawi się komunikat o błędzie z informacją, że weryfikacja nie powiodła się. Nawet jeśli spróbujesz załadować plik APK za pomocą polecenia powłoki, nie otrzymasz bardziej szczegółowej przyczyny niepowodzenia instalacji. Kod powrotu instalacji, który otrzymasz to „INSTALL_FAILED_VERIFICATION_FAILURE", co niestety nie informuje, dlaczego weryfikacja się nie powiodła. Badając logcat, możemy dowiedzieć się dokładnie, dlaczego weryfikacja kończy się niepowodzeniem:
AppIntegrityManagerServiceImpl: Integritycheckofcom.google.android.GoogleCameraresult: DENYdueto[Rule: (PACKAGE_NAME EQ com.google.android.GoogleCamera) AND (VERSION_CODE GTE 32045130) AND (APP_CERTIFICATE EQ F0FD6C5B410F25CB25C3B53346C8972FAE30F8EE7411DF910480AD6B2D60DB83) AND NOT (INSTALLER_NAME EQ com.android.vending), DENY]Zgodnie z tą wiadomością sprawdzenie integralności instalacji Aparatu Google nie powiodło się, ponieważ nazwa „INSTALLER_NAME” nie jest zgodna z „com.android.vending”, czyli nazwą pakietu w Sklepie Google Play. (Próbowałem zainstalować Aparat Google 8.0 przy użyciu aplikacji APKMirror Instalator, jeśli to ma sens.) Ta wiadomość została dodana do dziennika systemowego przez „AppIntegrityManagerServiceImpl”, który jest częścią nowej funkcji „Integralność aplikacji” w systemie Android. Zgodnie z kodem w AOSP, integralność aplikacji ma na celu zapewnienie dodatkowej warstwy kontroli oprócz istniejącej weryfikacji podpisu APK przez menedżera pakietów. Wydaje się, że interfejs API integralności aplikacji korzysta z zestawu Zasady aby zdecydować, czy zezwolić lub odmówić instalacji. Reguły są dostarczane przez aplikację systemową — którą uważamy za Usługi Google Play — i takie są zapisane w pliku.
Ponadto integralność aplikacji również dzwoni inna klasa tzw Weryfikator znacznika źródła jeśli „znaczek źródłowy” jest osadzony w metadanych Manifestu. Oto na przykład „znaczek źródłowy” z manifestu aplikacji Aparat Google:
<meta-dataandroid: name="com.android.stamp.source"android: value="https://play.google.com/store"/>Z tego, co wiemy, stempel źródłowy służy do weryfikacji podpisu instalatora pakietu. Na przykład nie można oszukać aplikacji AppIntegrity, aby zezwoliła na instalację, nawet jeśli oszukał Sklep Play jako instalator.
Poza tym nie byliśmy w stanie dowiedzieć się, w jaki sposób Google dokładnie wykorzystuje AppIntegrity i powiązane interfejsy API do blokowania bocznego pobierania aktualizacji aplikacji Aparat Google i Rejestrator Google. Szybka analiza pakietu APK Usług Google Play ujawnia, że korzysta on z tych interfejsów API, ale kod jest zbyt zaciemniony, aby naprawdę wszystko miało sens. Znaleźliśmy nawet katalog, w którym przechowywane są reguły integralności — /data/system/integrity_rules — ale był on mało przydatny, ponieważ zawierał tylko dane serializowane. Nie znaleźliśmy również sposobu na wyłączenie weryfikacji integralności (nie wydaje się to tak proste, jak po prostu zmiana ustawienia), chociaż uważamy, że w niektórych przypadkach przywrócenie ustawień fabrycznych działa, ponieważ Usługi Google Play nie mają możliwości zainicjowania zestawu reguł w celu zablokowania instalacji. Komunikat logcat i wprowadzenie nowych interfejsów API w systemie Android 11 zdecydowanie sugerują, że jest to jednak wszystko zgodne z projektem, a nie błąd.
Firma Google nie skomentowała publicznie korzystania z tych interfejsów API (ani tego nie oczekujemy) i nie odpowiedziała, gdy poproszono ją o komentarz. Mamy jednak kilka teorii, dlaczego blokują aktualizacje pobierane z boku. Po pierwsze, mogą chronić ludzi przed zainstalowaniem niewłaściwej wersji aplikacji na ich urządzeniu. Google dostarcza określone wersje swoich aplikacji na określone urządzenia Pixel. Na przykład w Internecie można znaleźć kilka wersji aplikacji Usługi personalizacji urządzenia. Mimo że wszystkie można je zainstalować na urządzeniach Pixel, w pewnym momencie było to możliwe utracić funkcję napisów na żywo na Pixelu 4, pobierając wersję zbudowaną dla starszego urządzenia Pixel. Innym powodem może być „poprawa identyfikowalności aplikacji pod kątem nieautoryzowanej dystrybucji”, jak wyjaśnił Google w klasie SourceStampVerifier.
Jak dotąd tylko kilka aplikacji Google korzystających z formatu pakietu aplikacji (np. Aparat Google i Rejestrator Google) tak robi blokowanie instalacji spoza Sklepu Play, ale nie wiemy, czy firma rozszerzy to zachowanie na inne swoje aplikacje gdy wszyscy przejdą na format AAB. Rozważaliśmy również, czy przejście na pakiety aplikacji wymagało wdrożenia integralności aplikacji, ale odkryliśmy, że Google już to zrobił ma rozwiązanie do obsługi, gdy użytkownicy próbują zainstalować aplikację, która nie ma wszystkich wymaganych podziałów. Niezależnie od przypadku, nie sądzimy, że Google ma zamiar blokować wszelkie pobieranie swoich aplikacji z boku, chociaż te narzędzia z pewnością im to umożliwiają.
Podziękowania dla programistów vvb2060, aviraxp i Quinny899 za pomoc w tym artykule orazdziękujemy firmie PNF Software za udostępnienie nam licencji na użytkowanie Dekompilator JEB, profesjonalne narzędzie inżynierii wstecznej dla aplikacji na Androida.