Builds für 32-Bit- und 64-Bit-Architekturen erstellen

Das Build-System unterstützt das Erstellen von Binärdateien für zwei CPU-Zielarchitekturen, 32-Bit und 64-Bit im selben Build. Dieser Build mit zwei Zielen wird als multilib build erstellt wurden.

Für integrierte statische und freigegebene Bibliotheken richtet das Buildsystem Regeln ein, um Binärdateien für beide Architekturen zu erstellen. Die Produktkonfiguration (PRODUCT_PACKAGES) legt zusammen mit dem Abhängigkeitsgraphen fest, welche Binärdateien erstellt und im System-Image installiert werden.

Für ausführbare Dateien und Apps wird im Build-System standardmäßig nur die 64‑Bit-Version erstellt. Sie können diese Einstellung jedoch mit einer globalen BoardConfig.mk-Variablen oder einer Variablen auf Modulebene überschreiben.

Zweite CPU-Architektur und ABI identifizieren

BoardConfig.mk enthält die folgenden Variablen zum Konfigurieren der zweiten CPU-Architektur und der Anwendungs-Binärschnittstelle (Application Binary Interface, ABI):

  • TARGET_2ND_ARCH
  • TARGET_2ND_ARCH_VARIANT
  • TARGET_2ND_CPU_VARIANT
  • TARGET_2ND_CPU_ABI
  • TARGET_2ND_CPU_ABI2

Ein Beispiel-Makefile, in dem diese Variablen verwendet werden, finden Sie unter build/make/target/board/generic_arm64/BoardConfig.mk

In einem Multilib-Build werden Modulnamen im PRODUCT_PACKAGES-Cover behandelt. sowohl die 32-Bit- als auch die 64-Bit-Binärdatei, sofern sie durch den Build System. Für Bibliotheken, die nach Abhängigkeit enthalten sind, ist eine 32-Bit- oder 64-Bit-Bibliothek installiert werden, wenn sie für eine andere 32-Bit- oder 64-Bit-Bibliothek benötigt werden, oder ausführbar sein.

Modulnamen in der make-Befehlszeile decken jedoch nur die 64-Bit-Version. Wenn Sie beispielsweise lunch aosp_arm64-eng ausführen, wird mit make libc nur die 64‑Bit-libc erstellt. Um die 32-Bit-libc zu erstellen, müssen Sie make libc_32 ausführen.

Modularchitektur in Android.mk definieren

Mit der Variablen LOCAL_MULTILIB können Sie Ihren Build für 32- und 64-Bit-Systeme konfigurieren und die globale Variable TARGET_PREFER_32_BIT überschreiben.

Wenn Sie TARGET_PREFER_32_BIT überschreiben möchten, setzen Sie LOCAL_MULTILIB auf einen der Folgendes:

  • both bietet sowohl 32-Bit- als auch 64-Bit-Versionen.
  • 32 erstellt nur 32-Bit-Builds.
  • 64 bietet nur 64-Bit-Versionen.
  • first erstellt nur die erste Architektur (32-Bit bei 32-Bit-Geräten). und 64-Bit auf 64-Bit-Geräten).

Standardmäßig ist LOCAL_MULTILIB nicht festgelegt und das Build-System entscheidet anhand der Modulklasse und anderer LOCAL_*-Variablen wie LOCAL_MODULE_TARGET_ARCH und LOCAL_32_BIT_ONLY, welche Architektur erstellt werden soll.

Wenn Sie Ihr Modul für bestimmte Architekturen erstellen möchten, verwenden Sie die folgenden Variablen:

  • LOCAL_MODULE_TARGET_ARCH: Legen Sie für diese Variable eine Liste von Architekturen fest, z. B. arm x86 arm64. Wenn die erstellte Architektur in dieser Liste aufgeführt ist, ist im Build-System enthalten.

  • LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH: Diese Variable ist das Gegenteil von LOCAL_MODULE_TARGET_ARCH. Wenn die zu erstellende Architektur not in dieser Liste ist, wird das aktuelle Modul vom Build-System eingeschlossen.

Es gibt geringfügige Varianten dieser beiden Variablen:

  • LOCAL_MODULE_TARGET_ARCH_WARN
  • LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH_WARN

Das Build-System warnt, wenn das aktuelle Modul aufgrund der Architekturen aufgelistet.

Wenn Sie Build-Flags für eine bestimmte Architektur einrichten möchten, verwenden Sie die architekturspezifischen LOCAL_*-Variablen, wobei * ein architekturspezifisches Suffix ist, z. B.:

  • LOCAL_SRC_FILES_arm, LOCAL_SRC_FILES_x86,
  • LOCAL_CFLAGS_arm, LOCAL_CFLAGS_arm64,
  • LOCAL_LDFLAGS_arm, LOCAL_LDFLAGS_arm64,

