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

Activer le VNDK

Le kit de développement natif pour fournisseurs (VNDK) nécessite plusieurs modifications du codebase pour séparer entre le fournisseur et le système. Utilisez ce guide pour activer le VNDK chez un fournisseur/OEM de votre codebase.

Créer des bibliothèques système

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

Figure 1 : Créer des bibliothèques système

Les bibliothèques core sont utilisées par l'image système, sur l'image système. Ces les bibliothèques ne peuvent pas être utilisées par vendor, vendor_available, vndk ou vndk-sp.
```
cc_library {
    name: "libThatIsCore",
    ...
}
```

Les bibliothèques vendor-only (ou proprietary) sont utilisées par les 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 le fournisseur image (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 indirectement.

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ée sur /system/lib)
Une fois pour le fournisseur (et donc installé dans /vendor/lib ou VNDK APEX)

Les versions des fournisseurs des bibliothèques sont créées avec -D__ANDROID_VNDK__. Composants système privés susceptibles de changer de manière significative dans les futures versions de Android est désactivé avec cet indicateur. De plus, différentes bibliothèques exportent un autre ensemble d'en-têtes (comme liblog). Les options spécifiques à un La variante de fournisseur d'une cible peut être spécifiée 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 de Partitions vendor.img et system.img.
Activer BOARD_VNDK_VERSION=current. Vous pouvez ajouter à BoardConfig.mk ou créer des composants directement avec celui-ci (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 suivantes en termes de dépendances et d'en-tête.

Gestion des dépendances

Un objet vendor qui dépend d'un composant core qui n'existe pas dans vndk ni en tant qu'objet vendor doit être résolu de l'une des façons suivantes:

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

De plus, si un composant core a des dépendances sur un vendor, le composant vendor doit être configuré dans un composant core ou la dépendance doit être supprimé d'une autre manière (par exemple, en supprimant la dépendance ou en déplaçant le dans 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 les en-têtes avec ou sans -D__ANDROID_VNDK__. Par exemple, les en-têtes libutils tels que utils/StrongPointer.h peuvent reste accessible à 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 transitoire mais il peut être inclus localement.

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

Supprimez la dépendance pour private/android_filesystem_config.h en remplaçant tous Macros AID_* avec getgrnam/ getpwnam si possible. Par exemple: <ph type="x-smartling-placeholder">
- (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