Aktivieren des VNDK

Das VNDK erfordert mehrere Änderungen an einer Codebasis, um die Bedenken zwischen Anbieter und System zu trennen. Verwenden Sie die folgende Anleitung, um VNDK in einer Anbieter-/OEM-Codebasis zu aktivieren.

Erstellen Sie Systembibliotheken

Das Build-System enthält verschiedene Arten von Objekten, darunter Bibliotheken (gemeinsam genutzt, statisch oder Header) und Binärdateien.

Abbildung 1. Systembibliotheken erstellen

• core werden vom System-Image auf dem System-Image verwendet. Diese Bibliotheken können nicht von den Bibliotheken vendor , vendor_available , vndk “ oder vndk-sp verwendet werden.

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

• vendor-only (oder proprietary ) Bibliotheken werden vom Anbieter-Image auf dem Anbieter-Image verwendet.

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

• vendor_available Bibliotheken werden vom Anbieter-Image auf dem Anbieter-Image verwendet (können Duplikate von core enthalten).

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

• vndk Bibliotheken werden vom Hersteller-Image auf dem System-Image verwendet.

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

• vndk-sp Bibliotheken werden vom Hersteller-Image und indirekt auch vom System-Image verwendet.

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

• llndk Bibliotheken werden sowohl vom System als auch vom Hersteller-Image verwendet.

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

Wenn eine Bibliothek als vendor_available:true markiert ist, wird sie zweimal erstellt:

• Einmal für die Plattform (und daher in /system/lib installiert)
• Einmal für den Anbieter (und daher in /vendor/lib oder VNDK APEX installiert)

Die Herstellerversionen von Bibliotheken werden mit -D__ANDROID_VNDK__ erstellt. Mit diesem Flag werden private Systemkomponenten deaktiviert, die sich in zukünftigen Android-Versionen erheblich ändern können. Darüber hinaus exportieren verschiedene Bibliotheken unterschiedliche Headersätze (z. B. liblog ). Spezifische Optionen für eine Anbietervariante eines Ziels können in einer Android.bp Datei angegeben werden in:

target: { vendor: { … } }

Aktivieren von VNDK für eine Codebasis

So aktivieren Sie das VNDK für eine Codebasis:

1. Bestimmen Sie die Eignung, indem Sie die erforderlichen Größen der vendor.img und system.img Partitionen berechnen.
2. Aktivieren Sie BOARD_VNDK_VERSION=current . Sie können BoardConfig.mk hinzufügen oder Komponenten direkt damit erstellen (z. B. m -j BOARD_VNDK_VERSION=current MY-LIB ).

Nach der Aktivierung von BOARD_VNDK_VERSION=current erzwingt das Build-System die folgenden Abhängigkeits- und Header-Anforderungen.

Abhängigkeiten verwalten

Ein vendor , das von einer core abhängt, die nicht in vndk oder als vendor vorhanden ist, muss mit einer der folgenden Optionen aufgelöst werden:

• Die Abhängigkeit kann entfernt werden.
• Wenn die core dem vendor gehört, kann sie als vendor_available “ oder vendor markiert werden.
• Eine Änderung, durch die das Kernobjekt Teil des vndk wird, kann an Google weitergegeben werden.

Wenn eine core außerdem Abhängigkeiten von einer vendor aufweist, muss die vendor in eine core umgewandelt werden oder die Abhängigkeit muss auf andere Weise entfernt werden (z. B. durch Entfernen der Abhängigkeit oder durch Verschieben der Abhängigkeit in eine vendor ). ).

Header verwalten

Globale Header-Abhängigkeiten müssen entfernt werden, damit das Build-System weiß, ob die Header mit oder ohne -D__ANDROID_VNDK__ erstellt werden sollen. Auf libutils-Header wie utils/StrongPointer.h kann beispielsweise weiterhin über die Header-Bibliothek libutils_headers zugegriffen werden.

Einige Header (z. B. unistd.h ) können nicht mehr transitiv, sondern lokal eingebunden werden.

Schließlich wurde der öffentliche Teil von private/android_filesystem_config.h nach cutils/android_filesystem_config.h verschoben. Um diese Header zu verwalten, führen Sie einen der folgenden Schritte aus:

• Entfernen Sie die Abhängigkeit von private/android_filesystem_config.h , indem Sie nach Möglichkeit alle AID_* Makros durch getgrnam / getpwnam Aufrufe ersetzen. Zum Beispiel:
  • (uid_t)AID_WIFI wird getpwnam("wifi")->pw_uid .
  • (gid_t)AID_SDCARD_R wird zu getgrnam("sdcard_r")->gr_gid .
  Einzelheiten finden Sie unter private/android_filesystem_config.h .
• Für hartcodiertes AIS schließen Sie cutils/android_filesystem_config.h ein.