Si vous avez vu une erreur « échec de la vérification » lors du chargement latéral d'une mise à jour des applications Google Camera ou Recorder, lisez ceci pour savoir pourquoi.
Lorsque Google a lancé le Pixel 5 en octobre, nous étions ravis de mettre la main sur ses nouvelles applications. (Le téléphone lui-même c'est plutôt cool, aussi.) Avec le lancement du Pixel 5, de nouvelles versions de la caméra Google et Enregistreur Google applications que nous avons partagées avec la communauté. Cependant, lorsque de nombreux utilisateurs d'anciens appareils Pixel ont tenté de télécharger les mises à jour, ils ont rencontré une erreur (illustré ci-dessus). Bizarrement, tout le monde n’a pas eu de problèmes pour installer les mises à jour. Certains ont pu les installer très bien, tandis que d’autres ont dû réinitialiser les paramètres d’usine pour pouvoir installer les nouvelles versions. En raison de la nature apparemment aléatoire de ce problème, beaucoup l'ont attribué à un bug. Nous sommes désormais convaincus que ce problème ne provient pas d'un bug mais plutôt de l'utilisation par Google d'une nouvelle API dans Android 11 pour bloquer le chargement latéral des mises à jour.
Si vous essayez de télécharger Google Camera 8.0 ou version ultérieure ou Google Recorder 2.0 ou version ultérieure sur un appareil Pixel exécutant Android 11, vous verrez un message d'erreur indiquant que la vérification n'a pas réussi. Même si vous essayez de charger l'APK à l'aide d'une commande shell, vous n'obtiendrez pas de raison plus spécifique de l'échec de l'installation. Le code retour d'installation qui vous sera fourni est "INSTALL_FAILED_VERIFICATION_FAILURE", ce qui malheureusement ne vous explique pas pourquoi la vérification n'aboutit pas. En examinant le logcat, nous pouvons savoir exactement pourquoi la vérification échoue :
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]Selon ce message, une vérification d'intégrité de l'installation de Google Camera a échoué car le "INSTALLER_NAME" ne correspondait pas à "com.android.vending", le nom du package du Google Play Store. (J'essayais d'installer Google Camera 8.0 à l'aide de l'application APKMirror Installer, pour ce que ça vaut.) Ce message a été ajouté au journal système par "AppIntegrityManagerServiceImpl", qui fait partie de la nouvelle fonctionnalité "App Integrity" d'Android. Selon le code de l'AOSP, App Integrity est conçu pour fournir une couche de contrôle supplémentaire en plus de la vérification de la signature APK existante du gestionnaire de packages. L'API App Integrity semble utiliser un ensemble de Règles pour décider d'autoriser ou de refuser l'installation. Les règles sont fournies par une application système (que nous pensons être les services Google Play) et sont stocké dans un fichier.
De plus, l'intégrité des applications appelle aussi une autre classe appelée SourceStampVerifier si un « tampon source » est intégré dans les métadonnées du manifeste. Par exemple, voici ce que nous pensons être le « cachet source » du manifeste de l'application Appareil photo Google :
<meta-dataandroid: name="com.android.stamp.source"android: value="https://play.google.com/store"/>D'après ce que nous pouvons dire, le cachet source est utilisé pour vérifier la signature de l'installateur du package. Ainsi, par exemple, vous ne pouvez pas tromper AppIntegrity pour qu'il autorise l'installation même si vous usurpé le Play Store en tant qu'installateur.
Au-delà de cela, nous n'avons pas pu savoir exactement comment Google utilise AppIntegrity et les API associées pour bloquer le chargement latéral des mises à jour des applications Google Camera et Google Recorder. Un examen rapide de l'APK des services Google Play révèle qu'il utilise ces API, mais le code est trop obscurci pour vraiment donner un sens à tout. Nous avons même trouvé le répertoire où sont stockées les règles d'intégrité — /data/system/integrity_rules — mais il s'est avéré de peu d'utilité car il ne contient que des données sérialisées. Nous n'avons pas non plus trouvé de moyen de désactiver la vérification de l'intégrité (cela ne semble pas être aussi simple que de simplement changer un paramètre), même si nous pensons que la réinitialisation d'usine fonctionne pour certains, c'est parce que les services Google Play n'ont pas la possibilité d'initialiser leur ensemble de règles pour bloquer l'installation. Le message logcat et l’introduction de ces nouvelles API dans Android 11 suggèrent fortement que tout cela est intentionnel et non un bug.
Google n'a pas commenté publiquement son utilisation de ces API (et nous ne nous attendons pas à ce qu'ils le fassent), et ils n'ont pas répondu lorsqu'ils ont été contactés pour commenter. Nous avons cependant quelques théories sur les raisons pour lesquelles ils bloquent les mises à jour téléchargées. Premièrement, ils pourraient empêcher les utilisateurs d’installer la mauvaise version de l’application pour leur appareil. Google propose des versions spécifiques de ses applications à des appareils Pixel spécifiques. Par exemple, plusieurs versions de l'application Device Personality Services peuvent être trouvées en ligne. Même s'ils peuvent tous être installés sur les appareils Pixel, il était possible à un moment donné de perdre la fonctionnalité Live Captions sur le Pixel 4 en téléchargeant une version conçue pour un ancien appareil Pixel. Une autre raison pourrait être "d'améliorer la traçabilité des applications en matière de distribution non autorisée", comme l'explique Google dans la classe SourceStampVerifier.
Jusqu'à présent, seules quelques applications de Google utilisant le format App Bundle (comme Google Camera et Google Recorder) sont disponibles. bloquer les installations non-Play Store, mais nous ne savons pas si l'entreprise étendra ce comportement à ses autres applications une fois qu'ils seront tous passés au format AAB. Nous avons également examiné si le passage aux offres groupées nécessitait la mise en œuvre de l'intégrité des applications, mais nous avons constaté que Google avait déjà a une solution à gérer lorsque les utilisateurs tentent d'installer une application qui ne dispose pas de toutes les divisions requises. Quoi qu'il en soit, nous ne pensons pas que Google ait l'intention de bloquer tout chargement latéral de ses applications, même si ces outils leur permettent certainement de le faire.
Merci aux développeurs vvb2060, aviraxp et Quinny899 pour leur aide dans cet article, et tmerci à PNF Software de nous avoir fourni une licence d'utilisation Décompilateur JEB, un outil d'ingénierie inverse de qualité professionnelle pour les applications Android.