Android 11 dissocie la partition product
, ce qui en fait
indépendamment des partitions system
et vendor
. Dans le cadre de ces changements,
vous pouvez désormais contrôler l'accès de la partition product
aux langages natifs et Java
interfaces (ce qui est semblable à la façon dont fonctionne l'application de l'interface pour vendor
partitions).
Appliquer les interfaces natives
Pour activer l'application de l'interface native, définissez PRODUCT_PRODUCT_VNDK_VERSION
à current
. (La version est automatiquement définie sur current
lorsque l'adresse de livraison
le niveau d'API de la cible est supérieur à 29.) Leur application permet:
- Modules natifs dans la partition
product
à associer: <ph type="x-smartling-placeholder">- </ph>
- De manière statique ou dynamique avec les autres modules de la partition
product
qui inclure des bibliothèques statiques, partagées ou d’en-tête. - De manière dynamique aux bibliothèques VNDK dans la partition
system
.
- De manière statique ou dynamique avec les autres modules de la partition
- Bibliothèques JNI dans les APK non groupés de la partition
product
à associer bibliothèques dans/product/lib
ou/product/lib64
(cela s'ajoute à bibliothèques NDK).
L'application n'autorise pas d'autres liens vers des partitions autres que product
partition.
Application forcée du temps de compilation (Android.bp)
Sous Android 11, les modules système peuvent créer un produit
en plus des variantes d'image principales et du fournisseur. Si native
l'application forcée de l'interface est activée (PRODUCT_PRODUCT_VNDK_VERSION
est défini sur
current
):
Les modules natifs de la partition
product
sont dans la variante du produit de la variante principale.Les modules dont le fichier
Android.bp
contientproduct_available: true
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 spécifiantproduct_specific: true
ouproduct_available: true
dans leurs fichiersAndroid.bp
.product_available: true
doit figurer dans les fichiersAndroid.bp
des bibliothèques VNDK afin que les binairesproduct
puissent être associés aux bibliothèques VNDK.
Le tableau suivant récapitule les propriétés Android.bp
utilisées pour créer une image
.
Propriétés dans Android.bp | Variantes créées | |
---|---|---|
Avant l'application forcée | Après application | |
par défaut (aucun) | zone abdominale
(inclut /system , /system_ext et
/product ) |
zone abdominale
(inclut /system et /system_ext , mais pas
/product ) |
system_ext_specific: true |
core | core |
product_specific: true |
core | produit |
vendor: true |
fournisseur | fournisseur |
vendor_available: true |
cœur, fournisseur | cœur, fournisseur |
product_available: true |
N/A | cœur, produit |
vendor_available: true ET product_available:
true |
N/A | principale, produit, fournisseur |
system_ext_specific: true ET vendor_available:
true |
cœur, fournisseur | cœur, fournisseur |
product_specific: true ET vendor_available:
true |
cœur, fournisseur | produit, fournisseur |
Application forcée du temps de compilation (Android.mk)
Lorsque l'application forcée de l'interface native est activée, les modules natifs installés sur
Le type de liaison native:product
des partitions product
ne peut être associé qu'à
d'autres modules native:product
ou native:vndk
. Tentative d'association à une
les modules autres que ceux-ci entraînent la génération par le système de compilation d'une vérification du type de lien
.
Application forcée de l'environnement d'exécution
Lorsque l'application de l'interface native est activée, la configuration de l'éditeur de liens pour le
l'éditeur de liens bionic n'autorise pas les processus système à utiliser les bibliothèques product
,
création d'une section product
pour les processus product
qui ne peuvent pas être associés à
en dehors de la partition product
(toutefois, ces processus peuvent être associés à
VNDK). Les tentatives de violation de la configuration du lien d'exécution provoquent
processus et de générer un message d'erreur CANNOT LINK EXECUTABLE
.
Appliquer les interfaces Java
Pour activer l'application forcée de l'interface Java, définissez
De PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE
à true
. (La valeur est
est automatiquement défini sur true
lorsque le niveau d'API de livraison pour la cible est
supérieure à 29.) Lorsque cette option est activée, la mesure d'application autorise ou interdit ce qui suit :
accès:
API | /system | /system_ext | /product | /vendor | /data |
---|---|---|---|---|---|
API publique | |||||
@SystemApi | |||||
API @hide |
Comme dans la partition vendor
, une application ou une bibliothèque Java dans le fichier product
partition est autorisée à utiliser uniquement des API publiques et système ; un lien vers une bibliothèque
utilisant des API masquées n'est pas autorisé. Cette restriction inclut l'association au moment de la compilation
le temps et la réflexion lors de l'exécution.
Application forcée de la durée de compilation
Au moment de la compilation, Make et Soong vérifient que les modules Java dans product
n'utilisent pas d'API masquées en vérifiant le platform_apis
et
sdk_version
. Le sdk_version
des applications dans la partition product
doit
être rempli par current
, system_current
ou la version numérique de l'API ;
le champ platform_apis
doit être vide.
Application forcée de l'environnement d'exécution
L'environnement d'exécution Android vérifie que les applications de la partition product
n'utilisent pas
les API cachées, y compris la réflexion. Pour en savoir plus, consultez la section Restrictions concernant
non SDK
interfaces Google Cloud.
Activer l'application forcée de l'interface produit
Suivez la procédure décrite dans cette section pour activer l'application forcée de l'interface produit.
Étape | Tâche | Obligatoire |
---|---|---|
1 | Définissez votre propre fichier makefile système qui spécifie les packages pour
system , puis définissez la vérification des exigences concernant le chemin d'accès aux artefacts
dans le device.mk (pour empêcher les modules non système d'installer
à la partition system ). |
N |
2 | Nettoyez la liste d'autorisation. | N |
3 | Appliquer les interfaces natives et identifier les échecs de liaison lors de l'exécution (peut s'exécuter dans parallèlement à l'application de Java). | O |
4 | Appliquer les interfaces Java et vérifier le comportement lors de l'exécution (peut s'exécuter en parallèle) avec application native). | O |
5 | Vérifiez les comportements de l'environnement d'exécution. | O |
6 | Mettez à jour device.mk avec l'application forcée de l'interface produit. |
O |
Étape 1: Créez un fichier makefile et activez la vérification du chemin d'accès à l'artefact
Au cours de cette étape, vous allez définir le fichier makefile system
.
Créez un fichier makefile qui définit les packages pour la partition
system
. Pour Par exemple, créez un fichieroem_system.mk
avec ce qui suit:$(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 fichier makefile commun poursystem
. partitionner et activer la vérification des exigences concernant le chemin d'accès à l'artefact. 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 concernant le chemin d'accès à l'artefact
Lorsque PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS
est défini sur true
ou strict
,
le système de compilation empêche l'installation des packages définis dans d'autres fichiers makefile
les chemins d'accès définis dans require-artifacts-in-path
et empêche les packages
défini dans le fichier makefile actuel d'installer des artefacts en dehors des chemins d'accès.
défini dans require-artifacts-in-path
.
Dans l'exemple ci-dessus, PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS
est défini sur
strict
, les fichiers makefile en dehors de oem_system.mk
ne peuvent pas inclure de modules installés pour
la partition root
ou system
. Pour inclure ces modules, vous devez :
définissez-les dans le fichier oem_system.mk
lui-même ou dans un fichier makefile inclus.
Les tentatives d'installation de modules sur des chemins d'accès non autorisés entraînent des interruptions de compilation. Pour corriger
effectuez l'une des opérations suivantes:
Option 1:inclure le module système dans les fichiers makefiles inclus dans
oem_system.mk
Ainsi, l'exigence de chemin d'accès à l'artefact est satisfaite (étant donné que modules existent désormais dans un fichier makefile inclus) et permet donc l'installation ensemble de chemins d'accès dans "require-artifacts-in-path".Option 2:installer des modules sur la partition
system_ext
ouproduct
(et n'installez pas de modules sur la partitionsystem
).Option 3:ajoutez des modules à la
PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST
Cette liste affiche la liste des modules autorisés. à installer.
Étape 2: Videz la liste d'autorisation
Au cours de cette étape, vous allez définir PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST
vide afin que tous les appareils partageant le oem_system.mk
puissent aussi partager un même system
l'image. Pour vider la liste d'autorisation, déplacez tous les modules de la liste vers le
system_ext
ou product
, ou ajoutez-les à des fichiers de création system
. Ce
Cette étape est facultative, car il n'est pas nécessaire de définir une image system
commune pour
activer l'application forcée de l'interface produit. Toutefois, vider la liste d'autorisation
utile pour définir la limite system
avec system_ext
.
Étape 3: Appliquez les interfaces natives
Au cours de cette étape, vous allez définir PRODUCT_PRODUCT_VNDK_VERSION := current
, puis rechercher
les erreurs de compilation et d'exécution
et de les résoudre. Vérifier le démarrage et les journaux de l'appareil
et recherchez et corrigez les échecs d'association au moment de l'exécution:
Définissez
PRODUCT_PRODUCT_VNDK_VERSION := current
.Créez l'appareil et recherchez les erreurs de compilation. Vous verrez probablement quelques erreurs pour cause de variantes de produit ou de variantes principales manquantes. Coupures courantes incluent:
- Aucun module
hidl_interface
contenantproduct_specific: true
ne sera disponibles pour les modules système. Pour résoudre le problème, remplacezproduct_specific: true
avecsystem_ext_specific: true
. - Il est possible que les modules ne contiennent pas la variante requise pour le produit
modules. Pour résoudre ce problème, rendez ce module disponible pour la partition
product
en en définissantproduct_available: true
ou déplacez le module versproduct
partition en définissantproduct_specific: true
.
- Aucun module
Résolvez les erreurs de compilation et assurez-vous que l'appareil se compile correctement.
Flashez l'image et recherchez les erreurs d'exécution au démarrage et dans les journaux de l'appareil.
- Si la balise
linker
d'un journal de scénario de test affiche uneCANNOT LINK EXECUTABLE
s'affiche, il manque une dépendance dans le fichier "make" (et n'a pas été capturé à l'adresse la durée de la compilation). - Pour la vérifier à partir du système de compilation, ajoutez la bibliothèque requise au
Champ
shared_libs:
ourequired:
.
- Si la balise
Résolvez les dépendances manquantes en suivant les instructions ci-dessus.
Étape 4: Appliquez les interfaces Java
Au cours de cette étape, vous allez définir PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true
,
puis trouver et corriger
les erreurs de compilation qui en résultent. Recherchez deux types d'erreurs spécifiques:
Erreurs liées au type de lien. Cette erreur indique qu'une application est liée à des modules Java dont le
sdk_version
est plus large. Pour résoudre ce problème, vous pouvez élargirsdk_version
ou limiter lesdk_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 dans une API cachée. Pour résoudre le problème, utilisez une API visible (non masquée) ou recherchez 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érifiez les comportements d'exécution
Au cours de cette étape, vous allez vérifier que les comportements d'exécution sont conformes à vos attentes. Pour les applications
débogable, vous pouvez surveiller l'utilisation de l'API cachée par journal à l'aide de
StrictMode.detectNonSdkApiUsage
(qui génère un journal lorsque l'application utilise un
API cachée). Vous pouvez également utiliser la
veridex
un outil d'analyse statique pour connaître le type d'utilisation (lien ou réflexion) ;
le niveau de restriction et la pile d'appel.
Syntaxe Veridex:
./art/tools/veridex/appcompat.sh --dex-file={apk file}
Exemple de résultat pour 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 en savoir plus sur l'utilisation de veridex, consultez Tester avec veridex. l'outil.
Étape 6: Mettez à jour le fichier device.mk
Après avoir corrigé tous les échecs de compilation et d'exécution, et après avoir vérifié que
sont conformes aux attentes, définissez les éléments suivants dans device.mk
:
PRODUCT_PRODUCT_VNDK_VERSION := current
PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true