Le 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.
Créer des bibliothèques système
Le système de build contient plusieurs types d'objets, notamment des bibliothèques (partagées, statiques ou en-tête) et des binaires.
- 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èquesvendor
,vendor_available
,vndk
ouvndk-sp
.cc_library { name: "libThatIsCore", ... }
- Les bibliothèques
vendor-only
(ouproprietary
) 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 (peuvent contenir des doublons decore
).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 indirectement par l'image 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 celles 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 construite deux fois :
- Une fois pour la plateforme (et donc installé sur
/system/lib
) - Une fois pour le fournisseur (et donc installé sur
/vendor/lib
ou VNDK APEX)
Les versions fournisseur des bibliothèques sont construites avec -D__ANDROID_VNDK__
. Les composants du système privé 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 fournisseur d'une cible peuvent être spécifiées dans un fichier Android.bp
dans :
target: { vendor: { … } }
Activation de VNDK pour une base de code
Pour activer le VNDK pour une base de code :
- Déterminez l’éligibilité en calculant les tailles requises des partitions
vendor.img
etsystem.img
. - Activez
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
).
Après avoir activé BOARD_VNDK_VERSION=current
, le système de build 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 auvendor
, il peut être marqué commevendor_available
ouvendor
. - Une modification faisant de l'objet principal une partie du
vndk
peut être transmise en amont à 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 déplaçant la dépendance dans un composant vendor
). ).
Gestion des en-têtes
Les dépendances globales des en-têtes doivent être supprimées pour permettre au système de build de savoir s'il doit construire 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 (tels que 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 à
private/android_filesystem_config.h
en remplaçant toutes les macrosAID_*
par des appelsgetgrnam
/getpwnam
si possible. Par exemple:-
(uid_t)AID_WIFI
devientgetpwnam("wifi")->pw_uid
. -
(gid_t)AID_SDCARD_R
devientgetgrnam("sdcard_r")->gr_gid
.
private/android_filesystem_config.h
. -
- Pour l'AIS codé en dur, incluez
cutils/android_filesystem_config.h
.