Här är anledningen till att du inte kan sidladda uppdateringar till Google Camera and Recorder

När Google lanserade Pixel 5 redan i oktober var vi glada över att lägga vantarna på dess nya appar. (Själva telefonen är ganska coolockså.) Med lanseringen av Pixel 5 kom nya versioner av Google Kamera och Google Recorder appar som vi delat med communityn. Men när många användare av äldre Pixel-enheter försökte sidladda uppdateringarna möttes de av ett fel (visas ovan). Konstigt nog hade inte alla problem med att installera uppdateringarna. Vissa kunde installera dem bra, medan andra var tvungna att återställa fabriken bara för att de skulle kunna installera de nya versionerna. På grund av den här frågans till synes slumpmässiga karaktär har många kritat det till en bugg. Vi är ganska övertygade om att det här problemet inte härrör från en bugg utan snarare Googles användning av ett nytt API i Android 11 för att blockera sidladdningsuppdateringar.

Om du försöker sidladda Google Camera 8.0 eller senare eller Google Recorder 2.0 eller senare på en Pixel-enhet som kör Android 11, kommer du att se ett felmeddelande som säger att verifieringen inte kunde lyckas. Även om du försöker sidladda APK-filen med hjälp av ett skalkommando, kommer du inte att få en mer specifik orsak till installationsfelet. Installationsreturkoden som du får är "INSTALL_FAILED_VERIFICATION_FAILURE", som tyvärr inte berättar varför verifieringen inte lyckas. Genom att undersöka logcat kan vi lära oss exakt varför verifieringen misslyckas:

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]

Enligt det här meddelandet misslyckades en integritetskontroll av installationen av Google Kamera eftersom "INSTALLER_NAME" inte matchade "com.android.vending", paketnamnet för Google Play Butik. (Jag försökte installera Google Camera 8.0 med APKMirror Installer-appen, för vad den är värd.) Det här meddelandet lades till i systemloggen av "AppIntegrityManagerServiceImpl", som är en del av Androids nya "App Integrity"-funktion. Enligt koden i AOSP är App Integrity designad för att ge ett extra lager av kontroller ovanpå pakethanterarens befintliga APK-signaturverifiering. App Integrity API verkar använda en uppsättning av Regler för att bestämma om installationen ska tillåtas eller inte. Reglerna tillhandahålls av en systemapp – som vi tror är Google Play-tjänster – och är det lagras i en fil.

Dessutom appintegritet ringer också ringde en annan klass SourceStampVerifier om en "källstämpel" är inbäddad i manifestets metadata. Till exempel, här är vad vi tror är "källstämpeln" från Google Kamera-appens manifest:

<meta-dataandroid: name="com.android.stamp.source"android: value="https://play.google.com/store"/>

Vad vi kan säga används källstämpeln för att verifiera signaturen för paketinstallationsprogrammet. Så du kan till exempel inte lura AppIntegrity att tillåta installationen även om du förfalskade Play Butik som installatör.

Utöver detta kunde vi inte ta reda på exakt hur Google använder AppIntegrity och relaterade API: er för att blockera sidladdningsuppdateringar till apparna Google Kamera och Google Recorder. En snabb undersökning av Google Play Services APK avslöjar att den använder dessa API: er, men koden är för förvirrad för att verkligen förstå allt. Vi hittade till och med katalogen där integritetsreglerna är lagrade — /data/system/integrity_rules — men den var till liten nytta eftersom den bara innehåller serialiserade data. Vi har inte heller hittat något sätt att inaktivera integritetsverifiering (det verkar inte vara så enkelt som bara ändra en inställning), även om vi tror att anledningen till att fabriksåterställning fungerar för vissa är att Google Play Services inte får en chans att initiera sin regeluppsättning för att blockera installationen. Logcat-meddelandet och introduktionen av dessa nya API: er i Android 11 tyder starkt på att allt detta är designat och inte en bugg.

Google har inte offentligt kommenterat sin användning av dessa API: er (inte heller förväntar vi oss att de ska göra det), och de svarade inte när de nåddes för kommentar. Vi har dock några teorier om varför de blockerar sidladdade uppdateringar. För det första kan de skydda människor från att installera fel version av appen för sin enhet. Google levererar specifika versioner av sina appar till specifika Pixel-enheter. Till exempel kan flera versioner av appen Device Personalization Services hittas online. Även om de alla är installerade på Pixel-enheter, var det möjligt vid ett tillfälle förlorar Live Captions-funktionen på Pixel 4 genom att ladda ner en version byggd för en äldre Pixel-enhet. En annan anledning kan vara att "förbättra spårbarheten av appar med avseende på obehörig distribution", som förklarats av Google i klassen SourceStampVerifier.

Hittills är bara ett fåtal av Googles appar som använder app-paketformatet (som Google Camera och Google Recorder) som är blockerar installationer som inte kommer från Play Butik, men vi vet inte om företaget kommer att utöka detta beteende till sina andra appar när de alla byter till AAB-formatet. Vi övervägde också om övergången till AAB-paket gjorde det nödvändigt att implementera App Integrity, men vi upptäckte att Google redan har en lösning att hantera när användare försöker installera en app som inte har alla nödvändiga uppdelningar. Oavsett vad fallet kan vara, tror vi inte att Google har för avsikt att blockera all sidladdning av sina appar, även om dessa verktyg verkligen tillåter dem att göra det.

Tack till utvecklarna vvb2060, aviraxp och Quinny899 för deras hjälp i den här artikeln, och ttackar PNF Software för att ha tillhandahållit oss en licens att använda JEB Decompiler, ett professionellt omvänd ingenjörsverktyg för Android-applikationer.