Cette page a été traduite par l'API Cloud Translation.

Activer le VNDK

Le Vendor Native Development Kit (VNDK) nécessite plusieurs modifications d'un codebase pour séparer les problèmes entre le fournisseur et le système. Utilisez le guide suivant pour activer VNDK dans un codebase de fournisseur/OEM.

Compiler des bibliothèques système

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

Figure 1 : Créez des 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, et indirectement par l'image du système.

cc_library {
    name: "libThatIsVndkSp",
    vendor_available: true,
    vndk: {
        enabled: true,
        support_system_process: true,
    }
    ...
}

Les bibliothèques llndk sont utilisées à la fois par les images du système et du 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é sur /system/lib)
Une fois pour le fournisseur (et donc installé dans /vendor/lib ou VNDK APEX)

Les versions du fournisseur des bibliothèques sont créées avec -D__ANDROID_VNDK__. Les composants système privés susceptibles de changer de manière significative 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 un codebase

Pour activer le VNDK pour un codebase:

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

Après avoir activé BOARD_VNDK_VERSION=current, le système de compilation applique les exigences de dépendance et d'en-tête suivantes.

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 faisant partie de l'objet principal 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 vers un composant vendor).

Gérer les en-têtes

Les dépendances d'en-tête globales 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 sont toujours accessibles à l'aide de la bibliothèque d'en-têtes libutils_headers.

Certains en-têtes (comme unistd.h) ne peuvent plus être inclus de manière transitive, mais peuvent être inclus 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 envers 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 l'AIS codé en dur, incluez cutils/android_filesystem_config.h.