VNDK aktivieren

Das Vendor Native Development Kit (VNDK) erfordert mehrere Änderungen an einer Codebasis, um Probleme zwischen Anbieter und System zu trennen. In der folgenden Anleitung wird beschrieben, wie Sie VNDK in der Codebasis eines Anbieters/OEMs aktivieren.

Systembibliotheken erstellen

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

Systembibliotheken erstellen

Abbildung 1: Systembibliotheken erstellen

  • core-Bibliotheken werden vom System-Image verwendet. Diese Bibliotheken können nicht von vendor-, vendor_available-, vndk- oder vndk-sp-Bibliotheken verwendet werden. 
    cc_library {
    name: "libThatIsCore",
    ...
}
  • vendor-only- (oder proprietary-) Bibliotheken werden vom Anbieterimage auf dem Anbieterimage verwendet. 
    cc_library {
    name: "libThatIsVendorOnly",
    proprietary: true,
    # or: vendor: true, # (for things in AOSP)
    ...
}
  • vendor_available-Bibliotheken werden vom Anbieterbild verwendet (können Duplikate von core enthalten). 
    cc_library {
    name: "libThatIsVendorAvailable",
    vendor_available: true,
    ...
}
  • 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 von System- als auch von Anbieter-Images verwendet. 
    cc_library {
    name: "libThatIsLlndk",
    llndk: {
        symbol_file: "libthatisllndk.map.txt"
    }
    ...
}

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

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

Die Anbieterversionen der libs 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 Anbietervariante eines Ziels spezifisch sind, können in einer Android.bp-Datei in folgenden Formaten angegeben werden:

target: { vendor: { … } }

VNDK für eine Codebasis aktivieren

So aktivieren Sie den VNDK für eine Codebasis:

  1. Bestimmen 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 hinzufügen oder direkt damit Komponenten erstellen (z. B. m -j BOARD_VNDK_VERSION=current MY-LIB).

Nachdem BOARD_VNDK_VERSION=current aktiviert wurde, erzwingt das Build-System die folgenden Abhängigkeits- und Headeranforderungen.

Abhängigkeiten verwalten

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

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

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

Überschriften verwalten

Globale Headerabhä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 nur noch lokal eingeschlossen werden.

Der öffentliche Teil von private/android_filesystem_config.h wurde schließlich zu cutils/android_filesystem_config.h verschoben. So verwalten Sie diese Überschriften:

  • Entfernen Sie die Abhängigkeit von private/android_filesystem_config.h, indem Sie nach Möglichkeit alle AID_*-Makros 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.
  • Geben Sie für hartcodierte AIS-Daten cutils/android_filesystem_config.h ein.