Image système partagée Android

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) sur leurs gammes de produits. Il propose également une procédure pour baser un SSI appartenant à un OEM sur une image système générique (GSI) créée par AOSP.

Arrière-plan

Avec Project Treble, Android monolithique a été divisé en deux parties : la partie spécifique au matériel (l'implémentation du fournisseur) et la partie OS générique (le framework Android OS). 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 OS générique. Une interface versionnée, appelée interface du fournisseur (VINTF), est définie et appliquée aux deux partitions. En utilisant ce système de partitionnement, vous pouvez modifier la partition système sans modifier la partition du fournisseur, et vice versa.

Motivation

Le code du framework publié dans AOSP est conforme à l'architecture Treble et reste rétrocompatible avec les anciennes implémentations du fournisseur. Par exemple, une image système générique créée à partir de sources AOSP Android 10 peut s'exécuter sur n'importe quel appareil compatible avec Treble fonctionnant sous 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 Cycle de vie d'une version Android.) Ces modifications et extensions apportées au framework n'ont pas été conçues pour maintenir la rétrocompatibilité, ce qui s'est traduit par une complexité accrue et un coût plus élevé lors de la mise à niveau de l'OS. Les modifications et les changements spécifiques aux appareils augmentent le coût et la complexité de la mise à niveau d'une version d'Android.

Avant Android 11, il n'existait pas d'architecture claire permettant 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 une SSI. Cela signifie qu'une seule image, créée à partir des sources du framework Android OS 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 d'Android OS. Pour connaître les étapes spécifiques à suivre pour créer une SSI, consultez la section Étapes suggérées pour une SSI basée sur un GSI. Notez que vous n'avez pas besoin de suivre les quatre étapes. Les étapes que vous choisissez (par exemple, uniquement l'étape 1) dépendent de votre implémentation.

Présentation de l'SSI

Avec SSI, les composants logiciels spécifiques aux produits 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 SSI ou d'en utiliser un petit nombre pour plusieurs SKU d'appareils. Lorsqu'une nouvelle version de l'OS Android est publiée, les OEM n'ont besoin d'investir qu'une seule fois pour mettre à jour leurs SSI vers 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 atteindre les objectifs clés suivants :

• Réutiliser le SSI sur plusieurs SKU d'appareils
• Mettez à jour le système Android avec les extensions modulaires pour faciliter les mises à niveau de l'OS.

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

Partitions autour de SSI

La figure 1 montre les partitions autour de SSI, ainsi que les interfaces versionnées 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'identité numérique souveraine

Images et partitions

Les informations de cette section permettent de distinguer les termes image et partition.

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

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

• SSI : la SSI est l'image commune à un OEM et peut exister sur plusieurs appareils. Il ne comporte 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. Le SSI se compose d'une seule image /system ou d'un /system et des partitions /system_ext, comme illustré sur la figure 1.

  • La partition /system contient des composants basés sur AOSP, tandis que /system_ext, lorsqu'elle est implémentée, contient des extensions et des composants OEM et de fournisseur de SoC étroitement liés aux composants AOSP. Par exemple, une bibliothèque de framework Java OEM qui fournit des API personnalisées pour les propres applications de l'OEM convient mieux à la partition /system_ext qu'à 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 lié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 au fil du temps.

• Produit : ensemble de composants spécifiques à un produit ou à un 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 peut être inclus ou non dans 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 sa finalité.

• 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 du 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 l'identité numérique souveraine :

• Interface du fournisseur (VINTF) : VINTF est l'interface des composants qui résident dans les images du fournisseur et de l'ODM. Les composants des images produit et système ne peuvent interagir avec les images du fournisseur et de l'ODM que par le biais de 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 définition est initialement définie dans Project Treble, qui a divisé les images en partitions système et fournisseur. L'interface est décrite à l'aide des mécanismes suivants :

  • HIDL (Passthrough HAL n'est disponible que pour les modules system et system_ext)
  • AIDL stable
  • Configurations
    • API des propriétés système
    • API de schéma de fichier de configuration
  • VNDK
  • API du SDK Android
  • Bibliothèque du SDK Java

• Interfaces produit : l'interface produit est l'interface entre l'ISS et l'image du produit. La définition d'une interface stable découple les composants du produit de ceux du système dans une SSI. L'interface produit nécessite les mêmes interfaces stables que VINTF. Toutefois, seules les API VNDK et SDK Android sont appliquées aux appareils lancés avec Android 11 (et versions ultérieures).

Activer SSI dans Android 11

Cette section explique comment utiliser les nouvelles fonctionnalités mises en place pour prendre en charge les identités numériques auto-souveraines dans Android 11.

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 non-AOSP étroitement liés aux composants définis par AOSP dans la partition /system.) La partition /system_ext est considérée comme l'extension spécifique à l'OEM de la partition /system, sans interface définie entre les deux partitions. Les composants de la partition /system_ext peuvent effectuer des appels d'API privés dans la partition /system, et 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 toutes les deux mises à niveau 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 disposent 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 les déplacer tous en même temps, surtout lorsque certains composants étaient étroitement liés à la partition /system. Pour déplacer un composant étroitement couplé vers la partition /product, l'interface produit doit être étendue. Cela nécessitait souvent de refactoriser le composant lui-même de manière approfondie, ce qui demandait beaucoup de temps et d'efforts. La partition /system_ext a été créée pour héberger temporairement les composants qui ne sont pas encore prêts à être déplacés vers la partition /product. L'objectif de l'ISS était d'éliminer à terme la partition /system_ext.

