Activation du VNDK

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.

Créer des bibliothèques système
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 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 (peuvent 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 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 :

  1. Déterminez l’éligibilité en calculant les tailles requises des partitions vendor.img et system.img .
  2. 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 au vendor , il peut être marqué comme vendor_available ou vendor .
  • 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 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 plus de détails, reportez-vous à private/android_filesystem_config.h .
  • Pour l'AIS codé en dur, incluez cutils/android_filesystem_config.h .