Android-Build

Folgen Sie der Anleitung auf dieser Seite, um Android zu erstellen.

Build-Umgebung einrichten

Führen Sie im Arbeitsverzeichnis das envsetup.sh-Skript aus, um die Build-Umgebung einzurichten:

source build/envsetup.sh

Dieses Skript importiert mehrere Befehle, mit denen Sie mit dem Android-Quellcode arbeiten können, einschließlich der auf dieser Seite verwendeten Befehle. Den Quellcode des Skripts finden Sie unter platform/build/envsetup.sh. Geben Sie hmm ein, um die integrierte Hilfe aufzurufen.

Ziel auswählen

Bevor Sie Android erstellen, müssen Sie ein Ziel für den Build festlegen. Ein Ziel gibt die Zielplattform an, für die Sie entwickeln. Verwenden Sie den Befehl lunch gefolgt von einem String, der das Ziel darstellt, um das Ziel für den Build zu identifizieren. Beispiel:

lunch aosp_cf_x86_64_only_phone-aosp_current-userdebug

Sie sollten eine Zusammenfassung Ihrer Ziel- und Build-Umgebung sehen:

============================================
PLATFORM_VERSION_CODENAME=Baklava
PLATFORM_VERSION=Baklava
TARGET_PRODUCT=aosp_cf_x86_64_only_phone
TARGET_BUILD_VARIANT=userdebug
TARGET_ARCH=x86_64
TARGET_ARCH_VARIANT=silvermont
HOST_OS=linux
HOST_OS_EXTRA=Linux-6.10.11-1rodete2-amd64-x86_64-Debian-GNU/Linux-rodete
HOST_CROSS_OS=windows
BUILD_ID=BP1A.250305.020
OUT_DIR=out
============================================

Der String, der das Ziel darstellt, hat das folgende Format:

lunch product_name-release_config-build_variant

Die Komponenten dieses Strings sind:

  • product_name ist der Name des Produkts, das Sie erstellen möchten, z. B. aosp_cf_x86_64_only_phone oder aosp_husky. Die spezifische product_name kann ein eigenes Format für Ihr Gerät haben. Das Format, das Google für seine Geräte verwendet, hat jedoch die folgenden Komponenten:

    • aosp bezieht sich auf die Android Open Source Platform.
    • (optional) cf ist enthalten, wenn das Ziel im Cuttlefish-Emulator ausgeführt werden soll.
    • Architektur und Hardware (Codename), z. B. x86_64_only_phone oder husky, der Codename für das Pixel 8 Pro. Eine Liste der Codenamen für Google-Geräte finden Sie unter Geräte-Codenamen.

  • release_config ist auf eine Releasekonfiguration festgelegt, z. B. die Entwicklungsreleasekonfiguration mit dem Namen aosp_current. Eine Release-Konfiguration identifiziert bestimmte Funktionen und Code, die sich hinter Flags für die Einführung von Funktionen befinden und für einen Build entweder aktiviert oder deaktiviert sind. Weitere Informationen zu Release-Konfigurationen finden Sie unter Startwerte für Feature-Flags festlegen.

  • Der build_variant-Teil des Strings kann einen der drei Werte in der folgenden Tabelle haben:

    build_variant Beschreibung
    user Diese Build-Variante bietet eingeschränkten Sicherheitszugriff und eignet sich für die Produktion.
    userdebug Diese Build-Variante hilft Geräteentwicklern, die Leistung und den Stromverbrauch von Releases in der Entwicklung zu verstehen. Wenn Sie mit einem userdebug-Build entwickeln, halten Sie sich an die Richtlinien für userdebug.
    eng Diese Build-Variante lässt sich schneller erstellen und eignet sich am besten für die tägliche Entwicklung, wenn Leistung und Stromverbrauch keine Rolle spielen.

Wenn Sie lunch ohne Argumente ausführen, wird eine Liste mit häufig verwendeten Zielen angezeigt. Sie können auch eigene Zielstrings erstellen, indem Sie die Elemente des Zielstrings mithilfe der Informationen auf dieser Seite und der Codenamen, die bestimmte Google-Hardware unter Geräte-Codenamen darstellen, zusammensetzen.

Aktuelles Ziel ansehen

So rufen Sie die aktuellen Einstellungen für das Mittagessen auf:

$ echo "$TARGET_PRODUCT-$TARGET_BUILD_VARIANT"

Code erstellen

Führen Sie den folgenden Befehl aus, um das Ziel zu erstellen. Je nach Spezifikation Ihrer Workstation kann der erste Build weniger als eine Stunde oder bis zu einigen Stunden dauern. Nachfolgende Builds dauern deutlich weniger lange.

m

Die Ausgabe Ihres Builds wird in $OUT_DIR angezeigt. Wenn Sie verschiedene Ziele erstellen, wird jeder Ziel-Build in $OUT_DIR angezeigt.

Der Befehl m wird von der Spitze des Baums aus ausgeführt. Sie können m also in Unterverzeichnissen ausführen. Wenn Sie die Umgebungsvariable TOP festgelegt haben, wird sie vom Befehl m verwendet. Wenn TOP nicht festgelegt ist, sucht der Befehl m im Baum vom aktuellen Verzeichnis aus nach oben, um den oberen Teil des Baums zu finden.

Der Befehl m kann parallele Aufgaben mit einem -jN-Argument verarbeiten. Wenn Sie kein -j-Argument angeben, wählt das Build-System automatisch eine Anzahl paralleler Aufgaben aus, die es für Ihr System als optimal erachtet.

Sie können bestimmte Module anstelle des vollständigen Geräte-Images erstellen, indem Sie Modulnamen in der Befehlszeile für m auflisten. Außerdem bietet der Befehl m einige Pseudoziele, die als goals bezeichnet werden. Mit m nothing wird beispielsweise nichts erstellt, sondern die Build-Struktur wird nur geparst und validiert. Eine Liste der gültigen Ziele erhalten Sie mit dem Befehl m help.

Build-Fehler beheben (Android 8.0 oder früher)

Wenn Sie AOSP 8 oder früher erstellen, wird m möglicherweise abgebrochen, wenn ein Problem mit Ihrer Java-Version auftritt. Beispiel:

************************************************************
You are attempting to build with the incorrect version
of java.

Your version is: WRONG_VERSION.
The correct version is: RIGHT_VERSION.

Please follow the machine setup instructions at
    https://source.android.com/source/initializing.html
************************************************************

Hier sind die wahrscheinlichen Ursachen und Lösungen:

  • Sie haben das richtige JDK nicht wie in den JDK-Abschnitten von AOSP-Entwicklung einrichten (2.3–8.0) angegeben installiert.
  • In Ihrem Pfad ist ein anderes, zuvor installiertes JDK vorhanden. Stellen Sie den richtigen JDK an den Anfang Ihres Pfads oder entfernen Sie den problematischen JDK.