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

Application des interfaces de partition de produit

Android 11 dégroupe la partition product , la rendant indépendante des partitions du system et vendor . Dans le cadre de ces modifications, vous pouvez désormais contrôler l'accès de la partition product aux interfaces natives et Java (ce qui est similaire au fonctionnement de l'application des interfaces pour les partitions vendor ).

Application des interfaces natives

Pour activer l'application de l'interface native, définissez PRODUCT_PRODUCT_VNDK_VERSION sur current . (La version est automatiquement définie sur current lorsque le niveau d'API d'expédition pour la cible est supérieur à 29.) L'application permet :

Modules natifs dans la partition product à lier :
- De manière statique ou dynamique vers d'autres modules de la partition product qui incluent des bibliothèques statiques, partagées ou d'en-tête.
- Dynamiquement vers les bibliothèques VNDK dans la partition system .
Bibliothèques JNI dans les APK dégroupés dans la partition product pour créer un lien vers les bibliothèques dans /product/lib ou /product/lib64 (en plus des bibliothèques NDK).

L'application n'autorise pas d'autres liens vers des partitions autres que la partition product .

Application du temps de construction (Android.bp)

Dans Android 11, les modules système peuvent créer une variante d'image de produit en plus des variantes d'image de base et de fournisseur. Lorsque l'application de l'interface native est activée ( PRODUCT_PRODUCT_VNDK_VERSION est défini sur current ) :

Les modules natifs de la partition product se trouvent dans la variante du produit au lieu de la variante principale.
Les modules avec product_available: true dans leurs fichiers Android.bp sont disponibles pour la variante du produit.
Les bibliothèques ou les binaires qui spécifient product_specific: true peuvent être liés à d'autres bibliothèques qui spécifient product_specific: true ou product_available: true dans leurs fichiers Android.bp .
Les bibliothèques VNDK doivent avoir product_available: true dans leurs fichiers Android.bp afin que les binaires product puissent être liés aux bibliothèques VNDK.

Le tableau suivant résume les propriétés Android.bp utilisées pour créer des variantes d'image.

Propriétés dans Android.bp	Variantes créées
Propriétés dans Android.bp	Avant l'exécution	Après l'exécution
par défaut (aucun)	cœur (comprend `/system` , `/system_ext` et `/product` )	cœur (comprend `/system` et `/system_ext` mais pas `/product` )
`system_ext_specific: true`	cœur	cœur
`product_specific: true`	cœur	produit
`vendor: true`	fournisseur	fournisseur
`vendor_available: true`	noyau, fournisseur	noyau, fournisseur
`product_available: true`	N / A	produit principal
`vendor_available: true` ET `product_available: true`	N / A	noyau, produit, fournisseur
`system_ext_specific: true` ET `vendor_available: true`	noyau, fournisseur	noyau, fournisseur
`product_specific: true` ET `vendor_available: true`	noyau, fournisseur	produit, fournisseur

Application du temps de construction (Android.mk)

Lorsque l'application de l'interface native est activée, les modules natifs installés sur la partition product ont un type de lien native:product qui ne peut être lié qu'à d'autres modules native:product ou native:vndk . Tenter de créer un lien vers des modules autres que ceux-ci entraîne la génération par le système de construction d'une erreur de vérification du type de lien.

Application de l'exécution

Lorsque l'application de l'interface native est activée, la configuration de l'éditeur de liens pour l'éditeur de liens bionique ne permet pas aux processus système d'utiliser les bibliothèques product , créant ainsi une section product pour les processus de product qui ne peuvent pas être liés à des bibliothèques en dehors de la partition product (cependant, de tels processus peuvent lien vers les bibliothèques VNDK). Les tentatives de violation de la configuration du lien d'exécution entraînent l'échec du processus et génèrent un message d'erreur CANNOT LINK EXECUTABLE .

Application des interfaces Java

Pour activer l'application de l'interface Java, définissez PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE sur true . (La valeur est automatiquement définie sur true lorsque le niveau d'API d'expédition pour la cible est supérieur à 29.) Lorsqu'elle est activée, l'application autorise/interdit l'accès suivant.

API	/système	/system_ext	/produit	/fournisseur	/données
API publique
@SystemApi
@masquer l'API

Comme dans la partition vendor , une application ou une bibliothèque Java dans la partition product est autorisée à utiliser uniquement les API publiques et système ; la création de liens vers une bibliothèque qui utilise des API cachées n'est pas autorisée. Cette restriction inclut la liaison au moment de la construction et la réflexion au moment de l'exécution.

Construire l’application du temps

Au moment de la construction, Make et Soong vérifient que les modules Java de la partition product n'utilisent pas d'API cachées en vérifiant les champs platform_apis et sdk_version . Le sdk_version des applications dans la partition product doit être renseigné avec la version current , system_current ou numérique de l'API, et le champ platform_apis doit être vide.

