Attiva VNDK

Il Vendor Native Development Kit (VNDK) richiede diverse modifiche a una base di codice per separare i problemi tra il fornitore e il sistema. Utilizza la guida riportata di seguito per attivare VNDK in un codebase del fornitore/OEM.

Creare librerie di sistema

Il sistema di compilazione contiene diversi tipi di oggetti, tra cui librerie (condivise, statiche o di intestazione) e file binari.

Figura 1. Crea librerie di sistema.

• Le librerie core vengono utilizzate dall'immagine di sistema. Queste librerie non possono essere utilizzate dalle librerie vendor, vendor_available, vndk o vndk-sp.

  cc_library {
      name: "libThatIsCore",
      ...
  }

• Le librerie vendor-only (o proprietary) vengono utilizzate dall'immagine del fornitore.

  cc_library {
      name: "libThatIsVendorOnly",
      proprietary: true,
      # or: vendor: true, # (for things in AOSP)
      ...
  }

• Le librerie vendor_available vengono utilizzate dall'immagine del fornitore, sull'immagine del fornitore (possono contenere duplicati di core).

  cc_library {
      name: "libThatIsVendorAvailable",
      vendor_available: true,
      ...
  }

• Le librerie vndk vengono utilizzate dall'immagine del fornitore nell'immagine di sistema.

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

• Le librerie vndk-sp vengono utilizzate dall'immagine del fornitore e anche dall'immagine di sistema indirectamente.

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

• Le librerie llndk vengono utilizzate sia dalle immagini di sistema sia da quelle del fornitore.

  cc_library {
      name: "libThatIsLlndk",
      llndk: {
          symbol_file: "libthatisllndk.map.txt"
      }
      ...
  }

Quando una libreria è contrassegnata come vendor_available:true, viene compilata due volte:

• Una volta per la piattaforma (e quindi installata su /system/lib)
• Una volta per il fornitore (e quindi installato in /vendor/lib o VNDK APEX)

Le versioni del fornitore delle librerie sono create con -D__ANDROID_VNDK__. I componenti di sistema privati che potrebbero cambiare in modo significativo nelle versioni future di Android vengono disattivati con questo flag. Inoltre, librerie diverse esportano un insieme diverso di intestazioni (ad esempio liblog). Le opzioni specifiche per una variante del fornitore di un target possono essere specificate in un file Android.bp in:

target: { vendor: { … } }

Attivare VNDK per una base di codice

Per attivare il VNDK per una base di codice:

1. Determina l'idoneità calcolando le dimensioni richieste delle partizioni vendor.img e system.img.
2. Attiva BOARD_VNDK_VERSION=current. Puoi aggiungere elementi a BoardConfig.mk o creare direttamente componenti con questo tipo di proprietà (ad es. m -j BOARD_VNDK_VERSION=current MY-LIB).

Dopo aver attivato BOARD_VNDK_VERSION=current, il sistema di compilazione impone i seguenti requisiti di dipendenze e intestazioni.

Gestire le dipendenze

Un oggetto vendor che dipende da un componente core che non esiste in vndk o come oggetto vendor deve essere risolto utilizzando una delle seguenti opzioni:

• La dipendenza può essere rimossa.
• Se il componente core è di proprietà di vendor, può essere contrassegnato come vendor_available o vendor.
• Una modifica che rende l'oggetto principale parte del vndk potrebbe essere trasferita a Google.

Inoltre, se un componente core ha dipendenze da un componente vendor, il componente vendor deve essere trasformato in un componente core o la dipendenza deve essere rimossa in un altro modo (ad esempio rimuovendo la dipendenza o spostandola in un componente vendor).

Gestire le intestazioni

Le dipendenze delle intestazioni globali devono essere rimosse per consentire al sistema di compilazione di sapere se compilare le intestazioni con o senza -D__ANDROID_VNDK__. Ad esempio, è ancora possibile accedere alle intestazioni libutils come utils/StrongPointer.h utilizzando la libreria di intestazioni libutils_headers.

Alcune intestazioni (ad esempio unistd.h) non possono più essere incluse in modo transitivo, ma possono essere incluse localmente.

Infine, la parte pubblica di private/android_filesystem_config.h è stata spostata in cutils/android_filesystem_config.h. Per gestire queste intestazioni, esegui una delle seguenti operazioni:

• Rimuovi la dipendenza da private/android_filesystem_config.h sostituendo tutte le AID_* macro con chiamate getgrnam/ getpwnam, se possibile. Ad esempio:
  • (uid_t)AID_WIFI diventa getpwnam("wifi")->pw_uid.
  • (gid_t)AID_SDCARD_R diventa getgrnam("sdcard_r")->gr_gid.
  Per maggiori dettagli, consulta private/android_filesystem_config.h.
• Per l'AIS hardcoded, includi cutils/android_filesystem_config.h.