Activer VNDK

Le Vendor Native Development Kit (VNDK) nécessite plusieurs modifications d'une base de code pour séparer les préoccupations entre le fournisseur et le système. Utilisez le guide suivant pour activer VNDK dans une base de code fournisseur/OEM.

Compiler les bibliothèques système

Le système de compilation contient plusieurs types d'objets, y compris des bibliothèques (partagées, statiques ou d'en-tête) et des binaires.

Compiler les bibliothèques système

Figure 1 : Compilez les bibliothèques système.

  • Les bibliothèques core sont utilisées par l'image système, sur l'image système. Ces bibliothèques ne peuvent pas être utilisées par les bibliothèques vendor, vendor_available, vndk ou vndk-sp. 
    cc_library {
    name: "libThatIsCore",
    ...
}
  • Les bibliothèques vendor-only (ou proprietary) sont utilisées par l'image du fournisseur, sur l'image du fournisseur. 
    cc_library {
    name: "libThatIsVendorOnly",
    proprietary: true,
    # or: vendor: true, # (for things in AOSP)
    ...
}
  • Les bibliothèques vendor_available sont utilisées par l'image du fournisseur, sur l'image du fournisseur (peut contenir des doublons de core). 
    cc_library {
    name: "libThatIsVendorAvailable",
    vendor_available: true,
    ...
}
  • Les bibliothèques vndk sont utilisées par l'image du fournisseur sur l'image système. 
    cc_library {
    name: "libThatIsVndk",
    vendor_available: true,
    vndk: {
        enabled: true,
    }
    ...
}
  • Les bibliothèques vndk-sp sont utilisées par l'image du fournisseur, ainsi que par l'image système de manière indirecte. 
    cc_library {
    name: "libThatIsVndkSp",
    vendor_available: true,
    vndk: {
        enabled: true,
        support_system_process: true,
    }
    ...
}
  • Les bibliothèques llndk sont utilisées par les images système et fournisseur. 
    cc_library {
    name: "libThatIsLlndk",
    llndk: {
        symbol_file: "libthatisllndk.map.txt"
    }
    ...
}

Lorsqu'une bibliothèque est marquée comme vendor_available:true, elle est compilée deux fois :

  • Une fois pour la plate-forme (et donc installé dans /system/lib)
  • Une fois pour le fournisseur (et donc installé dans /vendor/lib ou VNDK APEX)

Les versions fournisseur des libs sont créées avec -D__ANDROID_VNDK__. Les composants système privés susceptibles de changer considérablement dans les futures versions d'Android sont désactivés avec cet indicateur. De plus, différentes bibliothèques exportent un ensemble différent d'en-têtes (comme liblog). Les options spécifiques à une variante de fournisseur d'une cible peuvent être spécifiées dans un fichier Android.bp dans :

target: { vendor: { … } }

Activer le VNDK pour une base de code

Pour activer le VNDK pour un code source :

  1. Déterminez l'éligibilité en calculant la taille requise des partitions vendor.img et system.img.
  2. Activer BOARD_VNDK_VERSION=current. Vous pouvez ajouter BoardConfig.mk ou créer des composants directement avec (par exemple, m -j BOARD_VNDK_VERSION=current MY-LIB).

Une fois BOARD_VNDK_VERSION=current activé, le système de compilation applique les exigences suivantes en matière de dépendances et d'en-têtes.

Gestion des dépendances

Un objet vendor qui dépend d'un composant core qui n'existe pas dans vndk ou en tant qu'objet vendor doit être résolu à l'aide de l'une des options suivantes :

  • La dépendance peut être supprimée.
  • Si le composant core appartient à vendor, il peut être marqué comme vendor_available ou vendor.
  • Une modification qui fait de l'objet principal une partie de vndk peut être transmise à Google.

De plus, si un composant core a des dépendances sur un composant vendor, le composant vendor doit être transformé en composant core ou la dépendance doit être supprimée d'une autre manière (par exemple, en supprimant la dépendance ou en la déplaçant dans un composant vendor).

Gérer les en-têtes

Les dépendances d'en-tête global doivent être supprimées pour permettre au système de compilation de savoir s'il doit compiler les en-têtes avec ou sans -D__ANDROID_VNDK__. Par exemple, les en-têtes libutils tels que utils/StrongPointer.h restent accessibles à l'aide de la bibliothèque d'en-têtes libutils_headers.

Certains en-têtes (tels que unistd.h) ne peuvent plus être inclus de manière transitive, mais peuvent l'être localement.

Enfin, la partie publique de private/android_filesystem_config.h a été déplacée vers cutils/android_filesystem_config.h. Pour gérer ces en-têtes, effectuez l'une des opérations suivantes :

  • Supprimez la dépendance à private/android_filesystem_config.h en remplaçant toutes les macros AID_* par des appels getgrnam/getpwnam si possible. Par exemple :
    • (uid_t)AID_WIFI devient getpwnam("wifi")->pw_uid.
    • (gid_t)AID_SDCARD_R devient getgrnam("sdcard_r")->gr_gid.
    Pour en savoir plus, consultez private/android_filesystem_config.h.
  • Pour les AIS codés en dur, incluez cutils/android_filesystem_config.h.