Cette page a été traduite par l'API Cloud Translation.

Questions fréquentes

Google a-t-il utilisé des OTA A/B sur des appareils ?

Oui. Le nom marketing des mises à jour A/B est « mises à jour transparentes » . Les téléphones Pixel et Pixel XL d'octobre 2016 sont livrés avec A/B, et tous les Chromebooks utilisent la même implémentation update_engine de A/B. L'implémentation du code de plate-forme nécessaire est publique dans Android 7.1 et versions ultérieures.

Pourquoi les OTA A/B sont-elles meilleures ?

Les OTA A/B offrent une meilleure expérience utilisateur lors de la prise de mises à jour. Les mesures des mises à jour de sécurité mensuelles montrent que cette fonctionnalité a déjà fait ses preuves : en mai 2017, 95 % des propriétaires de Pixel exécutaient la dernière mise à jour de sécurité après un mois, contre 87 % des utilisateurs de Nexus, et les utilisateurs de Pixel mettent à jour plus tôt que les utilisateurs de Nexus. Les échecs de mise à jour des blocs lors d'une OTA n'entraînent plus un périphérique qui ne démarre pas ; jusqu'à ce que la nouvelle image système ait démarré avec succès, Android conserve la possibilité de revenir à l'image système de travail précédente.

Comment A/B a-t-il affecté les tailles de partition Pixel 2016 ?

Le tableau suivant contient des détails sur la configuration A/B d'expédition par rapport à la configuration non-A/B testée en interne :

Tailles de partition de pixels	UN B	Non-A/B
Chargeur de démarrage	50*2	50
Botte	32*2	32
Récupération	0	32
Cache	0	100
Radio	70*2	70
Fournisseur	300*2	300
Système	2048*2	4096
Total	5000	4680

Les mises à jour A/B nécessitent une augmentation de seulement 320 Mo en flash, avec une économie de 32 Mo grâce à la suppression de la partition de récupération et 100 Mo supplémentaires préservés en supprimant la partition de cache. Cela équilibre le coût des partitions B pour le chargeur de démarrage, la partition de démarrage et la partition radio. La taille de la partition du fournisseur a doublé (la grande majorité de la taille a augmenté). L'image système A/B du Pixel fait la moitié de la taille de l'image système non A/B d'origine.

Pour les variantes Pixel A/B et non-A/B testées en interne (uniquement A/B expédié), l'espace utilisé ne différait que de 320 Mo. Sur un appareil de 32 Go, cela représente un peu moins de 1 %. Pour un appareil de 16 Go, cela serait inférieur à 2 %, et pour un appareil de 8 Go, près de 4 % (en supposant que les trois appareils avaient la même image système).

Pourquoi n'avez-vous pas utilisé SquashFS ?

Nous avons expérimenté SquashFS mais n'avons pas réussi à atteindre les performances souhaitées pour un appareil haut de gamme. Nous n'utilisons ni ne recommandons SquashFS pour les appareils portables.

Plus précisément, SquashFS a permis d'économiser environ 50 % de taille sur la partition système, mais l'écrasante majorité des fichiers bien compressés étaient des fichiers .odex précompilés. Ces fichiers avaient des taux de compression très élevés (approchant les 80 %), mais le taux de compression pour le reste de la partition système était bien inférieur. De plus, SquashFS dans Android 7.0 a soulevé les problèmes de performances suivants :

Le Pixel a un flash très rapide par rapport aux appareils précédents, mais pas un grand nombre de cycles de CPU disponibles, donc lire moins d'octets à partir du flash mais avoir besoin de plus de CPU pour les E/S était un goulot d'étranglement potentiel.
Les modifications d'E/S qui fonctionnent bien sur un test de référence artificiel exécuté sur un système non chargé ne fonctionnent parfois pas bien dans des cas d'utilisation réels sous une charge réelle (comme la cryptographie sur Nexus 6).
L'analyse comparative a montré des régressions de 85 % à certains endroits.

À mesure que SquashFS mûrit et ajoute des fonctionnalités pour réduire l'impact sur le processeur (comme une liste blanche de fichiers couramment consultés qui ne doivent pas être compressés), nous continuerons à l'évaluer et à proposer des recommandations aux fabricants d'appareils.

Comment avez-vous réduit de moitié la taille de la partition système sans SquashFS ?

