Als u de foutmelding 'mislukte verificatie' heeft gezien bij het sideloaden van een update voor de Google Camera- of Recorder-apps, lees dan dit om erachter te komen waarom.
Toen Google in oktober de Pixel 5 lanceerde, waren we enthousiast om de nieuwe apps in handen te krijgen. (De telefoon zelf is best gaaf, ook.) Met de lancering van de Pixel 5 kwamen er nieuwe versies van de Google-camera En Google-recorder apps die we met de community hebben gedeeld. Toen veel gebruikers van oudere Pixel-apparaten echter probeerden de updates te sideloaden, kregen ze een foutmelding (hierboven weergegeven). Vreemd genoeg had niet iedereen problemen met het installeren van de updates. Sommigen konden ze prima installeren, terwijl anderen de fabrieksinstellingen moesten herstellen om de nieuwe versies te kunnen installeren. Vanwege de ogenschijnlijk willekeurige aard van dit probleem, hebben velen het toegeschreven aan een bug. We zijn er nu vrij zeker van dat dit probleem niet voortkomt uit een bug, maar eerder uit het gebruik door Google van een nieuwe API in Android 11 om sideloading-updates te blokkeren.
Als u Google Camera 8.0 of hoger of Google Recorder 2.0 of hoger probeert te sideloaden op een Pixel-apparaat met Android 11, ziet u een foutmelding waarin staat dat de verificatie niet is gelukt. Zelfs als u de APK probeert te sideloaden met een shell-opdracht, krijgt u geen specifiekere reden voor het mislukken van de installatie. De installatieretourcode die u krijgt, is "INSTALL_FAILED_VERIFICATION_FAILURE", wat u helaas niet vertelt waarom de verificatie niet lukt. Door de logcat te onderzoeken, kunnen we precies leren waarom de verificatie mislukt:
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]Volgens dit bericht is een integriteitscontrole van de Google Camera-installatie mislukt omdat de "INSTALLER_NAME" niet overeenkomt met "com.android.vending", de pakketnaam voor de Google Play Store. (Ik probeerde Google Camera 8.0 te installeren met de APKMirror Installer-app, voor wat het waard is.) Dit bericht is toegevoegd aan het systeemlogboek door "AppIntegrityManagerServiceImpl", dat deel uitmaakt van de nieuwe "App Integrity" -functie van Android. Volgens de code in AOSP is App Integrity ontworpen om een extra controlelaag te bieden bovenop de bestaande APK-handtekeningverificatie van de pakketbeheerder. De App Integrity API lijkt een set te gebruiken Reglement om te beslissen of u de installatie al dan niet wilt toestaan of weigeren. Regels worden geleverd door een systeemapp – waarvan wij denken dat het Google Play-services is – en dat is ook zo opgeslagen in een bestand.
Bovendien app-integriteit belt ook een andere klas belde SourceStampVerifier als er een "bronstempel" is ingebed in de metadata van het Manifest. Dit is bijvoorbeeld wat volgens ons de 'bronstempel' is uit het Manifest van de Google Camera-app:
<meta-dataandroid: name="com.android.stamp.source"android: value="https://play.google.com/store"/>Voor zover we kunnen zien, wordt de bronstempel gebruikt om de handtekening van het pakketinstallatieprogramma te verifiëren. U kunt AppIntegrity dus bijvoorbeeld niet misleiden om de installatie toe te staan, zelfs als u dat wel doet vervalste de Play Store als installateur.
Daarnaast konden we niet precies achterhalen hoe Google AppIntegrity en gerelateerde API's gebruikt om sideloading-updates voor de Google Camera- en Google Recorder-apps te blokkeren. Een snel onderzoek van Google Play Services APK laat zien dat het deze API's gebruikt, maar de code is te onduidelijk om echt alles te begrijpen. We hebben zelfs de map gevonden waar de integriteitsregels zijn opgeslagen – /data/system/integrity_rules – maar deze had weinig nut omdat deze alleen geserialiseerde gegevens bevat. We hebben ook geen manier gevonden om integriteitsverificatie uit te schakelen (het lijkt niet zo eenvoudig als gewoon een instelling wijzigen), hoewel we denken dat de reden dat het terugzetten van de fabrieksinstellingen voor sommigen werkt, is dat Google Play Services geen kans krijgt om de regelset te initialiseren om de installatie te blokkeren. Het logcat-bericht en de introductie van deze nieuwe API's in Android 11 suggereren echter sterk dat dit allemaal ontwerp is en geen bug.
Google heeft niet publiekelijk gereageerd op het gebruik van deze API's (en dat verwachten we ook niet), en ze reageerden niet toen ze voor commentaar werden benaderd. We hebben echter een paar theorieën waarom ze sideloaded updates blokkeren. Ten eerste kunnen ze mensen beschermen tegen het installeren van de verkeerde versie van de app voor hun apparaat. Google levert specifieke versies van zijn apps op specifieke Pixel-apparaten. Er zijn bijvoorbeeld verschillende versies van de Device Personalisation Services-app online te vinden. Hoewel ze allemaal op Pixel-apparaten kunnen worden geïnstalleerd, was het ooit mogelijk verlies de functie Live ondertiteling op de Pixel 4 door een versie te downloaden die is gebouwd voor een ouder Pixel-apparaat. Een andere reden zou kunnen zijn om "de traceerbaarheid van apps te verbeteren met betrekking tot ongeautoriseerde distributie", zoals uitgelegd door Google in de SourceStampVerifier-klasse.
Tot nu toe gebruiken slechts enkele apps van Google het app-bundelformaat (zoals Google Camera en Google Recorder). het blokkeren van niet-Play Store-installaties, maar we weten niet of het bedrijf dit gedrag zal uitbreiden naar zijn andere apps zodra ze allemaal overschakelen naar het AAB-formaat. We hebben ook overwogen of de overstap naar app-bundels de implementatie van App Integrity noodzakelijk maakte, maar we ontdekten dat Google al heeft een oplossing te behandelen wanneer gebruikers een app proberen te installeren die niet over alle vereiste splitsingen beschikt. Hoe het ook zij, we denken niet dat Google van plan is alle sideloading van zijn apps te blokkeren, hoewel deze tools dat zeker wel mogelijk maken.
Dank aan ontwikkelaars vvb2060, aviraxp en Quinny899 voor hun hulp bij dit artikel, en tmet dank aan PNF Software voor het verstrekken van een gebruikslicentie JEB-decompiler, een professionele reverse engineering-tool voor Android-applicaties.