Toutefois, la partition /system_ext est utile pour maintenir la partition /system aussi proche que possible d'AOSP. Avec 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 semblables que possible à celles d'AOSP, vous pouvez concentrer vos 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 rendre SSI possible dans 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 sur l'utilisation des composants système que la partition /product avait 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. En dissociant les modules spécifiques au produit, /system_ext devient commun aux appareils. (Pour en savoir plus, consultez Rendre la partition /system_ext commune.)

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

À 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 Appliquer les interfaces de partition de produits.

• Interfaces natives : les modules natifs de la partition /product doivent être dissociés des autres partitions. Les seules dépendances autorisées à partir des modules produit sont certaines bibliothèques VNDK (y compris LLNDK) de la partition /system. Les bibliothèques JNI dont dépendent les applications produit 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 les API publiques et les API système de la partition /system, ainsi que les bibliothèques du 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 suggérées pour l'SSI basée sur GSI

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

Une image système générique (GSI) est l'image système créée directement à partir d'AOSP. Elle est utilisée 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 Images et partitions, la SSI se compose de l'image système pour les composants définis par AOSP et de l'image system_ext pour les composants définis par l'OEM. Lorsque la GSI est utilisée 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 créent l'image système à partir de sources AOSP, ils peuvent remplacer l'image système qu'ils créent par la GSI fournie par AOSP. Toutefois, les OEM n'ont pas besoin d'atteindre l'étape finale (utiliser la GSI telle quelle) d'un seul coup.

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

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 (OEM GSI) inclut tous les fichiers de l'AOSP GSI. Ces fichiers peuvent être modifiés par les OEM, de sorte que la GSI OEM peut contenir les fichiers propriétaires 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 de generic_system.mk pour l'image système de l'OEM

Étape 2 : Faites en sorte que la GSI OEM comporte la même liste de fichiers que la 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 de la GSI OEM

Étape 3 : Définir une liste d'autorisation pour limiter les fichiers modifiés dans la GSI 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 la GSI AOSP à partir de la cible de lancement AOSP generic_system_*.

En exécutant l'outil compare_images régulièrement 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 à la GSI de l'OEM.

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

Étape 4 : Faites en sorte que la GSI OEM ait les mêmes binaires que la GSI AOSP

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

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

Définir l'identité numérique souveraine 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 la GSI OEM, les OEM peuvent utiliser une macro makefile 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 Créer un fichier makefile et activer la vérification du chemin d'accès aux artefacts.

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

Appliquer les interfaces produit

Pour garantir que la partition /product est dissociée, les OEM peuvent s'assurer que leurs appareils appliquent les interfaces produit 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 la PRODUCT_SHIPPING_API_LEVEL de l'appareil est supérieure ou égale à 30. Pour en savoir plus, consultez Appliquer des interfaces de partition de produits.

Rendre la partition /system_ext commune

La partition /system_ext peut varier d'un appareil à l'autre, car elle peut contenir des modules spécifiques à l'appareil et regroupés dans le système. Étant donné que le SSI se compose des 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 le partager entre plusieurs appareils en supprimant les différences et en rendant la partition /system_ext commune.

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

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

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

La méthode recommandée pour supprimer les API masquées des applications consiste à trouver des API publiques ou système alternatives pour les remplacer. S'il n'existe aucune API pour remplacer les API masquées, les OEM peuvent contribuer à AOSP pour définir les nouvelles API système pour 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 produit ou fournisseur. Les OEM doivent figer les API orientées produit pour assurer la rétrocompatibilité.

Incluez le superset de tous les APK et ignorez l'installation de certains packages pour chaque appareil.

Certains packages fournis avec le système ne sont pas courants sur tous les appareils. Il peut être difficile de dissocier ces modules APK pour les déplacer vers la partition du produit ou du fournisseur. En guise de solution provisoire, les OEM peuvent inclure tous les modules dans le SSI, puis filtrer ceux qui ne sont pas souhaités à 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 RRO au lieu d'utiliser une superposition de ressources statiques

Une superposition de ressources statiques manipule les packages superposés. Toutefois, il peut empêcher la définition d'une SSI. Assurez-vous donc que les propriétés de RRO sont activées et correctement définies. En définissant les propriétés comme suit, les OEM peuvent avoir toutes les couches 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 manuellement un RRO au lieu de vous fier à un RRO généré automatiquement. Pour en savoir plus, consultez 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 en utilisant les attributs android:requiredSystemPropertyName et android:requiredSystemPropertyValue.

Questions fréquentes

Puis-je définir plusieurs SSI ?

Cela dépend de la fréquence et des caractéristiques des appareils (ou du groupe d'appareils). Les OEM peuvent essayer de rendre la partition system_ext commune, comme décrit dans 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 SSI.

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

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

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

Non. La GSI comporte un ensemble minimal de modules bootables 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.