Abilitazione del VNDK

Il VNDK richiede diverse modifiche a una codebase per separare le preoccupazioni tra fornitore e sistema. Utilizza la seguente guida per abilitare VNDK in una codebase fornitore/OEM.

Costruisci librerie di sistema

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

Figura 1. Creazione di librerie di sistema

• le librerie core vengono utilizzate dall'immagine di sistema, sull'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, sull'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 (potrebbero contenere duplicati di core ).

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

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

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

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

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

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

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

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

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

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

target: { vendor: { … } }

Abilitazione di VNDK per una codebase

Per abilitare il VNDK per una codebase:

1. Determinare l'idoneità calcolando le dimensioni richieste delle partizioni vendor.img e system.img .
2. Abilita BOARD_VNDK_VERSION=current . Puoi aggiungere a BoardConfig.mk o creare componenti direttamente con esso (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.

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à del vendor , può essere contrassegnato come vendor_available o vendor .
• Una modifica che renda l'oggetto principale parte del vndk potrebbe essere trasmessa a Google.

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

Gestione delle intestazioni

Le dipendenze delle intestazioni globali devono essere rimosse per consentire al sistema di compilazione di sapere se creare 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 (come 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, effettuare una delle seguenti operazioni:

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