Cloisons de produit

Android 9 et versions ultérieures incluent la prise en charge de la création de partitions product à l'aide du système de génération Android. Auparavant, Android 8.x imposait la séparation des composants spécifiques au SoC de la partition system vers la partition vendor sans consacrer d'espace aux composants spécifiques aux OEM créés à partir du système de build Android. Android 9 et versions ultérieures fournissent des autorisations supplémentaires et des fonctionnalités de liste blanche qui s'appliquent aux applications privées sur différentes partitions.

À propos des partitions du produit

De nombreux constructeurs OEM personnalisent l'image système AOSP pour implémenter leurs propres fonctionnalités, ainsi que les exigences des opérateurs. Cependant, de telles personnalisations rendent impossible l’utilisation d’une seule image système pour plusieurs SKU de logiciels. Chaque image doit être différente pour prendre en charge les personnalisations, par exemple avec des paramètres régionaux ou des opérateurs différents. L'utilisation d'une partition product distincte pour contenir les personnalisations permet d'utiliser une seule image système pour plusieurs SKU de logiciels. (La partition system héberge du code générique qui peut être partagé entre de nombreuses références de logiciels). La partition vendor continue d'héberger le code BSP spécifique au SoC qui peut être partagé entre plusieurs appareils en fonction du SoC donné.

L'utilisation de partitions séparées présente certains inconvénients, tels que la gestion de l'espace disque (une quantité limitée d'espace doit rester réservée pour une croissance future) et le maintien d'une interface binaire d'application (ABI) stable entre les partitions. Avant de décider d'utiliser des partitions product , prenez le temps de réfléchir à votre implémentation AOSP unique et aux tactiques d'atténuation possibles (telles que le repartitionnement d'un appareil lors d'une mise à jour en direct (OTA) , ce qui n'est pas effectué par Google mais par certains OEM. ). Le partitionnement dynamique sera une bonne solution pour cela.

Partitions et autorisations du produit

Sous Android 9 et versions ultérieures, une modification du processus d'autorisations et de liste blanche affecte la façon dont vous accordez les autorisations d'applications privées sur vos partitions « produit ». Le fichier permissions.xml doit résider dans la même partition que les priv-apps. Le placement d'un fichier permissions.xml dans la partition system pour les applications privées n'étend pas ces autorisations aux applications privées dans la partition product , même si la première est une extension de la seconde. Pour plus de détails sur les autorisations et les processus de mise en liste blanche, consultez Liste blanche des autorisations privilégiées .

Héritage /oem vs /produit

Nous avons deux types d'attributs de partition de product en fonction de l' application de l'interface du produit . De plus, la partition product est différente de la partition oem héritée :

Cloison Les attributs
oem
  • Non actualisable ; généralement flashé une fois à l'usine.
  • Construit selon de petites variations, telles que la marque et la couleur. Avoir un contenu de partition oem différent ne signifie pas que le logiciel du produit est différent.
  • La partition system ne dépend pas de la partition oem . (Il utilise la partition oem uniquement lorsqu'un fichier spécifique s'y trouve).
  • Utilise uniquement l'API publique sur la partition system .
product
  • Possibilité de mise à jour
  • Couplé à l'image système (ils se mettent à jour ensemble)
  • Construit par produit ou familles de produits.
  • La partition système peut dépendre de la partition product .
  • Peut utiliser des API non publiques puisqu'elles sont mises à jour simultanément.
product (interfaces renforcées)
  • Possibilité de mise à jour
  • Découplé de l'image système.
  • Construit par produit ou familles de produits.
  • La partition system ne dépend pas de la partition product .
  • Ne peut pas utiliser d'API masquées, mais utilise uniquement les API publiques et système sur la partition system .

Pour ces raisons, Android 9 prend en charge la partition product tout en conservant la prise en charge de l'ancienne partition oem , pour les appareils qui en dépendent. Pour découpler la partition product de la partition system , Android 11 prend en charge l'application des interfaces product .

/composants du produit

La partition product contient les composants suivants :

  • Propriétés système spécifiques au produit ( /product/build.prop )
  • RRO spécifiques au produit ( /product/overlay/*.apk )
  • Applications spécifiques au produit ( /product/app/*.apk )
  • Applications privées spécifiques au produit ( /product/priv-app/*.apk )
  • Bibliothèques spécifiques au produit ( /product/lib/* )
  • Bibliothèques Java spécifiques au produit ( /product/framework/*.jar )
  • Configurations système Android Framework spécifiques au produit ( /product/etc/sysconfig/* et /product/etc/permissions/* )
  • Fichiers multimédias spécifiques au produit ( /product/media/audio/* )
  • Fichiers bootanimation spécifiques au produit

Aucune image_personnalisée

Vous ne pouvez pas utiliser custom_images . Ils manquent de soutien pour les éléments suivants :

  • Installation de modules dans une cible spécifique . custom_images prend en charge la copie d'artefacts dans une image mais ne peut pas installer un module dans une partition spécifique en spécifiant sa partition cible dans le cadre d'une règle de construction.
  • Bientôt un soutien . custom_images ne peut pas être construit à l'aide du système de construction Soong.
  • Prise en charge des mises à jour OTA . custom_images sont utilisés comme images ROM d'usine qui ne peuvent pas recevoir de mises à jour OTA.

Maintenir les ABI entre les partitions

La partition product dans Android 9 est une extension de la partition system . Il existe un faible ABI entre les partitions product et system , les deux doivent donc être mis à niveau en même temps et l'ABI doit être basé sur le SDK système. Si le SDK système ne couvre pas toutes les surfaces API entre product et system , les OEM doivent conserver leurs propres ABI entre les deux partitions.

Les partitions product et system peuvent dépendre les unes des autres. Toutefois, les tests avec l' image système générique (GSI) doivent fonctionner correctement sans la partition product .

Lorsque les interfaces product sont appliquées, la partition product est découplée de la partition system . La partition product utilise uniquement les interfaces autorisées de la partition system .

La partition product ne doit avoir aucune dépendance via des interfaces instables sur la partition vendor . L'interaction directe entre les partitions du product et vendor est interdite. (Ceci est appliqué par SEpolicy.)

Implémentation de partitions de produits

Avant d'implémenter une nouvelle partition de produit, examinez les modifications associées à la partition de produit dans AOSP . Ensuite, pour configurer product , incluez les indicateurs de carte ou de construction de produit suivants :

  • BOARD_USES_PRODUCTIMAGE
  • BOARD_PRODUCTIMAGE_PARTITION_SIZE
  • BOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE
  • PRODUCT_PRODUCT_PROPERTIES pour /product/build.prop . Ceux-ci doivent se trouver dans un $(call inherit-product path/to/device.mk) , comme dans PRODUCT_PRODUCT_PROPERTIES += product.abc=ok .

Installation d'un module sur la partition du produit

Utilisez les indicateurs de build suivants pour installer un module sur la partition product .

  • product_specific: true dans Android.bp
  • LOCAL_PRODUCT_MODULE := true dans Android.mk

Activation du démarrage vérifié

Pour éviter que la partition product ne soit altérée par un logiciel malveillant, activez Android Verified Boot (AVB) pour cette partition (comme vous le faites pour les partitions vendor et system ). Pour activer AVB, incluez les indicateurs de build suivants : BOARD_AVB_PRODUCT_ADD_HASHTREE_FOOTER_ARGS .