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) entre les gammes de produits. Il propose également une procédure permettant de baser un SSI appartenant à un OEM sur une image système générique (GSI) construite 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 générique du système d'exploitation (le framework du système d'exploitation Android). Le logiciel de chacun est installé dans une partition distincte : la partition fournisseur pour le logiciel spécifique au matériel et la partition système pour le logiciel générique du système d'exploitation. Une interface versionnée, appelée interface fournisseur ( VINTF ), est définie et appliquée sur les deux partitions. En utilisant ce système de partitionnement, vous pouvez modifier la partition système sans modifier la partition fournisseur, et vice versa.
Motivation
Le code-cadre publié dans AOSP est conforme à l'architecture Treble et conserve une compatibilité descendante avec les implémentations des anciens fournisseurs. Par exemple, une image système générique créée à partir de sources Android 10 AOSP peut s'exécuter sur n'importe quel appareil compatible Treble fonctionnant sous Android 8 ou version ultérieure. La version d'Android livrée sur les appareils grand public est modifiée par les fournisseurs de SoC et les OEM. (Voir Durée de vie d'une version Android .) Ces modifications et extensions apportées au framework n'ont pas été écrites pour maintenir la compatibilité ascendante, ce qui s'est traduit par une complexité accrue et un coût plus élevé dans une mise à niveau du système d'exploitation. Les changements et modifications spécifiques à l'appareil ajoutent au coût et à la complexité de la mise à niveau d'une version du système d'exploitation Android.
Avant Android 11, il n'existait pas d'architecture claire permettant aux partenaires de créer des extensions modulaires pour le framework du système d'exploitation Android. Ce document décrit les étapes que les fournisseurs de SoC et les OEM peuvent suivre pour créer un SSI. Cela signifie une image, construite à partir des sources du framework Android OS pour être réutilisée sur plusieurs appareils, pour maintenir la compatibilité descendante avec les implémentations des fournisseurs et pour fournir une réduction significative de la complexité et du coût des mises à niveau du système d'exploitation Android. Pour connaître les étapes spécifiques dont vous avez besoin pour créer un SSI, consultez la section Étapes suggérées pour le SSI basé sur GSI et notez que vous n'êtes pas obligé d'utiliser les quatre étapes. Les étapes que vous choisissez (uniquement l'étape 1, par exemple) dépendent de votre implémentation.
Présentation du SSI
Avec 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 de disposer d'un petit nombre de SSI à utiliser sur plusieurs SKU d'appareils. Lorsqu'une nouvelle version du système d'exploitation Android est publiée, les OEM n'investissent qu'une seule fois dans la mise à jour de 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 ces objectifs clés :
- Réutilisez le SSI sur plusieurs SKU d’appareil.
- Mettez à jour le système Android avec les extensions modulaires pour faciliter les mises à niveau du système d'exploitation.
L'idée principale consistant à séparer les composants spécifiques au produit dans la partition du produit est similaire à l'idée de Treble consistant à séparer les composants spécifiques au SoC dans la partition du fournisseur. Une interface produit (similaire à 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. installés sur 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 sur les partitions et les stratégies sur les interfaces. Cette section explique en détail chacune des partitions et interfaces.
Figure 1. Partitions et interfaces autour de SSI
Images et partitions
Les informations contenues dans 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 qui peut être mis à jour indépendamment.
Les sections de la figure 1 sont définies comme suit :
SSI : le SSI est l'image commune à un OEM et peut exister sur plusieurs appareils. Il ne contient aucun composant spécifique au matériel ou au produit. Tout ce qui se trouve dans un SSI donné est, par définition, partagé entre tous les appareils utilisant ce SSI. Le SSI est composé soit d'une seule image
/system, soit d'une partition/systemet des partitions/system_ext, comme le montre la figure 1.La partition
/systemcontient des composants basés sur AOSP, tandis que/system_ext, une fois implémenté, contient des extensions et des composants de fournisseurs OEM et SoC étroitement couplé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 s'intègre mieux dans la partition/system_extque dans la partition/system. Le contenu des partitions/systemet/system_extest créé à partir de sources Android modifiées par OEM.La partition
/system_extest facultative, mais il est avantageux 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 que vous devez apporter pour déplacer ces composants de la partition/system_extvers la partition/productsur une période donnée.
Produit : ensemble de composants spécifiques au produit ou à l'appareil qui représentent les personnalisations et extensions OEM du système d'exploitation Android. Placez les composants spécifiques au SoC dans la partition
/vendor. Les fournisseurs de SoC peuvent également utiliser la partition/productpour les composants appropriés, tels que ceux indépendants du SoC. Par exemple, si un fournisseur de SoC fournit à ses clients OEM un composant indépendant du SoC (dont la livraison est facultative avec le produit), le fournisseur de SoC 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 : une collection de composants spécifiques au SoC.
ODM : un 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 possède l'image du fournisseur, tandis que le fabricant de l'appareil possède l'image ODM. Lorsqu'il n'y a pas de partition
/odmdistincte, les images du fournisseur SoC et ODM sont fusionnées dans la partition/vendor.
Interfaces entre images
Deux interfaces principales pour les images de fournisseurs et de produits existent autour de SSI :
Interface fournisseur (VINTF) : VINTF est l'interface avec les composants qui résident dans le fournisseur et les images ODM. Les composants des images du produit et du système ne peuvent interagir qu'avec les images du fournisseur et de l'ODM via cette interface. Par exemple, une image fournisseur ne peut pas dépendre d’une partie privée de l’image système, et vice versa. Ceci est initialement défini 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 (Passthrough HAL est uniquement disponible pour les modules
systemetsystem_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
- HIDL (Passthrough HAL est uniquement disponible pour les modules
Interfaces produit : L'interface produit est l'interface entre SSI et l'image produit. La définition d'une interface stable découple 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. Cependant, seules les API VNDK et Android SDK sont appliquées pour les appareils lancés avec Android 11 (et versions ultérieures).
Activation de SSI dans Android 11
Cette section explique comment utiliser les nouvelles fonctionnalités en place pour prendre en charge SSI dans Android 11.
La partition /system_ext
La partition /system_ext a été introduite dans Android 11 en tant que partition facultative. (C'est l'endroit idéal pour les composants non-AOSP qui ont un couplage étroit avec les composants définis par AOSP dans la partition /system .) La partition /system_ext est supposée être l'extension spécifique à l'OEM de la partition /system , sans interface définie dans les deux cloisons. 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 couplées, les deux partitions 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 dans la prochaine version d'Android.
Pour installer un module sur la partition /system_ext , ajoutez system_ext_specific: true au fichier Android.bp . Pour les appareils qui n'ont pas de partition /system_ext , installez ces modules dans le sous-répertoire ./system_ext de la partition /system .
Histoire
Voici un peu d'historique sur la partition /system_ext . L'objectif de conception était de placer tous les composants spécifiques aux OEM, qu'ils soient communs ou non, dans la partition /product . Cependant, les déplacer tous en même temps n'était pas réalisable, surtout 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 refonte approfondie du composant lui-même, ce qui demandait beaucoup de temps et d'efforts. La partition /system_ext a commencé comme un endroit pour héberger temporairement les composants qui ne sont pas prêts à être déplacés vers la partition /product . Le but du SSI était d'éliminer à terme la partition /system_ext .
Cependant, la partition /system_ext est utile pour garder la partition /system aussi proche que possible de l'AOSP. Avec SSI, la plupart des efforts de mise à niveau sont consacrés 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 l'effort de mise à niveau sur l'image system_ext .
Dégroupage des composants des partitions /system et /system_ext dans la partition /product
Android 9 a introduit une partition /product couplée à la partition /system . Les modules de la partition /product utilisent les ressources système sans aucune restriction, et vice versa. 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 besoin de respecter les restrictions d'utilisation des composants système que la partition /product faisait dans Android 9. À partir d'Android 10, la partition /product doit être dissociée de la partition /system et doit utiliser des interfaces stables de les 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 sur la /system_ext partition . Pour ce faire, dégroupez les modules spécifiques au produit et déplacez-les dans la partition /product . Le dégroupage des modules spécifiques au produit rend /system_ext commun aux appareils. (Pour plus de détails, voir Rendre la partition /system_ext commune .)
Pour dissocier la partition /product des composants système, la partition /product doit avoir la même politique d'application que la partition /vendor déjà dissociée avec Project Treble.
À partir d'Android 11, les interfaces natives et Java pour la partition /product sont appliquées comme décrit ci-dessous. Pour plus d'informations, consultez Application des interfaces de partition de produit .
- Interfaces natives : Les modules natifs de la partition
/productdoivent être dissociés des autres partitions. Les seules dépendances autorisées des modules du produit sont certaines bibliothèques VNDK (y compris LLNDK) de la partition/system. Les bibliothèques JNI dont dépendent les applications du produit doivent être des bibliothèques NDK. - Interfaces Java : Les modules Java (app) dans la partition
/productne peuvent pas utiliser les API cachées, car elles sont instables. Ces modules doivent uniquement utiliser les API publiques et les API système de la partition/system, ainsi que les bibliothèques Java SDK de la partition/systemou/system_ext. Vous pouvez définir des bibliothèques Java SDK pour les API personnalisées.
Étapes suggérées pour le SSI basé sur GSI
Figure 2. Partitions suggérées pour SSI basé sur GSI
Une image système générique (GSI) est l'image système créé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 véritable appareil exécutant la version requise d'Android.
Les OEM peuvent également utiliser GSI pour créer leur SSI. Comme expliqué dans Images et partitions , 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 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 quasi-AOSP. Si les OEM créent l'image système à partir de sources AOSP, ils peuvent alors remplacer l'image système qu'ils créent par le GSI fourni par AOSP. Cependant, les constructeurs OEM n'ont pas besoin d'atteindre l'étape finale (en utilisant GSI tel quel) d'un seul coup.
Étape 1. Héritage de generic_system.mk pour l'image système OEM (OEM GSI)
En héritant generic_system.mk (qui a été nommé mainline_system.mk dans Android 11 et renommé generic_system.mk dans AOSP), l'image système (OEM GSI) inclut tous les fichiers dont dispose l'AOSP GSI. Ces fichiers peuvent être modifiés par les OEM, afin que l'OEM GSI puisse contenir les fichiers propriétaires OEM en plus des fichiers AOSP GSI. Cependant, les OEM ne sont pas autorisés à modifier le fichier generic_system.mk lui-même.
Figure 3. Héritage de generic_system.mk pour l'image système 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 avoir 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éplacement des fichiers ajoutés hors du GSI OEM
Étape 3. Définition d'une liste autorisée pour limiter les fichiers modifiés dans le GSI OEM
Pour vérifier les fichiers modifiés, les OEM peuvent utiliser l'outil compare_images et comparer l'AOSP GSI avec l'OEM GSI. Obtenez l'AOSP GSI à partir de la cible du déjeuner AOSP generic_system_* .
En exécutant périodiquement l'outil compare_images avec le paramètre allowlist , vous pouvez surveiller les différences en dehors de la liste autorisée. Cela évite de devoir apporter des modifications supplémentaires au GSI OEM.
Figure 5. Définir une liste autorisée pour réduire la liste des fichiers modifiés dans le GSI OEM
Étape 4. Faire en sorte que le GSI OEM ait les mêmes binaires que le GSI AOSP
Le nettoyage de la liste verte permet aux OEM d'utiliser l'AOSP GSI comme image système pour leurs propres produits. Pour nettoyer la liste verte, les OEM peuvent soit abandonner leurs modifications dans le GSI OEM, soit en amont de leurs modifications dans l'AOSP afin que l'AOSP GSI inclut leurs modifications.
Figure 6. Faire en sorte que le GSI OEM ait les mêmes binaires que le GSI AOSP
Définir SSI pour les OEM
Protéger la partition /system au moment de la construction
Pour éviter toute modification spécifique au produit dans la partition /system et définir le 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. Voir l'exemple Créer un makefile et activer la vérification du chemin d'artefact .
Les OEM peuvent définir une liste pour permettre l'installation temporaire de modules spécifiques au produit dans la partition /system . Cependant, la liste doit être vide pour que le GSI OEM soit commun à tous les produits de l'OEM. Ce processus sert à définir le GSI OEM et peut être indépendant des étapes du GSI AOSP .
Appliquer les interfaces des produits
Pour garantir que la partition /product est dégroupée, les OEM peuvent garantir que leurs appareils appliquent les interfaces du 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 automatiquement définies si le PRODUCT_SHIPPING_API_LEVEL de l'appareil est supérieur ou égal à 30 . Pour des informations détaillées, consultez Application des interfaces de partition de produit .
Rendre la partition /system_ext commune
La partition /system_ext peut différer d'un périphérique à l'autre, car elle peut contenir des modules spécifiques au périphérique et regroupés au système. Étant donné que le SSI est constitué 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 partager ce SSI 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 caché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, interdites dans la partition du produit. Pour déplacer des applications spécifiques à un appareil vers la partition du produit, supprimez l'utilisation des API masquées.
La méthode privilégiée pour supprimer les API masquées des applications consiste à rechercher 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 à l'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 SDK Java dans la partition /system_ext . Il peut utiliser des API cachées dans la partition système et fournir les API aux applications dans la partition du produit ou du fournisseur. Les OEM doivent geler les API orientées produit pour des raisons de compatibilité ascendante.
Incluez le sur-ensemble de tous les APK et ignorez certaines installations de packages pour chaque appareil
Certains packages fournis avec le système ne sont pas communs à tous les appareils. Dégrouper ces modules APK pour les déplacer vers le produit ou la partition du fournisseur peut être difficile. En guise de solution provisoire, les OEM peuvent faire en sorte que le SSI inclue tous les modules, puis filtrer ceux qui ne sont pas nécessaires à 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 récepteur de diffusion qui désactive les packages inutiles. Le récepteur de diffusion appelle setApplicationEnabledSetting pour désactiver le package lorsqu'il reçoit le message ACTION_BOOT_COMPLETED .
Définir RRO au lieu d'utiliser la superposition de ressources statiques
Une superposition de ressources statiques manipule les packages superposés. Cependant, cela peut empêcher la définition d'un SSI, alors assurez-vous que les propriétés du RRO 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 un RRO manuellement au lieu de vous fier à un RRO généré automatiquement. Pour des informations détaillées, consultez Superpositions de ressources d'exécution (RRO) . Les OEM peuvent également définir des RRO conditionnels qui dépendent des propriétés du système à l’aide des attributs android:requiredSystemPropertyName et android:requiredSystemPropertyValue .
Questions fréquemment posées (FAQ)
Puis-je définir plusieurs SSI ?
Cela dépend des points communs 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 de périphériques 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 un GSI OEM ?
Non, mais les OEM peuvent définir un nouveau makefile pour un OEM GSI qui hérite du fichier generic_system.mk et utiliser le nouveau makefile à la place. Pour obtenir un exemple, consultez Application des interfaces de partition de produit .
Puis-je supprimer des modules de generic_system.mk qui entrent en conflit avec mon implémentation ?
Non. GSI dispose d'un ensemble minimum de modules amorçables et testables. Si vous pensez qu'un module n'est pas indispensable, veuillez signaler un bug pour mettre à jour le fichier generic_system.mk dans AOSP.