Attiva VNDK

Il Vendor Native Development Kit (VNDK) richiede diverse modifiche a un codebase per separare tra il fornitore e il sistema. Utilizza la seguente guida per attivare VNDK in un fornitore/OEM codebase.

Crea librerie di sistema

Il sistema di compilazione contiene diversi tipi di oggetti, tra cui le librerie (condivisi, statici o di intestazione) e binari.

Figura 1. Creare librerie di sistema.

• Le librerie core vengono utilizzate dall'immagine di sistema nell'immagine di sistema. Questi le librerie non possono essere utilizzate da vendor, vendor_available, vndk o vndk-sp.

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

• Le librerie vendor-only (o proprietary) vengono utilizzate dalla dell'immagine del fornitore,

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

• vendor_available librerie vengono utilizzate dall'immagine del fornitore, sul fornitore immagine (potrebbe 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 indirettamente.

  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 dalle immagini del fornitore.

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

Quando una lib è contrassegnata come vendor_available:true, viene creata due volte:

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

Le versioni delle librerie del fornitore sono create con -D__ANDROID_VNDK__. Componenti di sistema privati che potrebbero cambiare in modo significativo nelle versioni future di I dispositivi Android sono disabilitati con questo flag. Inoltre, diverse librerie esportano un insieme di intestazioni diverso (ad esempio, liblog). Opzioni specifiche per la variante del fornitore di un target può essere specificata in un file Android.bp tra:

target: { vendor: { … } }

Abilita VNDK per un codebase

Per abilitare la VNDK per un codebase:

1. Determina l'idoneità calcolando le dimensioni richieste Partizioni vendor.img e system.img.
2. Attiva BOARD_VNDK_VERSION=current. Puoi aggiungere BoardConfig.mk o creare componenti direttamente con quest'ultima (ad esempio, m -j BOARD_VNDK_VERSION=current MY-LIB).

Dopo aver abilitato BOARD_VNDK_VERSION=current, il sistema di compilazione applica i seguenti requisiti di dipendenza e intestazione.

Gestisci le dipendenze

Un oggetto vendor che dipende da un componente core che non esiste in vndk o come oggetto vendor devono essere risolti 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 di vndk può essere a Google.

Inoltre, se un componente core ha dipendenze su un Componente vendor, è necessario creare il componente vendor in un componente core oppure la dipendenza deve essere rimosso in altro modo (ad esempio, rimuovendo la dipendenza o spostando una dipendenza in un componente vendor).

Gestisci intestazioni

Le dipendenze dell'intestazione globale devono essere rimosse per consentire al sistema di build di sapere se creare le intestazioni con o senza -D__ANDROID_VNDK__. Ad esempio, le intestazioni libutils come utils/StrongPointer.h possono accessibile tramite la libreria di intestazioni libutils_headers

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

Infine, la parte pubblica di private/android_filesystem_config.h è stato spostato in cutils/android_filesystem_config.h. Per gestire queste intestazioni, procedi in uno dei seguenti modi:

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