Appliquer les interfaces de partitionnement des produits

Android 11 dissocie la partition product, la rendant indépendante des partitions 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 (comme pour l'application des interfaces pour les partitions vendor).

Appliquer les 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.) Les mesures d'application permettent :

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

L'application des règles n'autorise pas les liens vers des partitions autres que la partition product.

Application du temps de compilation (Android.bp)

Dans Android 11, les modules système peuvent créer une variante d'image produit en plus des variantes d'image principale et 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 et non dans la variante principale.

  • Les modules comportant 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 associé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 contenir product_available: true dans leurs fichiers Android.bp pour 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 des variantes d'image.

Propriétés dans Android.bp Variantes créées
Avant l'application Après l'application
par défaut (aucune) core
(inclut /system, /system_ext et /product)		 core
(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 core, vendor core, vendor
product_available: true N/A core, product
vendor_available: true ET product_available: true N/A core, product, vendor
system_ext_specific: true ET vendor_available: true core, vendor core, vendor
product_specific: true ET vendor_available: true core, vendor produit, fournisseur

Application de la durée de compilation (Android.mk)

Lorsque l'application de l'interface native est activée, les modules natifs installés dans la partition product ont un type de lien native:product qui ne peut être associé qu'à d'autres modules native:product ou native:vndk. Si vous tentez d'associer d'autres modules, le système de compilation génère une erreur de vérification du type de lien.

Application lors 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, ce qui crée une section product pour les processus product qui ne peuvent pas être associés à des bibliothèques en dehors de la partition product (toutefois, ces processus peuvent être associés à des bibliothèques VNDK). Toute tentative d'enfreindre la configuration du lien d'exécution entraîne l'échec du processus et la génération d'un message d'erreur CANNOT LINK EXECUTABLE.

Appliquer 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 de livraison pour la cible est supérieur à 29.) Lorsqu'elle est activée, l'application autorise ou refuse les accès suivants :

API /system /system_ext /product /vendor /data
API publique
@SystemApi
@hide API

Comme dans la partition vendor, une application ou une bibliothèque Java dans la partition product n'est autorisée à utiliser que les API publiques et système. Il n'est pas autorisé de créer un lien vers une bibliothèque qui utilise des API masquées. Cette restriction inclut l'association au moment de la compilation et la réflexion au moment de l'exécution.

Application au moment de la compilation

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

Application lors de l'exécution

Le runtime Android vérifie que les applications de la partition product n'utilisent pas d'API cachées, y compris la réflexion. Pour en savoir plus, consultez Restrictions sur les interfaces non-SDK.

Activer l'application de l'interface produit

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

Étape Tâche Obligatoire
1 Définissez votre propre fichier make système qui spécifie les packages pour la partition system, puis définissez la vérification des exigences du chemin d'accès aux artefacts dans device.mk (pour empêcher l'installation de modules non système dans la partition system). N
2 Nettoyez la liste des adresses autorisées. N
3 Appliquez les interfaces natives et identifiez les échecs de liens d'exécution (peut s'exécuter en parallèle avec l'application Java). O
4 Appliquez les interfaces Java et vérifiez le comportement d'exécution (peut s'exécuter en parallèle avec l'application native). O
5 Vérifiez les comportements d'exécution. O
6 Mise à jour de device.mk avec l'application de l'interface produit. O

Étape 1 : Créer un fichier makefile et activer la vérification du chemin d'accès aux artefacts

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. Par exemple, créez un fichier oem_system.mk avec le contenu suivant :

    $(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 la partition system et activez la vérification des exigences relatives au chemin d'accès aux artefacts. 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'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 make dans les chemins d'accès définis dans require-artifacts-in-path et empêche l'installation des packages définis dans le fichier make actuel dans les chemins d'accès définis dans require-artifacts-in-path.

Dans l'exemple ci-dessus, avec PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS défini sur strict, les fichiers makefile en dehors de oem_system.mk ne peuvent pas inclure les modules installés dans les partitions root ou system. Pour inclure ces modules, vous devez les définir dans le fichier oem_system.mk lui-même ou dans un fichier makefile inclus. Les tentatives d'installation de modules dans des chemins non autorisés entraînent des échecs de compilation. Pour corriger les sauts de ligne, effectuez l'une des opérations suivantes :

  • Option 1 : Incluez le module système dans les fichiers makefiles inclus dans oem_system.mk. Cela permet de répondre à l'exigence concernant le chemin d'accès aux artefacts (puisque les modules existent désormais dans un fichier makefile inclus) et permet ainsi l'installation dans l'ensemble des chemins d'accès dans `require-artifacts-in-path`.

  • Option 2 : Installez les modules dans la partition system_ext ou product (et ne les installez pas dans la partition system).

  • Option 3 : Ajoutez des modules au PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST. Cette liste indique les modules autorisés à être installés.

Étape 2 : Videz la liste des autorisations

Dans cette étape, vous videz PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST afin que tous les appareils partageant oem_system.mk puissent également partager une seule image system. Pour vider la liste autorisée, déplacez les modules de la liste vers la partition system_ext ou product, ou ajoutez-les aux fichiers make system. Cette étape est facultative, car il n'est pas nécessaire de définir une image system commune pour activer l'application de l'interface produit. Toutefois, vider la liste des autorisations 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 vous recherchez les erreurs de compilation et d'exécution et vous les corrigez. Pour vérifier le démarrage et les journaux de l'appareil, et pour trouver et corriger les échecs de liens d'exécution :

  1. Définissez PRODUCT_PRODUCT_VNDK_VERSION := current.

  2. Compilez l'appareil et recherchez les erreurs de compilation. Vous verrez probablement quelques erreurs de compilation pour les variantes de produit ou les variantes principales manquantes. Voici quelques exemples de pauses courantes :

    • Les modules hidl_interface qui comportent product_specific: true ne seront pas disponibles pour les modules système. Pour résoudre ce problème, remplacez product_specific: true par system_ext_specific: true.
    • Il est possible que les modules ne contiennent pas la variante de produit requise pour les modules de produits. 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.

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

  4. Flashez l'image et recherchez les erreurs d'exécution dans le démarrage et les journaux de l'appareil.

    • Si le tag linker d'un journal de cas de test affiche un message CANNOT LINK EXECUTABLE, cela signifie qu'une dépendance est manquante dans le fichier make (et n'a pas été capturée lors de la compilation).
    • Pour le 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 conseils ci-dessus.

Étape 4 : Appliquer les interfaces Java

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

  • Erreurs de type d'association. Cette erreur indique qu'une application établit un lien vers des modules Java qui ont une portée sdk_version plus large. Pour résoudre le problème, vous pouvez élargir le sdk_version de l'application 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 symbole Cette erreur indique qu'un symbole est introuvable, car il se trouve dans une API masquée. Pour résoudre ce problème, utilisez une API visible (non masquée) ou trouvez une autre solution. 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 vérifiez que les comportements d'exécution sont conformes aux attentes. Pour les applications débogables, vous pouvez surveiller l'utilisation des API masquées par journal à 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 (association 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 en savoir plus sur l'utilisation de veridex, consultez Test avec l'outil veridex.

Étape 6 : Mettez à jour device.mk

Après avoir corrigé toutes les erreurs de compilation et d'exécution, et vérifié que les comportements d'exécution sont conformes aux attentes, définissez les éléments suivants dans device.mk :

  • PRODUCT_PRODUCT_VNDK_VERSION := current
  • PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true