Ecco perché non puoi caricare localmente gli aggiornamenti su Google Camera and Recorder

Quando Google ha lanciato Pixel 5 a ottobre, eravamo entusiasti di mettere le mani sulle sue nuove app. (Il telefono stesso è piuttosto bello, anche.) Con il lancio di Pixel 5 sono arrivate nuove versioni di la fotocamera di Google E Registratore Google app che abbiamo condiviso con la community. Tuttavia, quando molti utenti di dispositivi Pixel meno recenti hanno provato a eseguire il sideload degli aggiornamenti, hanno riscontrato un errore (mostrato sopra). Stranamente, non tutti hanno avuto problemi con l'installazione degli aggiornamenti. Alcuni sono riusciti a installarli senza problemi, mentre altri hanno dovuto ripristinare le impostazioni di fabbrica solo per poter installare le nuove versioni. A causa della natura apparentemente casuale di questo problema, molti lo hanno attribuito a un bug. Siamo abbastanza sicuri ora che questo problema non derivi da un bug ma piuttosto dall'utilizzo da parte di Google di una nuova API in Android 11 per bloccare gli aggiornamenti di sideload.

Se provi a eseguire il sideload di Google Camera 8.0 o versione successiva o Google Recorder 2.0 o versione successiva su un dispositivo Pixel con Android 11, vedrai un messaggio di errore che indica che la verifica non è riuscita. Anche se provi a eseguire il sideload dell'APK utilizzando un comando shell, non otterrai un motivo più specifico per l'errore di installazione. Il codice di ritorno dell'installazione che ti verrà fornito è "INSTALL_FAILED_VERIFICATION_FAILURE", che purtroppo non ti dice perché la verifica non ha esito positivo. Esaminando il logcat, possiamo scoprire esattamente perché la verifica fallisce:

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]

Secondo questo messaggio, un controllo di integrità dell'installazione di Google Camera non è riuscito perché "INSTALLER_NAME" non corrisponde a "com.android.vending", il nome del pacchetto per Google Play Store. (Stavo tentando di installare Google Camera 8.0 utilizzando l'app APKMirror Installer, per quello che vale.) Questo messaggio è stato aggiunto al registro di sistema da "AppIntegrityManagerServiceImpl", che fa parte della nuova funzionalità "App Integrity" di Android. Secondo il codice in AOSP, App Integrity è progettato per fornire un ulteriore livello di controlli oltre alla verifica della firma APK esistente del gestore pacchetti. L'API App Integrity sembra utilizzare un set di Regole per decidere se consentire o negare l'installazione. Le regole sono fornite da un'app di sistema, che riteniamo essere Google Play Services, e lo sono memorizzato in un file.

Inoltre, l'integrità dell'app anche chiamate un'altra classe chiamata SourceStampVerifier se un "timbro sorgente" è incorporato nei metadati del manifest. Ad esempio, ecco quello che crediamo sia il "timbro sorgente" del manifest dell'app Google Fotocamera:

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

Da quello che possiamo dire, il timbro sorgente viene utilizzato per verificare la firma del programma di installazione del pacchetto. Quindi, ad esempio, non puoi ingannare AppIntegrity facendogli consentire l'installazione anche se tu ha falsificato il Play Store come installatore.

Oltre a ciò, non siamo riusciti a scoprire esattamente come Google utilizza AppIntegrity e le relative API per bloccare il sideload degli aggiornamenti alle app Google Camera e Google Recorder. Un rapido esame dell'APK di Google Play Services rivela che utilizza queste API, ma il codice è troppo confuso per dare davvero un senso a tutto. Abbiamo anche trovato la directory in cui sono archiviate le regole di integrità — /data/system/integrity_rules — ma è stata di scarsa utilità perché contiene solo dati serializzati. Inoltre, non abbiamo trovato un modo per disabilitare la verifica dell'integrità (non sembra essere così semplice come basta modifica di un'impostazione), anche se riteniamo che il motivo per cui il ripristino dei dati di fabbrica funzioni per alcuni è che Google Play Services non ha la possibilità di inizializzare il proprio set di regole per bloccare l'installazione. Il messaggio logcat e l'introduzione di queste nuove API in Android 11 suggeriscono fortemente che tutto ciò è dovuto alla progettazione e non a un bug.

Google non ha commentato pubblicamente l'utilizzo di queste API (né ci aspettiamo che lo facciano) e non ha risposto quando è stato raggiunto per un commento. Tuttavia, abbiamo alcune teorie sul motivo per cui stanno bloccando gli aggiornamenti trasferiti lateralmente. Innanzitutto, potrebbero proteggere le persone dall'installazione della versione sbagliata dell'app per il proprio dispositivo. Google fornisce versioni specifiche delle sue app a specifici dispositivi Pixel. Ad esempio, online è possibile trovare diverse versioni dell'app Servizi di personalizzazione del dispositivo. Anche se sono tutti installabili sui dispositivi Pixel, a un certo punto è stato possibile farlo perdere la funzione Live Captions sul Pixel 4 scaricando una versione creata per un dispositivo Pixel precedente. Un altro motivo potrebbe essere quello di "migliorare la tracciabilità delle app rispetto alla distribuzione non autorizzata", come spiegato da Google nella classe SourceStampVerifier.

Finora, solo alcune delle app di Google che utilizzano il formato app bundle (come Google Camera e Google Recorder) lo sono bloccando le installazioni non provenienti dal Play Store, ma non sappiamo se l'azienda estenderà questo comportamento alle altre sue app una volta passati tutti al formato AAB. Abbiamo anche considerato se il passaggio agli app bundle richiedesse l'implementazione dell'integrità dell'app, ma abbiamo già scoperto che Google ha una soluzione da gestire quando gli utenti tentano di installare un'app che non dispone di tutte le suddivisioni richieste. In ogni caso, non crediamo che Google intenda bloccare completamente il sideload delle sue app, anche se questi strumenti certamente glielo consentono.

Grazie agli sviluppatori vvb2060, aviraxp e Quinny899 per la loro assistenza in questo articolo eRingraziamo PNF Software per averci fornito la licenza d'uso Decompilatore JEB, uno strumento di reverse engineering di livello professionale per applicazioni Android.