Image système Android partagée

Cette page présente plusieurs mécanismes que les OEM d'appareils Android peuvent utiliser pour disposer de leur propre image système partagée (SSI) dans l'ensemble de leurs gammes de produits. Il propose également une procédure permettant de baser un SSI détenu par l'OEM sur une image système générique (GSI) créée par AOSP.

Arrière-plan

Avec le projet Treble, Android monolithique a été divisé en deux parties: la partie spécifique au matériel (l'implémentation du fournisseur) et la partie de l'OS générique (le framework de l'OS Android). Le logiciel de chacun est installé dans une partition distincte: la partition du fournisseur pour le logiciel spécifique au matériel et la partition système pour le logiciel d'OS générique. Une interface avec gestion des versions, appelée interface fournisseur (VINTF), est définie et appliquée sur les deux partitions. Ce système de partitionnement vous permet de modifier la partition système sans modifier la partition du fournisseur, et inversement.

Motivation

Le code du framework publié dans AOSP était conforme à l'architecture Treble et a conservé la rétrocompatibilité avec les anciennes implémentations des fournisseurs. Par exemple, une image système générique créée à partir de sources AOSP Android 10 peut s'exécuter sur tout appareil compatible avec Treble équipé d'Android 8 ou version ultérieure. La version d'Android fournie sur les appareils grand public est modifiée par les fournisseurs de SoC et les OEM. (Consultez la section Cycle de vie d'une version Android.) Ces modifications et extensions apportées au framework n'ont pas été écrites pour maintenir la rétrocompatibilité, ce qui a entraîné une complexité et des coûts plus élevés lors de la mise à niveau de l'OS. Les modifications spécifiques à l'appareil augmentent le coût et la complexité de la mise à niveau d'une version du système d'exploitation Android.

Avant Android 11, aucune architecture claire ne permettait aux partenaires de créer des extensions modulaires pour le framework de l'OS Android. Ce document décrit les étapes que les fournisseurs de SoC et les OEM peuvent suivre pour créer un SSI. Cela signifie qu'une seule image, créée à partir des sources du framework de l'OS Android pour être réutilisée sur plusieurs appareils, permet de maintenir la rétrocompatibilité avec les implémentations des fournisseurs et de réduire considérablement la complexité et le coût des mises à niveau de l'OS Android. Pour connaître les étapes spécifiques à suivre pour créer un SSI, consultez la section Étapes suggérées pour les SSI basées sur GSI. Notez que vous n'êtes pas obligé d'effectuer les quatre étapes. Les étapes que vous choisissez (par exemple, uniquement l'étape 1) dépendent de votre implémentation.

Présentation de la SSI

Avec la SSI, les composants logiciels spécifiques au produit et les extensions OEM sont placés dans une nouvelle partition /product. Les composants de la partition /product utilisent une interface stable et bien définie pour interagir avec les composants de la partition /system. Les OEM peuvent choisir de créer un seul SSI ou d'en avoir un petit nombre à utiliser sur plusieurs SKU d'appareils. Lorsqu'une nouvelle version de l'OS Android est publiée, les OEM n'investissent qu'une seule fois pour mettre à jour leurs SSI avec la dernière version d'Android. Ils peuvent réutiliser les SSI pour mettre à jour plusieurs appareils sans mettre à jour la partition /product.

Notez que les OEM et les fournisseurs de SoC créent des SSI qui incluent toutes les fonctionnalités et modifications personnalisées dont un OEM a besoin. Les mécanismes et les bonnes pratiques fournis sur cette page sont destinés aux OEM pour les aider à atteindre ces objectifs clés:

• Réutiliser le SSI pour plusieurs codes SKU d'appareils
• Mettez à jour le système Android avec les extensions modulaires pour faciliter les mises à niveau du système d'exploitation.

L'idée de base consistant à séparer les composants spécifiques au produit dans la partition du produit est semblable à l'idée de Treble consistant à séparer les composants spécifiques au SoC dans la partition du fournisseur. Une interface produit (semblable à VINTF) permet la communication entre SSI et la partition de produits. Notez que, par rapport à la SSI, le terme "composants" décrit toutes les ressources, binaires, textes, bibliothèques, etc. installés sur des images, qui deviennent essentiellement des partitions.

Partitions autour du SSI

La figure 1 montre les partitions autour de SSI, ainsi que les interfaces avec gestion des versions dans les partitions et les règles sur les interfaces. Cette section explique en détail chacune des partitions et interfaces.

Figure 1 : Partitions et interfaces autour de l'SSI

Images et partitions

Les informations de cette section font la distinction entre les termes image et partition.

• Une image est un logiciel conceptuel qui peut être mis à jour indépendamment.
• Une partition est un emplacement de stockage physique pouvant être mis à jour indépendamment.

Les sections de la figure 1 sont définies comme suit:

• SSI (System Software Image) : image commune à un OEM et pouvant exister sur plusieurs appareils. Il n'a aucun composant spécifique au matériel ou au produit. Par définition, tout ce qui se trouve dans un SSI donné est partagé entre tous les appareils qui l'utilisent. L'SSI se compose d'une seule image /system, ou d'une /system et des partitions /system_ext, comme illustré dans la figure 1.

  • La partition /system contient des composants basés sur AOSP, tandis que /system_ext, lorsqu'il est implémenté, contient des extensions et des composants de fournisseurs OEM et de SoC étroitement associés aux composants AOSP. Par exemple, une bibliothèque de framework Java OEM qui fournit des API personnalisées pour les applications de l'OEM s'intègre mieux dans /system_ext que dans la partition /system. Le contenu des partitions /system et /system_ext est créé à partir de sources Android modifiées par l'OEM.

  • La partition /system_ext est facultative, mais il est utile de l'utiliser pour toutes les fonctionnalités et extensions personnalisées étroitement associées aux composants basés sur AOSP. Cette distinction vous aide à identifier les modifications à apporter pour déplacer ces composants de la partition /system_ext vers la partition /product sur une période donnée.

• Produit:ensemble de composants spécifiques au produit ou à l'appareil qui représentent les personnalisations et les extensions OEM de l'OS Android. Placez les composants spécifiques au SoC dans la partition /vendor. Les fournisseurs de SoC peuvent également utiliser la partition /product pour les composants appropriés, tels que ceux qui sont indépendants du SoC. Par exemple, si un fournisseur de SoC fournit un composant indépendant du SoC à ses clients OEM (qui n'est pas obligatoire à expédier avec le produit), il peut placer ce composant dans l'image du produit. L'emplacement d'un composant n'est pas déterminé par sa propriété, mais par son objectif.

• Fournisseur:ensemble de composants spécifiques au SoC.

• ODM:ensemble de composants spécifiques à la carte qui ne sont pas fournis par le SoC. En règle générale, le fournisseur de SoC est propriétaire de l'image du fournisseur, tandis que le fabricant de l'appareil est propriétaire de l'image ODM. Lorsqu'il n'y a pas de partition /odm distincte, les images du fournisseur de SoC et de l'ODM sont fusionnées dans la partition /vendor.

Interfaces entre les images

Il existe deux interfaces principales pour les images de fournisseurs et de produits autour de la SSI:

• Interface fournisseur (VINTF): VINTF est l'interface des composants qui résident chez le fournisseur et les images ODM. Les composants des images du produit et du système ne peuvent interagir avec les images du fournisseur et de l'OEM que via cette interface. Par exemple, une image de fournisseur ne peut pas dépendre d'une partie privée de l'image système, et inversement. Cette valeur est définie à l'origine dans Project Treble, qui divise les images en partitions système et fournisseur. L'interface est décrite à l'aide des mécanismes suivants:

  • HIDL (le HAL de passthrough n'est disponible que pour les modules system et system_ext)
  • AIDL stable
  • Configurations
    • API System Properties
    • API de schéma de fichier de configuration
  • VNDK
  • API du SDK Android
  • Bibliothèque du SDK Java

• Interfaces produit:interface entre le SSI et l'image du produit. La définition d'une interface stable dissocie les composants du produit des composants du système dans un SSI. L'interface du produit nécessite les mêmes interfaces stables que VINTF. Toutefois, seules les API VNDK et Android SDK sont appliquées pour les appareils lancés avec Android 11 (ou version ultérieure).

Activer SSI dans Android 11

Cette section explique comment utiliser les nouvelles fonctionnalités en place pour prendre en charge l'SSI dans Android 11.

La partition /system_ext

La partition /system_ext a été introduite dans Android 11 en tant que partition facultative. (Il s'agit de l'emplacement des composants autres que l'AOSP qui sont étroitement associés aux composants définis par l'AOSP dans la partition /system.) La partition /system_ext est supposée être l'extension de la partition /system propre à l'OEM, sans interface définie entre les deux partitions. Les composants de la partition /system_ext peuvent effectuer des appels d'API privées dans la partition /system, tandis que les composants de la partition /system peuvent effectuer des appels d'API privés dans la partition /system_ext.

Étant donné que les deux partitions sont étroitement liées, elles sont mises à niveau ensemble lorsqu'une nouvelle version d'Android est publiée. Une partition /system_ext créée pour la version précédente d'Android n'a pas besoin d'être compatible avec la partition /system de la prochaine version d'Android.

Pour installer un module dans la partition /system_ext, ajoutez system_ext_specific: true au fichier Android.bp. Pour les appareils qui ne possèdent pas de partition /system_ext, installez ces modules dans le sous-répertoire ./system_ext de la partition /system.

Historique

Voici quelques informations sur la partition /system_ext. L'objectif de conception était de placer tous les composants spécifiques à l'OEM, qu'ils soient courants ou non, dans la partition /product. Toutefois, il n'était pas possible de tous les déplacer en même temps, en particulier lorsque certains composants étaient étroitement liés à la partition /system. Pour déplacer un composant étroitement couplé vers la partition /product, l'interface du produit doit être étendue. Cela nécessitait souvent une refactorisation approfondie du composant lui-même, ce qui demandait beaucoup de temps et d'efforts. La partition /system_ext a été conçue pour héberger temporairement les composants qui ne sont pas prêts à être déplacés vers la partition /product. L'objectif de l'SSI était d'éliminer à terme la partition /system_ext.

Cependant, la partition /system_ext est utile pour conserver la partition /system aussi proche que possible d'AOSP. Avec la SSI, la majeure partie de l'effort de mise à niveau est consacrée aux composants des partitions /system et /system_ext. Lorsque l'image système est créée à partir de sources aussi similaires que possible à celles d'AOSP, vous pouvez concentrer les efforts de mise à niveau sur l'image system_ext.

Dégrouper les composants des partitions /system et /system_ext dans la partition /product

Android 9 a introduit une partition /product associée à la partition /system. Les modules de la partition /product utilisent les ressources système sans aucune restriction, et inversement. Pour permettre l'SSI sous Android 10, les composants du produit sont divisés en partitions /system_ext et /product. La partition /system_ext n'a pas à respecter les restrictions d'utilisation des composants système que la partition /product appliquait dans Android 9. À partir d'Android 10, la partition /product doit être dissociée de la partition /system et doit utiliser des interfaces stables des partitions /system et /system_ext.

L'objectif principal de la partition /system_ext est d'étendre les fonctionnalités du système, plutôt que d'installer des modules de produits groupés, comme décrit dans la section /system_ext partition. Pour ce faire, dissociez les modules spécifiques au produit et déplacez-les dans la partition /product. Le dégroupement des modules spécifiques au produit rend /system_ext commun aux appareils. (Pour en savoir plus, consultez Rendre la partition /system_ext commune.)

Pour dissocier la partition /product des composants système, la partition /product doit avoir la même règle d'application que la partition /vendor qui a déjà été dissociée du projet Treble.

À partir d'Android 11, les interfaces natives et Java pour la partition /product sont appliquées comme décrit ci-dessous. Pour en savoir plus, consultez la section Application des interfaces de partitionnement de produits.

• Interfaces natives:les modules natifs de la partition /product doivent être dissociés des autres partitions. Les seules dépendances autorisées des modules de produits sont certaines bibliothèques VNDK (y compris LLNDK) de la partition /system. Les bibliothèques JNI sur lesquelles les applications du produit dépendent doivent être des bibliothèques NDK.
• Interfaces Java:les modules Java (application) de la partition /product ne peuvent pas utiliser d'API masquées, car elles sont instables. Ces modules ne doivent utiliser que des API publiques et des API système de la partition /system, ainsi que des bibliothèques de SDK Java dans la partition /system ou /system_ext. Vous pouvez définir des bibliothèques de SDK Java pour les API personnalisées.

Étapes recommandées pour l'authentification unique basée sur GSI

Figure 2. Partitions suggérées pour la SSI basée sur GSI

Une image système générique (GSI) est l'image système compilée directement à partir d'AOSP. Il est utilisé pour les tests de conformité Treble (par exemple, CTS-on-GSI) et comme plate-forme de référence que les développeurs d'applications peuvent utiliser pour tester la compatibilité de leurs applications lorsqu'ils ne disposent pas d'un appareil réel exécutant la version requise d'Android.

Les OEM peuvent également utiliser GSI pour créer leur SSI. Comme expliqué dans la section Images et partitions, la SSI comprend l'image système pour les composants définis par l'AOSP et l'image system_ext pour les composants définis par l'OEM. Lorsque GSI est utilisé comme image system, l'OEM peut se concentrer sur l'image system_ext pour la mise à niveau.

Cette section fournit un guide aux OEM qui souhaitent modulariser leurs personnalisations dans les partitions /system_ext et /product tout en utilisant une image système AOSP ou proche d'AOSP. Si les OEM compilent l'image système à partir de sources AOSP, ils peuvent remplacer l'image système qu'ils compilent par la GSI fournie par AOSP. Toutefois, les OEM n'ont pas besoin d'atteindre l'étape finale (utiliser le GSI tel quel) en une seule fois.

Étape 1 : Hériter de generic_system.mk pour l'image système de l'OEM (GSI OEM)

En héritant de generic_system.mk (qui s'appelait mainline_system.mk dans Android 11 et a été renommé generic_system.mk dans AOSP), l'image système (GSI OEM) inclut tous les fichiers de la GSI AOSP. Ces fichiers peuvent être modifiés par les OEM afin que le GSI de l'OEM puisse contenir les fichiers propriétaires de l'OEM en plus des fichiers GSI AOSP. Toutefois, les OEM ne sont pas autorisés à modifier le fichier generic_system.mk lui-même.

Figure 3. Hériter du fichier générique_system.mk pour l'image système de l'OEM

Étape 2 : Faire en sorte que le GSI OEM ait la même liste de fichiers que le GSI AOSP

Le GSI OEM ne peut pas contenir de fichiers supplémentaires à ce stade. Les fichiers propriétaires de l'OEM doivent être déplacés vers les partitions system_ext ou product.

Figure 4. Déplacer les fichiers ajoutés hors du GSI OEM

Étape 3 : Définir une liste d'autorisation pour limiter les fichiers modifiés dans le GSI de l'OEM

Pour vérifier les fichiers modifiés, les OEM peuvent utiliser l'outil compare_images et comparer la GSI AOSP à la GSI OEM. Obtenez le GSI AOSP à partir de la cible de lancement AOSP generic_system_*.

En exécutant régulièrement l'outil compare_images avec le paramètre allowlist, vous pouvez surveiller les différences en dehors de la liste autorisée. Cela évite d'avoir à apporter des modifications supplémentaires aux GSI de l'OEM.

Figure 5. Définir une liste d'autorisation pour réduire la liste des fichiers modifiés dans le GSI de l'OEM

Étape 4 : Faire en sorte que le GSI OEM dispose des mêmes binaires que le GSI AOSP

Nettoyer la liste d'autorisation permet aux OEM d'utiliser le GSI AOSP comme image système pour leurs propres produits. Pour nettoyer la liste d'autorisation, les OEM peuvent soit abandonner leurs modifications dans le GSI OEM, soit les transférer vers AOSP afin que le GSI AOSP les inclue.

Figure 6. Faire en sorte que les GSI OEM ont les mêmes binaires que les GSI AOSP

Définir le SSI pour les OEM

Protéger la partition /system au moment de la compilation

Pour éviter toute modification spécifique au produit dans la partition /system et définir le GSI de l'OEM, les OEM peuvent utiliser une macro de fichier make appelée require-artifacts-in-path pour empêcher toute déclaration de modules système après l'appel de la macro. Consultez l'exemple de création d'un fichier makefile et d'activation de la vérification du chemin d'accès aux artefacts.

Les OEM peuvent définir une liste pour autoriser temporairement l'installation de modules spécifiques aux produits dans la partition /system. Toutefois, la liste doit être vide pour que les GSI de l'OEM soient communs à tous ses produits. Ce processus permet de définir le GSI OEM et peut être indépendant des étapes pour le GSI AOSP.

Appliquer les interfaces produit

Pour garantir que la partition /product n'est pas groupée, les OEM peuvent s'assurer que leurs appareils appliquent les interfaces des produits en définissant PRODUCT_PRODUCT_VNDK_VERSION:= current pour les modules natifs et PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true pour les modules Java. Ces variables sont définies automatiquement si le PRODUCT_SHIPPING_API_LEVEL de l'appareil est supérieur ou égal à 30. Pour en savoir plus, consultez la page Appliquer des interfaces de partition de produits.

Rendre la partition /system_ext commune

La partition /system_ext peut différer d'un appareil à l'autre, car elle peut comporter des modules groupés système spécifiques à l'appareil. Étant donné que le SSI se compose de partitions /system et /system_ext, les différences dans la partition /system_ext empêchent les OEM de définir un SSI. Les OEM peuvent avoir leur propre SSI et peuvent le partager entre plusieurs appareils en supprimant toutes les différences et en rendant la partition /system_ext commune.

Cette section donne des recommandations pour rendre la partition /system_ext commune.

Exposer les API masquées dans la partition système

De nombreuses applications spécifiques au produit ne peuvent pas être installées dans la partition du produit, car elles utilisent des API masquées, qui sont interdites dans la partition du produit. Pour déplacer les applications spécifiques à l'appareil vers la partition de produit, supprimez l'utilisation des API masquées.

Le moyen le plus simple de supprimer les API masquées des applications consiste à trouver les API publiques ou système de remplacement. Si aucune API ne remplace les API masquées, les OEM peuvent contribuer à AOSP pour définir les nouvelles API système de leurs appareils.

Les OEM peuvent également définir des API personnalisées en créant leur propre bibliothèque de SDK Java dans la partition /system_ext. Il peut utiliser des API masquées dans la partition système et fournir les API aux applications dans la partition des produits ou des fournisseurs. Les OEM doivent geler les API liées aux produits pour assurer la rétrocompatibilité.

Inclure le sur-ensemble de tous les APK et ignorer certaines installations de packages pour chaque appareil

Certains packages fournis avec le système ne sont pas communs à tous les appareils. Il peut être difficile de dégrouper ces modules APK pour les déplacer vers le produit ou la partition du fournisseur. En tant que solution provisoire, les OEM peuvent demander à la SSI d'inclure tous les modules, puis de filtrer les indésirables à l'aide d'une propriété SKU (ro.boot.hardware.sku). Pour utiliser le filtre, les OEM superposent les ressources du framework config_disableApkUnlessMatchedSku_skus_list et config_disableApksUnlessMatchedSku_apk_list.

Pour des paramètres plus précis, déclarez un broadcast receiver qui désactive les packages inutiles. Le broadcast receiver appelle setApplicationEnabledSetting pour désactiver le package lorsqu'il reçoit le message ACTION_BOOT_COMPLETED.

Définir une superposition de ressources statiques au lieu d'utiliser une superposition de ressources statiques

Une superposition de ressources statiques manipule les paquets superposés. Toutefois, cela peut empêcher la définition d'un SSI. Assurez-vous donc que les propriétés de l'ARR sont activées et définies correctement. En définissant les propriétés comme suit, les OEM peuvent avoir toutes les superpositions générées automatiquement en tant que RRO.

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

Si une configuration détaillée est requise, définissez une RRO manuellement au lieu de vous appuyer sur une configuration générée automatiquement. Pour en savoir plus, consultez la section Superpositions de ressources d'exécution (RRO). Les OEM peuvent également définir des RRO conditionnels qui dépendent des propriétés système à l'aide des attributs android:requiredSystemPropertyName et android:requiredSystemPropertyValue.

Questions fréquentes

Puis-je définir plusieurs SIS ?

Cela dépend des points communs et des caractéristiques des appareils (ou groupe d'appareils). Les OEM peuvent essayer de rendre la partition system_ext commune, comme décrit dans la section Rendre la partition system_ext commune. Si un groupe d'appareils présente de nombreuses différences, il est préférable de définir plusieurs IDS.

Puis-je modifier generic_system.mk (mainline_system.mk) pour une GSI OEM ?

Non. Toutefois, les OEM peuvent définir un nouveau fichier de compilation pour un GSI OEM qui hérite du fichier generic_system.mk et utiliser le nouveau fichier de compilation à la place. Pour obtenir un exemple, consultez la section Application des interfaces de partitionnement de produits.

Puis-je supprimer des modules de generic_system.mk qui sont en conflit avec mon implémentation ?

Non. GSI dispose d'un ensemble minimal de modules amorçables et testables. Si vous pensez qu'un module n'est pas essentiel, veuillez signaler un bug pour mettre à jour le fichier generic_system.mk dans AOSP.