Hvis du har set en "mislykket bekræftelse"-fejl, når du sideindlæser en opdatering til Google Camera- eller Recorder-apps, skal du læse dette for at finde ud af hvorfor.
Da Google lancerede Pixel 5 tilbage i oktober, var vi spændte på at få fingrene i dens nye apps. (selve telefonen er ret sejtogså.) Med Pixel 5's lancering kom nye versioner af Google-kameraet og Google Optager apps, som vi har delt med fællesskabet. Men da mange brugere af ældre Pixel-enheder forsøgte at sideindlæse opdateringerne, blev de mødt med en fejl (vist ovenfor). Bizart nok havde ikke alle problemer med at installere opdateringerne. Nogle var i stand til at installere dem fint, mens andre skulle fabriksindstilles bare for at kunne installere de nye versioner. På grund af den tilsyneladende tilfældige karakter af dette problem, kridtede mange det op til en fejl. Vi er temmelig sikre på nu, at dette problem ikke stammer fra en fejl, men snarere Googles brug af en ny API i Android 11 til at blokere sideloading-opdateringer.
Hvis du forsøger at sideindlæse Google Camera 8.0 eller nyere eller Google Recorder 2.0 eller nyere på en Pixel-enhed, der kører Android 11, vil du se en fejlmeddelelse, der siger, at bekræftelsen ikke kunne lykkes. Selvom du forsøger at sideindlæse APK'en ved hjælp af en shell-kommando, får du ikke en mere specifik årsag til installationsfejlen. Installationsreturkoden, du får tildelt, er "INSTALL_FAILED_VERIFICATION_FAILURE", som desværre ikke fortæller dig, hvorfor verifikationen ikke lykkes. Ved at undersøge logcat kan vi lære præcis, hvorfor verifikationen mislykkes:
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]Ifølge denne meddelelse mislykkedes et integritetstjek af Google Kamera-installationen, fordi "INSTALLER_NAME" ikke matchede "com.android.vending", pakkenavnet for Google Play Butik. (Jeg forsøgte at installere Google Camera 8.0 ved hjælp af APKMirror Installer-appen, for hvad det er værd.) Denne meddelelse blev tilføjet til systemloggen af "AppIntegrityManagerServiceImpl", som er en del af Androids nye "App Integrity"-funktion. Ifølge koden i AOSP er App Integrity designet til at give et ekstra lag af kontroller oven på pakkeadministratorens eksisterende APK-signaturbekræftelse. App Integrity API ser ud til at bruge et sæt af Regler for at beslutte, om installationen skal tillades eller afvises. Reglerne leveres af en systemapp – som vi mener er Google Play-tjenester – og er det gemt i en fil.
Derudover App Integrity ringer også ringede en anden klasse SourceStampVerifier hvis et "kildestempel" er indlejret i Manifestets metadata. For eksempel, her er, hvad vi mener er "kildestemplet" fra Google Kamera-appens manifest:
<meta-dataandroid: name="com.android.stamp.source"android: value="https://play.google.com/store"/>Ud fra hvad vi kan se, bruges kildestemplet til at bekræfte signaturen på pakkeinstallationsprogrammet. Så du kan for eksempel ikke snyde AppIntegrity til at tillade installationen, selvom du forfalskede Play Butik som installatør.
Ud over dette var vi ikke i stand til at finde ud af præcis, hvordan Google bruger AppIntegrity og relaterede API'er til at blokere sideloading-opdateringer til Google Kamera- og Google Recorder-apps. En hurtig undersøgelse af Google Play Services APK afslører, at den bruger disse API'er, men koden er for sløret til virkelig at give mening med alt. Vi fandt endda den mappe, hvor integritetsreglerne er gemt - /data/system/integrity_rules - men det var til lidt nytte, fordi det kun indeholder serialiserede data. Vi har heller ikke fundet en måde at deaktivere integritetsbekræftelse (det ser ikke ud til at være så nemt som bare at ændre en indstilling), selvom vi mener, at grunden til, at fabriksnulstilling fungerer for nogle, er, at Google Play Services ikke får en chance for at initialisere sit regelsæt for at blokere installationen. Logcat-meddelelsen og introduktionen af disse nye API'er i Android 11 tyder kraftigt på, at det hele er designet og ikke en fejl.
Google har ikke offentligt kommenteret sin brug af disse API'er (vi forventer heller ikke, at de gør det), og de reagerede ikke, da de blev nået til en kommentar. Vi har dog et par teorier om, hvorfor de blokerer sideloadede opdateringer. For det første kunne de beskytte folk mod at installere den forkerte version af appen til deres enhed. Google leverer specifikke versioner af sine apps til specifikke Pixel-enheder. For eksempel kan flere versioner af appen Device Personalization Services findes online. Selvom de alle kan installeres på Pixel-enheder, var det muligt på et tidspunkt miste Live Captions-funktionen på Pixel 4 ved at downloade en version bygget til en ældre Pixel-enhed. En anden grund kunne være at "forbedre sporbarheden af apps med hensyn til uautoriseret distribution", som forklaret af Google i klassen SourceStampVerifier.
Indtil videre er kun nogle få af Googles apps, der bruger app bundle-formatet (som Google Camera og Google Recorder), der er blokering af ikke-Play Butik-installationer, men vi ved ikke, om virksomheden vil udvide denne adfærd til sine andre apps når de alle skifter til AAB-formatet. Vi overvejede også, om skiftet til app bundles nødvendiggjorde implementering af App Integrity, men vi fandt ud af, at Google allerede har en løsning at håndtere, når brugere forsøger at installere en app, der ikke har alle de nødvendige opdelinger. Uanset hvad sagen måtte være, tror vi ikke, at Google har til hensigt at blokere al sideindlæsning af sine apps, selvom disse værktøjer bestemt tillader dem at gøre det.
Tak til udviklerne vvb2060, aviraxp og Quinny899 for deres hjælp i denne artikel, og ttakker PNF Software for at give os en licens til at bruge JEB Decompiler, et professionelt reverse engineeringværktøj til Android-applikationer.