Diese Variablen werden nur angewendet, wenn eine Binärdatei erstellt wird. Architektur.

Manchmal ist es einfacher, Flags einzurichten, je nachdem, ob das Binärprogramm die für 32-Bit oder 64-Bit konzipiert sind. Verwenden Sie die Variable LOCAL_* mit dem Suffix _32 oder _64, z. B.:

  • LOCAL_SRC_FILES_32, LOCAL_SRC_FILES_64,
  • LOCAL_CFLAGS_32, LOCAL_CFLAGS_64,
  • LOCAL_LDFLAGS_32, LOCAL_LDFLAGS_64,

Installationspfad der Bibliothek festlegen

Bei einem Build ohne Multilib können Sie mit LOCAL_MODULE_PATH eine Bibliothek an einem anderen Speicherort als dem Standardspeicherort installieren. Beispiel: LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/hw.

Verwenden Sie in einem Multilib-Build jedoch stattdessen LOCAL_MODULE_RELATIVE_PATH:

LOCAL_MODULE_RELATIVE_PATH := hw

Bei diesem Format werden sowohl die 64-Bit- als auch die 32-Bit-Bibliothek im für den richtigen Standort.

Wenn Sie eine ausführbare Datei sowohl als 32-Bit- als auch als 64-Bit-Version erstellen, verwenden Sie eine der folgenden Variablen, um den Installationspfad zu unterscheiden:

  • LOCAL_MODULE_STEM_32, LOCAL_MODULE_STEM_64: Gibt den Namen der installierten Datei an.
  • LOCAL_MODULE_PATH_32, LOCAL_MODULE_PATH_64: Gibt den Installationspfad an.

Zwischenverzeichnis für Quelldateien abrufen

Wenn Sie in einem Multilib-Build Quelldateien generieren, $(local-intermediates-dir) (oder $(intermediates-dir-for)) mit expliziten Variablen) funktioniert, funktioniert er nicht zuverlässig. Das liegt daran, dass die zwischengespeicherten generierten Quellen sowohl für die 32-Bit- als auch für die 64-Bit-Builds erforderlich sind, $(local-intermediates-dir) aber nur auf eines der beiden Zwischenverzeichnisse verweist.

Das Build-System bietet ein spezielles, multilib-freundliches Zwischenverzeichnis zum Generieren von Quellen. So rufen Sie das Zwischenformat ab: des Verzeichnisses angeben, verwenden Sie $(local-generated-sources-dir) oder $(generated-sources-dir-for)-Makro. Die Verwendung dieser Makros ähnelt der von $(local-intermediates-dir) und $(intermediates-dir-for).

Wenn eine Quelldatei in diesem speziellen Verzeichnis generiert und von LOCAL_GENERATED_SOURCES übernommen wird, wird sie in einem Multilib-Build sowohl für 32-Bit- als auch für 64-Bit-Systeme erstellt.

Systemarchitektur vorgefertigter Binärziele angeben

In einem Multilib-Build können Sie weder TARGET_ARCH noch TARGET_ARCH in Kombination mit TARGET_2ND_ARCH, um die Systemarchitektur der vordefinierten binären Zielen. Verwenden Sie stattdessen die Variablen LOCAL_*. LOCAL_MODULE_TARGET_ARCH oder LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH

Mit diesen Variablen kann das Buildsystem das entsprechende vorkompilierte 32-Bit-Binärprogramm auswählen, auch wenn es sich um einen 64-Bit-Multilib-Build handelt.

Wenn Sie die ausgewählte Architektur verwenden möchten, um den Quellpfad für das vorkonfigurierte Binary zu berechnen, rufen Sie $(get-prebuilt-src-arch) auf.

32-Bit- und 64-Bit-ODEX-Datei erstellen

Für 64-Bit-Geräte generiert Google standardmäßig sowohl 32-Bit- als auch 64-Bit-ODEX für das Boot-Image und alle Java-Bibliotheken. Für APKs ist standardmäßig Google generiert ODEX nur für die primäre 64-Bit-Architektur. Wenn eine App sowohl in 32-Bit- als auch in 64-Bit-Prozessen gestartet wird, können Sie mit LOCAL_MULTILIB := both dafür sorgen, dass sowohl 32-Bit- als auch 64-Bit-ODEX-Dateien generiert werden. Wenn die App 32-Bit- oder 64-Bit-JNI-Bibliotheken enthält, weist dieses Flag das Build-System auch an, diese einzubeziehen.