Android-Build

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

Build-Umgebung einrichten

Rufen Sie das envsetup.sh-Script in Ihrem Arbeitsverzeichnis auf, um die Buildumgebung einzurichten:

source build/envsetup.sh

Dieses Script importiert mehrere Befehle, mit denen Sie mit dem Android-Quellcode arbeiten können, einschließlich der auf dieser Seite verwendeten Befehle. Die Quelle des Scripts 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 auswählen. Ein Ziel spiegelt die Zielplattform wider, für die Sie eine App entwickeln. Geben Sie das Ziel für den Build mit dem Befehl lunch und einem String an, der das Ziel darstellt. Beispiel:

lunch aosp_cf_x86_64_phone-trunk_staging-userdebug

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

============================================
PLATFORM_VERSION_CODENAME=VanillaIceCream
PLATFORM_VERSION=VanillaIceCream
PRODUCT_INCLUDE_TAGS=com.android.mainline
TARGET_PRODUCT=aosp_arm
TARGET_BUILD_VARIANT=eng
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
TARGET_CPU_VARIANT=generic
HOST_OS=linux
HOST_OS_EXTRA=Linux-6.5.13-1rodete2-amd64-x86_64-Debian-GNU/Linux-rodete
HOST_CROSS_OS=windows
BUILD_ID=AOSP.MAIN
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_phone oder aosp_husky. Ihr product_name kann ein eigenes Format für Ihr Gerät haben. Das von Google für seine Geräte verwendete Format besteht jedoch aus den folgenden Komponenten:

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

  • release_config ist auf eine Releasekonfiguration festgelegt, z. B. die Entwicklungs-Releasekonfiguration namens trunk_staging. In einer Release-Konfiguration werden bestimmte Funktionen und Code identifiziert, die hinter Flags für die Einführung von Funktionen stehen und für einen Build entweder aktiviert oder deaktiviert sind. Weitere Informationen zu Releasekonfigurationen finden Sie unter Startwerte für Feature-Flags festlegen.

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

    build_variant Beschreibung
    user Diese Buildvariante bietet eingeschränkten Sicherheitszugriff und eignet sich für die Produktion.
    userdebug Diese Buildvariante hilft den Geräteentwicklern, die Leistung und Leistungsfähigkeit von Releases in der Entwicklungsphase zu verstehen. Beachten Sie bei der Entwicklung mit einem userdebug-Build die Richtlinien für userdebug.
    eng Diese Buildvariante hat eine kürzere Buildzeit und eignet sich am besten für die tägliche Entwicklung, wenn Sie nicht auf Leistung und Stromverbrauch achten.

Wenn Sie lunch ohne Argumente ausführen, wird eine Liste gängiger Ziele angezeigt. Sie können auch eigene Zielstrings erstellen, indem Sie die Elemente des Zielstrings anhand der Informationen auf dieser Seite und der Codenamen zusammensetzen, die bestimmte Google-Hardware repräsentieren. Diese finden Sie unter Gerätecodenamen.

Aktuelles Ziel ansehen

So rufen Sie die aktuellen Mittagseinstellungen 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 mehrere Stunden dauern. Nachfolgende Builds dauern deutlich weniger Zeit.

m

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

Der Befehl m wird von oben nach unten ausgeführt. Sie können ihn also auch in Unterverzeichnissen ausführen.m Wenn Sie die Umgebungsvariable TOP festgelegt haben, wird sie vom Befehl m verwendet. Wenn TOP nicht festgelegt ist, sucht der Befehl m im Verzeichnisbaum vom aktuellen Verzeichnis aus nach dem Stamm des Baums.

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 anstelle des vollständigen Geräte-Images bestimmte Module erstellen, indem Sie die Modulnamen in der m-Befehlszeile auflisten. Außerdem bietet der Befehl m einige Pseudoziele, die als Ziele bezeichnet werden. Mit m nothing wird beispielsweise nichts erstellt, sondern die Build-Struktur wird geparst und validiert. Geben Sie m help ein, um eine Liste der gültigen Zielvorhaben aufzurufen.

Build-Fehler beheben (8.0 oder älter)

Wenn Sie AOSP 8 oder älter erstellen, wird m möglicherweise abgebrochen, wenn ein Problem mit Ihrer Java-Version auftritt. Möglicherweise wird Ihnen folgende Meldung angezeigt:

************************************************************
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 wahrscheinlichsten Ursachen und Lösungen:

  • Sie haben nicht das richtige JDK installiert, wie in den JDK-Abschnitten des Artikels Einrichtung für die AOSP-Entwicklung (2.3–8.0) angegeben.
  • In Ihrem Pfad wird ein anderes zuvor installiertes JDK angezeigt. Fügen Sie das richtige JDK an den Anfang des Pfads ein oder entfernen Sie das problematische JDK.