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
.
- De manière statique ou dynamique vers d'autres modules de la partition
- 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 fichiersAndroid.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écifientproduct_specific: true
ouproduct_available: true
dans leurs fichiersAndroid.bp
.Les bibliothèques VNDK doivent avoir
product_available: true
dans leurs fichiersAndroid.bp
afin que les binairesproduct
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 | |
---|---|---|
Avant l'exécution | Après l'exécution | |
par défaut (aucun) | cœur (comprend | cœur (comprend |
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 fichieroem_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 partitionsystem
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
ouproduct
(et n'installez pas de modules sur la partitionsystem
).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, remplacezproduct_specific: true
parsystem_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éfinissantproduct_available: true
ou déplacez le module vers la partitionproduct
en définissantproduct_specific: true
.
- Tout module
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 messageCANNOT 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:
ourequired:
- Si la balise de
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 lasdk_version
de l'application ou restreindre lasdk_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