Application de l'exécution

Le runtime Android vérifie que les applications de la partition product n'utilisent pas d'API masquées, y compris la réflexion. Pour plus de détails, reportez-vous à Restrictions sur les interfaces non SDK .

Activation de l'application de l'interface du produit

Suivez les étapes de cette section pour activer l'application de l'interface du produit.

Étape	Tâche	Requis
1	Définissez votre propre makefile système qui spécifie les packages pour la partition `system` , puis définissez la vérification des exigences du chemin des artefacts dans le `device.mk` (pour empêcher les modules non système de s'installer sur la partition `system` ).	N
2	Nettoyez la liste autorisée.	N
3	Appliquez les interfaces natives et identifiez les échecs de liaison d’exécution (peut s’exécuter en parallèle avec l’application Java).	Oui
4	Appliquez les interfaces Java et vérifiez le comportement d'exécution (peut s'exécuter en parallèle avec l'application native).	Oui
5	Vérifiez les comportements d’exécution.	Oui
6	Mettez à jour `device.mk` avec l’application de l’interface du produit.	Oui

Étape 1 : Créez un makefile et activez la vérification du chemin de l'artefact

Dans cette étape, vous définissez le makefile system .

Créez un makefile qui définit les packages pour la partition system . Par exemple, créez un fichier oem_system.mk avec les éléments suivants :

$(call inherit-product, $(SRC_TARGET_DIR)/product/handheld_system.mk)
$(call inherit-product, $(SRC_TARGET_DIR)/product/telephony_system.mk)

# Applications
PRODUCT_PACKAGES += \
    CommonSystemApp1 \
    CommonSystemApp2 \
    CommonSystemApp3 \

# Binaries
PRODUCT_PACKAGES += \
    CommonSystemBin1 \
    CommonSystemBin2 \
    CommonSystemBin3 \

# Libraries
PRODUCT_PACKAGES += \
    CommonSystemLib1 \
    CommonSystemLib2 \
    CommonSystemLib3 \

PRODUCT_SYSTEM_NAME := oem_system
PRODUCT_SYSTEM_BRAND := Android
PRODUCT_SYSTEM_MANUFACTURER := Android
PRODUCT_SYSTEM_MODEL := oem_system
PRODUCT_SYSTEM_DEVICE := generic

# For system-as-root devices, system.img should be mounted at /, so we
# include ROOT here.
_my_paths := \
 $(TARGET_COPY_OUT_ROOT)/ \
 $(TARGET_COPY_OUT_SYSTEM)/ \

$(call require-artifacts-in-path, $(_my_paths),)

Dans le fichier device.mk , héritez du makefile commun pour la partition system et activez la vérification des exigences du chemin d'artefact. Par exemple:

$(call inherit-product, $(SRC_TARGET_DIR)/product/oem_system.mk)

# Enable artifact path requirements checking
PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS := strict

À propos des exigences relatives au chemin d'artefact

Lorsque PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS est défini sur true ou strict , le système de build empêche les packages définis dans d'autres makefiles de s'installer sur les chemins définis dans require-artifacts-in-path et empêche les packages définis dans le makefile actuel d'installer des artefacts en dehors des chemins définis dans require-artifacts-in-path .

Dans l'exemple ci-dessus, avec PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS défini sur strict , les makefiles en dehors oem_system.mk ne peuvent pas inclure de modules installés à la root ou sur la partition system . Pour inclure ces modules, vous devez soit les définir dans le fichier oem_system.mk lui-même, soit dans un makefile inclus. Les tentatives d'installation de modules sur des chemins non autorisés provoquent des interruptions de construction. Pour corriger les pauses, effectuez l'une des opérations suivantes :

Option 1 : Incluez le module système dans les makefiles inclus dans oem_system.mk . Cela permet de satisfaire aux exigences relatives au chemin d'artefact (car les modules existent désormais dans un makefile inclus) et permet ainsi l'installation sur l'ensemble de chemins dans `require-artifacts-in-path.
Option 2 : installez les modules sur la partition system_ext ou product (et n'installez pas de modules sur la partition system ).
Option 3 : ajoutez des modules au PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST . Cette liste répertorie les modules autorisés à être installés.

Étape 2 : vider la liste autorisée

Au cours de cette étape, vous rendez la PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST vide afin que tous les appareils partageant oem_system.mk puissent également partager une seule image system . Pour vider la liste autorisée, déplacez tous les modules de la liste vers la partition system_ext ou product ou ajoutez-les aux fichiers make system . Cette étape est facultative, car la définition d'une image system commune n'est pas requise pour activer l'application de l'interface du produit. Cependant, vider la liste autorisée est utile pour définir la limite system avec system_ext .

Étape 3 : Appliquer les interfaces natives

Dans cette étape, vous définissez PRODUCT_PRODUCT_VNDK_VERSION := current , puis recherchez les erreurs de build et d'exécution et résolvez-les. Pour vérifier le démarrage et les journaux du périphérique et rechercher et corriger les échecs de liaison d'exécution :

Définissez PRODUCT_PRODUCT_VNDK_VERSION := current .
Construisez l’appareil et recherchez les erreurs de construction. Vous verrez probablement quelques interruptions de build pour les variantes de produit manquantes ou les variantes principales. Les pauses courantes comprennent :
- Tout module hidl_interface doté product_specific: true ne sera pas disponible pour les modules système. Pour corriger, remplacez product_specific: true par system_ext_specfic: true .
- Il se peut que les modules ne contiennent pas la variante de produit requise pour les modules de produit. Pour résoudre ce problème, rendez ce module disponible pour la partition product en définissant product_available: true ou déplacez le module vers la partition product en définissant product_specific: true .
Remarque : les interruptions de build sont similaires pour les modules décrits dans Android.mk .
Résolvez les erreurs de build et assurez-vous que l’appareil se construit correctement.
Flashez l'image et recherchez les erreurs d'exécution dans le démarrage et les journaux du périphérique.
- Si la balise de linker d'un journal de scénario de test affiche un message CANNOT LINK EXECUTABLE , il manque une dépendance dans le fichier make (et n'a pas été capturé au moment de la construction).
- Pour le vérifier à partir du système de build, ajoutez la bibliothèque requise au champ shared_libs: ou required:
Résolvez les dépendances manquantes en utilisant les conseils donnés ci-dessus.

Étape 4 : Appliquer les interfaces Java

Dans cette étape, vous définissez PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true , puis recherchez et corrigez les erreurs de construction qui en résultent. Recherchez deux types spécifiques d'erreurs :

Erreurs de type de lien. Cette erreur indique qu'une application est liée à des modules Java dotés d'une sdk_version plus large. Pour résoudre ce problème, vous pouvez élargir la sdk_version de l'application ou restreindre la sdk_version de la bibliothèque. Exemple d'erreur :

error: frameworks/base/packages/SystemUI/Android.bp:138:1: module "SystemUI" variant "android_common": compiles against system API, but dependency "telephony-common" is compiling against private API.Adjust sdk_version: property of the source or target module so that target module is built with the same or smaller API set than the source.

Erreurs de symboles. Cette erreur indique qu'un symbole est introuvable car il se trouve dans une API masquée. Pour résoudre le problème, utilisez une API visible (non masquée) ou trouvez une alternative. Exemple d'erreur :

frameworks/opt/net/voip/src/java/com/android/server/sip/SipSessionGroup.java:1051: error: cannot find symbol
            ProxyAuthenticate proxyAuth = (ProxyAuthenticate)response.getHeader(
                                           ^
  symbol:   class ProxyAuthenticate
  location: class SipSessionGroup.SipSessionImpl

Étape 5 : Vérifier les comportements d'exécution

Au cours de cette étape, vous vérifiez que les comportements d’exécution sont comme prévu. Pour les applications déboguables, vous pouvez surveiller l'utilisation des API masquées en vous connectant à l'aide de StrictMode.detectNonSdkApiUsage (qui génère un journal lorsque l'application utilise une API masquée). Vous pouvez également utiliser l'outil d'analyse statique Veridex pour obtenir le type d'utilisation (liaison ou réflexion), le niveau de restriction et la pile d'appels.

Syntaxe Veridex :

./art/tools/veridex/appcompat.sh --dex-file={apk file}

Exemple de résultat veridex :

#1: Linking greylist-max-o Landroid/animation/AnimationHandler;-><init>()V use(s):
       Lcom/android/systemui/pip/phone/PipMotionHelper;-><init>(Landroid/content/Context;Landroid/app/IActivityManager;Landroid/app/IActivityTaskManager;Lcom/android/systemui/pip/phone/PipMenuActivityController;Lcom/android/internal/policy/PipSnapAlgorithm;Lcom/android/systemui/statusbar/FlingAnimationUtils;)V

#1332: Reflection greylist Landroid/app/Activity;->mMainThread use(s):
       Landroidx/core/app/ActivityRecreator;->getMainThreadField()Ljava/lang/reflect/Field;

Pour plus de détails sur l'utilisation de Veridex, reportez-vous à Test à l'aide de l'outil Veridex .

Étape 6 : Mettre à jour le fichier device.mk

Après avoir corrigé tous les échecs de construction et d'exécution et vérifié que les comportements d'exécution sont comme prévu, définissez les éléments suivants dans device.mk :

PRODUCT_PRODUCT_VNDK_VERSION := current
PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true