Diese Seite wurde von der Cloud Translation API übersetzt.

VNDK aktivieren

Das Vendor Native Development Kit (VNDK) erfordert mehrere Änderungen an einer Codebasis, um zwischen Anbieter und System zu klären. Folgen Sie dieser Anleitung, um VNDK bei einem Anbieter/OEM zu aktivieren. Codebasis.

Systembibliotheken erstellen

Das Build-System enthält mehrere Objekttypen, einschließlich Bibliotheken (freigegeben, statisch oder Header) und Binärdateien.

Abbildung 1: Erstellen Sie Systembibliotheken.

core-Bibliotheken werden vom System-Image auf dem System-Image verwendet. Diese Bibliotheken können von vendor, vendor_available nicht verwendet werden. vndk- oder vndk-sp-Bibliotheken.
```
cc_library {
    name: "libThatIsCore",
    ...
}
```

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

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

vendor_available-Bibliotheken werden vom Anbieter-Image auf dem Anbieter verwendet. Bild (kann Duplikate von core enthalten)
```
cc_library {
    name: "libThatIsVendorAvailable",
    vendor_available: true,
    ...
}
```

vndk-Bibliotheken werden vom Anbieter-Image auf dem System-Image verwendet.

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

vndk-sp-Bibliotheken werden vom Anbieter-Image und auch vom System-Image verwendet indirekt überfordert.

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 Bibliothek als vendor_available:true markiert ist, wird sie erstellt zweimal:

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

Die Anbieterversionen der Bibliotheken werden mit -D__ANDROID_VNDK__ erstellt. Private Systemkomponenten, die sich in zukünftigen Versionen von erheblich ändern können. Android ist mit diesem Flag deaktiviert. Außerdem exportieren verschiedene Bibliotheken einen anderen Satz von Headern verwenden (z. B. liblog). Spezifische Optionen für eine Anbietervariante eines Ziels kann in einer Android.bp-Datei angegeben werden in:

target: { vendor: { … } }

VNDK für eine Codebasis aktivieren

So aktivieren Sie VNDK für eine Codebasis:

Ermitteln Sie die Eignung, indem Sie die erforderliche Größe vendor.img- und system.img-Partitionen.
BOARD_VNDK_VERSION=current aktivieren. Sie können BoardConfig.mk oder Komponenten direkt damit erstellen (z. B. m -j BOARD_VNDK_VERSION=current MY-LIB).

Nach der Aktivierung von BOARD_VNDK_VERSION=current wird das Build-System erzwingt folgende Anforderungen an Abhängigkeit und Header.

Abhängigkeiten verwalten

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

Die Abhängigkeit kann entfernt werden.
Wenn die Komponente „core“ vendor gehört, kann sie Folgendes tun: als vendor_available oder vendor gekennzeichnet sein.
Eine Änderung, durch die das Hauptobjekt zu einem Teil von vndk wird, könnte sein: die Google vorgelagert sind.

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

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. Zum Beispiel können libutils-Header wie utils/StrongPointer.h können Sie weiterhin über die Header-Bibliothek libutils_headers

Einige Header (z. B. unistd.h) können nicht mehr transitiv eingefügt werden aber lokal eingebunden werden können.

Der öffentliche Teil von private/android_filesystem_config.h wurde nach cutils/android_filesystem_config.h verschoben. Zum Verwalten führen Sie einen der folgenden Schritte aus:

Die Abhängigkeit von private/android_filesystem_config.h, indem alle AID_*-Makros mit getgrnam/ getpwnam-Aufrufe. Hier einige Beispiele: <ph type="x-smartling-placeholder">
- (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 Folgendes an: cutils/android_filesystem_config.h