Activer VNDK

Le kit de développement natif du fournisseur (VNDK) nécessite plusieurs modifications d'une base de code pour séparer les préoccupations entre le fournisseur et le système. Suivez ce guide pour activer le VNDK dans une base de code de fournisseur/OEM.

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 d'en-tête) et des 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 bibliothèques ne peuvent pas être utilisées par les bibliothèques vendor, vendor_available, vndk ni 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 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 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ée dans /system/lib)
• Une fois pour le fournisseur (et donc installée dans /vendor/lib ou VNDK APEX)

Les versions fournisseur des bibliothèques sont créées avec -D__ANDROID_VNDK__. Les composants système privés qui peuvent 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 (tels que liblog). Les options spécifiques à une variante 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 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 des composants à BoardConfig.mk ou les créer directement (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 core composant appartient à vendor, il peut être marqué comme vendor_available ou vendor.
• Une modification qui fait de l'objet principal une partie du 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 déplaçant la dépendance 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 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ête 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, procédez de l'une des manières 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.