Les applications sont stockées dans des fichiers .apk, qui sont en réalité des archives ZIP. Chaque fichier .apk contient un ou plusieurs fichiers .dex contenant le bytecode Dalvik portable. Un fichier .odex (.dex optimisé) vit séparément du fichier .apk et peut contenir du code machine spécifique à l'appareil. Si un fichier .odex est disponible, Android peut exécuter des applications à des vitesses compilées à l'avance sans avoir à attendre que le code soit compilé à chaque lancement de l'application. Un fichier .odex n'est pas strictement nécessaire : Android peut en fait exécuter le code .dex directement via l'interprétation ou la compilation Just-In-Time (JIT), mais un fichier .odex offre la meilleure combinaison de vitesse de lancement et de vitesse d'exécution si l'espace est disponible.

Exemple : Pour le fichier install-files.txt d'un Nexus 6P exécutant Android 7.1 avec une taille totale d'image système de 2 628 Mo (2755792836 octets), la répartition des principaux contributeurs à la taille globale de l'image système par type de fichier est la suivante :

.odex	1391770312 octets	50,5%
.apk	846878259 octets	30,7%
.so (code natif C/C++)	202162479 octets	7,3%
Fichiers .oat/images .art	163892188 octets	5,9%
Polices	38952361 octets	1,4%
données locales de l'ICU	27468687 octets	0,9%

Ces chiffres sont également similaires pour d'autres appareils, donc sur les appareils Nexus/Pixel, les fichiers .odex occupent environ la moitié de la partition système. Cela signifiait que nous pouvions continuer à utiliser ext4 mais écrire les fichiers .odex sur la partition B en usine, puis les copier dans /data au premier démarrage. Le stockage réel utilisé avec ext4 A/B est identique à SquashFS A/B, car si nous avions utilisé SquashFS, nous aurions expédié les fichiers .odex préoptés sur system_a au lieu de system_b.

La copie des fichiers .odex dans /data ne signifie-t-elle pas que l'espace économisé sur /system est perdu sur /data ?

Pas exactement. Sur Pixel, la majeure partie de l'espace occupé par les fichiers .odex est destinée aux applications, qui existent généralement sur /data . Ces applications prennent les mises à jour de Google Play, de sorte que les fichiers .apk et .odex sur l'image système sont inutilisés pendant la majeure partie de la durée de vie de l'appareil. Ces fichiers peuvent être entièrement exclus et remplacés par de petits fichiers .odex basés sur un profil lorsque l'utilisateur utilise réellement chaque application (ne nécessitant ainsi aucun espace pour les applications que l'utilisateur n'utilise pas). Pour plus de détails, reportez-vous à la conférence Google I/O 2016 The Evolution of Art .

La comparaison est difficile pour plusieurs raisons principales :

Les applications mises à jour par Google Play ont toujours eu leurs fichiers .odex sur /data dès qu'elles reçoivent leur première mise à jour.
Les applications que l'utilisateur n'exécute pas n'ont pas du tout besoin d'un fichier .odex.
La compilation basée sur le profil génère des fichiers .odex plus petits que la compilation anticipée (car la première optimise uniquement le code critique en termes de performances).

Pour plus de détails sur les options de réglage disponibles pour les OEM, voir Configuration d'ART .

N'y a-t-il pas deux copies des fichiers .odex sur /data ?

C'est un peu plus compliqué... Une fois la nouvelle image système écrite, la nouvelle version de dex2oat est exécutée sur les nouveaux fichiers .dex pour générer les nouveaux fichiers .odex. Cela se produit alors que l'ancien système est toujours en cours d'exécution, de sorte que l'ancien et le nouveau fichier .odex sont tous deux sur /data en même temps.

Le code dans OtaDexoptService ( frameworks/base/+/main/services/core/java/com/android/server/pm/OtaDexoptService.java ) appelle getAvailableSpace avant d'optimiser chaque package pour éviter un remplissage excessif /data . Notez que ce qui est disponible ici est toujours conservateur : il s'agit de la quantité d'espace restant avant d'atteindre le seuil d'espace faible habituel du système (mesuré à la fois en pourcentage et en nombre d'octets). Donc, si /data est plein, il n'y aura pas deux copies de chaque fichier .odex. Le même code a également un BULK_DELETE_THRESHOLD : si l'appareil est sur le point de remplir l'espace disponible (comme je viens de le décrire), les fichiers .odex appartenant aux applications qui ne sont pas utilisées sont supprimés. C'est un autre cas sans deux copies de chaque fichier .odex.

