Appliquer les interfaces de partition des produits

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:
    • 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.
  • 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 contient product_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écifiant product_specific: true ou product_available: true dans leurs fichiers Android.bp.

  • product_available: true doit figurer dans les fichiers Android.bp des bibliothèques VNDK afin que les binaires product 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.

  1. Créez un fichier makefile qui définit les packages pour la partition system. Pour Par exemple, créez un fichier oem_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),)

  2. Dans le fichier device.mk, héritez du fichier makefile commun pour system. 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 ou product (et n'installez pas de modules sur la partition system).

  • 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:

  1. Définissez PRODUCT_PRODUCT_VNDK_VERSION := current.

  2. 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 contenant product_specific: true ne sera disponibles pour les modules système. Pour résoudre le problème, remplacez product_specific: true avec system_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éfinissant product_available: true ou déplacez le module vers product partition en définissant product_specific: true.

  3. Résolvez les erreurs de compilation et assurez-vous que l'appareil se compile correctement.

  4. 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 une CANNOT 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: ou required:.

  5. 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 élargir sdk_version ou limiter le 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 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) ; niveau de restriction et 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