VNDK aktivieren

Das Vendor Native Development Kit (VNDK) erfordert mehrere Änderungen an einer Codebasis, um die Zuständigkeiten zwischen Anbieter und System zu trennen. Folgen Sie dieser Anleitung, um VNDK in einer Vendor-/OEM-Codebasis zu aktivieren.

Systembibliotheken erstellen

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

Abbildung 1: Systembibliotheken erstellen

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

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

• Die Bibliotheken vendor-only (oder proprietary) werden vom Anbieter-Image im Anbieter-Image verwendet.

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

• vendor_available-Bibliotheken werden vom Anbieter-Image verwendet, im Anbieter-Image (kann Duplikate von core enthalten).

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

• Die vndk-Bibliotheken werden vom Anbieter-Image im System-Image verwendet.

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

• vndk-sp-Bibliotheken werden vom Anbieter-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 Anbieter-Image verwendet.

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

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

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

Die Anbieterversionen von Bibliotheken werden mit -D__ANDROID_VNDK__ erstellt. Private Systemkomponenten, die sich in zukünftigen Versionen von Android erheblich ändern können, werden mit diesem Flag deaktiviert. Außerdem exportieren verschiedene Bibliotheken unterschiedliche Header (z. B. liblog). Optionen, die für eine Anbieter-Variante eines Ziels spezifisch sind, können in einer Android.bp-Datei angegeben werden unter:

target: { vendor: { … } }

VNDK für eine Codebasis aktivieren

So aktivieren Sie das VNDK für eine Codebasis:

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

Nachdem Sie BOARD_VNDK_VERSION=current aktiviert haben, erzwingt das Build-System die folgenden Anforderungen an Abhängigkeiten und Header.

Abhängigkeiten verwalten

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

• Die Abhängigkeit kann entfernt werden.
• Wenn die Komponente core zu vendor gehört, kann sie als vendor_available oder vendor gekennzeichnet werden.
• Eine Änderung, durch die das Kernobjekt Teil von vndk wird, kann an Google weitergeleitet werden.

Wenn eine core-Komponente von einer vendor-Komponente abhängt, muss die vendor-Komponente in eine core-Komponente umgewandelt oder die Abhängigkeit auf andere Weise entfernt werden, z. B. durch Entfernen der Abhängigkeit oder durch Verschieben der Abhängigkeit in eine vendor-Komponente.

Header verwalten

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

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

Der öffentliche Teil von private/android_filesystem_config.h wurde nach cutils/android_filesystem_config.h verschoben. Sie haben folgende Möglichkeiten, diese Überschriften zu verwalten:

• Entfernen Sie die Abhängigkeit von private/android_filesystem_config.h, indem Sie alle AID_*-Makros nach Möglichkeit durch getgrnam-/getpwnam-Aufrufe ersetzen. Beispiel:
  • (uid_t)AID_WIFI wird zu getpwnam("wifi")->pw_uid.
  • (gid_t)AID_SDCARD_R wird zu getgrnam("sdcard_r")->gr_gid.
  Weitere Informationen finden Sie unter private/android_filesystem_config.h.
• Bei hartcodierten AIS muss cutils/android_filesystem_config.h angegeben werden.