Dans le pire des cas, où /data est complètement plein, la mise à jour attend que le périphérique ait redémarré sur le nouveau système et n'ait plus besoin des fichiers .odex de l'ancien système. Le PackageManager gère cela : ( frameworks/base/+/main/services/core/java/com/android/server/pm/PackageManagerService.java#7215 ). Une fois le nouveau système démarré avec succès, installd ( frameworks/native/+/main/cmds/installd/dexopt.cpp#2422 ) peut supprimer les fichiers .odex utilisés par l'ancien système, ramenant ainsi le périphérique à l'état stable. où il n'y a qu'un seul exemplaire.

Ainsi, bien qu'il soit possible que /data contienne deux copies de tous les fichiers .odex, (a) cela est temporaire et (b) ne se produit que si vous disposiez de toute façon de beaucoup d'espace libre sur /data . Sauf lors d'une mise à jour, il n'y a qu'une seule copie. Et dans le cadre des fonctionnalités générales de robustesse d'ART, il ne remplira jamais /data de fichiers .odex de toute façon (car cela poserait également un problème sur un système non-A/B).

Toute cette écriture/copie n'augmente-t-elle pas l'usure du flash ?

Seule une petite partie du flash est réécrite : une mise à jour complète du système Pixel écrit environ 2,3 Gio. (Les applications sont également recompilées, mais cela est également vrai pour les applications non A/B.) Traditionnellement, les OTA complets basés sur des blocs écrivaient une quantité similaire de données, les taux d'usure du flash devraient donc être similaires.

Le flashage de deux partitions système augmente-t-il le temps de flashage en usine ?

Non. Le pixel n'a pas augmenté la taille de l'image système (il a simplement divisé l'espace sur deux partitions).

Le fait de conserver les fichiers .odex sur B ne ralentit-il pas le redémarrage après la réinitialisation des données d'usine ?

Oui. Si vous avez réellement utilisé un appareil, effectué une OTA et effectué une réinitialisation des données d'usine, le premier redémarrage sera plus lent qu'il ne le serait autrement (1 min 40 s contre 40 s sur un Pixel XL), car les fichiers .odex auront été perdus. B après le premier OTA et ne peut donc pas être copié dans /data . C'est le compromis.

La réinitialisation des données d'usine devrait être une opération rare par rapport au démarrage normal, le temps nécessaire est donc moins important. (Cela n'affecte pas les utilisateurs ou les réviseurs qui obtiennent leur appareil en usine, car dans ce cas, la partition B est disponible.) L'utilisation du compilateur JIT signifie que nous n'avons pas besoin de tout recompiler, donc ce n'est pas aussi grave que vous. pourrait penser. Il est également possible de marquer les applications comme nécessitant une compilation préalable en utilisant coreApp="true" dans le manifeste : ( frameworks/base/+/main/packages/SystemUI/AndroidManifest.xml#23 ). Ceci est actuellement utilisé par system_server car il n'est pas autorisé à JIT pour des raisons de sécurité.

Le fait de conserver les fichiers .odex sur /data plutôt que sur /system ne provoque-t-il pas un redémarrage après un ralentissement OTA ?

Non. Comme expliqué ci-dessus, le nouveau dex2oat est exécuté pendant que l'ancienne image système est toujours en cours d'exécution pour générer les fichiers qui seront nécessaires au nouveau système. La mise à jour n'est pas considérée comme disponible tant que ce travail n'a pas été effectué.

Pouvons-nous (devrions-nous) expédier un appareil A/B de 32 Gio ? 16 Go ? 8 Go ?

32 Go fonctionnent bien, comme cela a été prouvé sur Pixel, et 320 Mo sur 16 Go signifient une réduction de 2 %. De même, 320 Mo sur 8 Go, soit une réduction de 4 %. Évidemment, A/B ne serait pas le choix recommandé sur les appareils dotés de 4 Go, car la surcharge de 320 Mo représente près de 10 % de l'espace total disponible.

AVB2.0 nécessite-t-il des OTA A/B ?

Non. Android Verified Boot a toujours nécessité des mises à jour par blocs, mais pas nécessairement des mises à jour A/B.

Les OTA A/B nécessitent-ils AVB2.0 ?

Non.

Les OTA A/B brisent-ils la protection anti-rollback d'AVB2.0 ?

Non. Il y a une certaine confusion ici, car si un système A/B ne parvient pas à démarrer dans la nouvelle image système, il reviendra automatiquement (après un certain nombre de tentatives déterminé par votre chargeur de démarrage) à l'image système "précédente". Le point clé ici est que "précédent" au sens A/B est en fait toujours l'image système "actuelle". Dès que l'appareil démarre avec succès une nouvelle image, la protection contre la restauration entre en jeu et garantit que vous ne pouvez pas revenir en arrière. Mais jusqu'à ce que vous ayez réellement démarré la nouvelle image, la protection contre la restauration ne la considère pas comme l'image système actuelle.

Si vous installez une mise à jour pendant que le système est en cours d'exécution, n'est-ce pas lent ?

Avec les mises à jour non-A/B, l'objectif est d'installer la mise à jour le plus rapidement possible car l'utilisateur attend et ne peut pas utiliser son appareil pendant l'application de la mise à jour. Avec les mises à jour A/B, c’est le contraire qui est vrai ; étant donné que l'utilisateur utilise toujours son appareil, l'objectif est d'avoir le moins d'impact possible, la mise à jour est donc délibérément lente. Via la logique du client de mise à jour du système Java (qui pour Google est GmsCore, le package de base fourni par GMS), Android tente également de choisir un moment où les utilisateurs n'utilisent pas du tout leurs appareils. La plate-forme prend en charge la pause/reprise de la mise à jour, et le client peut l'utiliser pour suspendre la mise à jour si l'utilisateur commence à utiliser l'appareil et la reprendre lorsque l'appareil est à nouveau inactif.

Il y a deux phases lors de la réalisation d'un OTA, clairement indiquées dans l'interface utilisateur comme l'étape 1 sur 2 et l'étape 2 sur 2 sous la barre de progression. L'étape 1 correspond à l'écriture des blocs de données, tandis que l'étape 2 correspond à la précompilation des fichiers .dex. Ces deux phases sont assez différentes en termes d’impact sur les performances. La première phase est constituée de simples E/S. Cela nécessite peu de ressources (RAM, CPU, E/S) car il s'agit simplement de copier lentement les blocs.

La deuxième phase exécute dex2oat pour précompiler la nouvelle image système. Cela a évidemment des limites moins claires quant à ses exigences car il compile des applications réelles. Et la compilation d'une application volumineuse et complexe demande évidemment beaucoup plus de travail que celle d'une application petite et simple ; alors que dans la phase 1, il n'y a pas de blocs de disque plus grands ou plus complexes que d'autres.

Le processus est similaire à celui où Google Play installe une mise à jour d'application en arrière-plan avant d'afficher la notification de mise à jour des 5 applications , comme cela se fait depuis des années.

Que se passe-t-il si un utilisateur attend réellement la mise à jour ?

L'implémentation actuelle dans GmsCore ne fait pas de distinction entre les mises à jour en arrière-plan et les mises à jour initiées par l'utilisateur, mais elle pourrait le faire à l'avenir. Dans le cas où l'utilisateur a explicitement demandé l'installation de la mise à jour ou regarde l'écran de progression de la mise à jour, nous donnerons la priorité au travail de mise à jour en supposant qu'il attend activement qu'elle se termine.

Que se passe-t-il en cas d'échec de l'application d'une mise à jour ?

Avec les mises à jour non A/B, si une mise à jour ne s'appliquait pas, l'utilisateur se retrouvait généralement avec un appareil inutilisable. La seule exception était si l'échec se produisait avant même le démarrage d'une application (parce que le package n'avait pas pu être vérifié, par exemple). Avec les mises à jour A/B, l’échec de l’application d’une mise à jour n’affecte pas le système en cours d’exécution. La mise à jour peut simplement être réessayée plus tard.

Quels systèmes sur puce (SoC) prennent en charge A/B ?

Au 15/03/2017, nous disposons des informations suivantes :

	Android 7.x et versions antérieures	Android 8.x et versions ultérieures
Qualcomm	Selon les demandes OEM	Tous les chipsets bénéficieront d'un support
Médiatek	Selon les demandes OEM	Tous les chipsets bénéficieront d'un support

Pour plus de détails sur les horaires, vérifiez auprès de vos contacts SoC. Pour les SoC non répertoriés ci-dessus, contactez directement votre SoC.