Ab 2026 werden wir, um unser stabiles Entwicklungsmodell für den Trunk zu unterstützen und die Plattformstabilität für das Ökosystem zu gewährleisten, den Quellcode im 2. und 4. Quartal in AOSP veröffentlichen. Verwenden Sie android-latest-release, um AOSP zu entwickeln und dazu beizutragen. Der Manifestzweig android-latest-release verweist immer auf das neueste Release, das an AOSP übertragen wurde. Weitere Informationen finden Sie unter Änderungen an AOSP.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Android-Build

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

Build-Umgebung einrichten

Rufen Sie im Arbeitsverzeichnis das Skript envsetup.sh auf, 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 Befehle, die auf dieser Seite verwendet werden. 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 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 festzulegen. Beispiel:

lunch aosp_cf_x86_64_only_phone-aosp_current-userdebug

Sie sollten eine Zusammenfassung des Ziels und der 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. Ihr spezifischer 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 das Open-Source-Projekt für Android.
- Optional wird cf verwendet, 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 Codenamen von Geräten.
release_config ist auf eine Releasekonfiguration festgelegt, z. B. die Releasekonfiguration für die Entwicklung aosp_current. Eine Releasekonfiguration gibt bestimmte Funktionen und Code an, 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 Releasekonfigurationen finden Sie unter Funktions-Flag-Einführungswerte festlegen.

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

`build_variant`	Beschreibung
`user`	Diese Build-Variante bietet eingeschränkten Sicherheitszugriff und ist für die Produktion geeignet.
`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, folgen Sie den Richtlinien für userdebug.
`eng`	Diese Build-Variante hat eine schnellere Build-Zeit und ist am besten für alltägliche Entwicklungsumgebungen geeignet, in denen Leistung und Stromverbrauch weniger wichtig sind.

Wenn Sie lunch ohne Argumente ausführen, wird eine Liste häufig verwendeter Ziele angezeigt.lunch Um benutzerdefinierte Zielstrings zu erstellen, kombinieren Sie Zielstringelemente mit Hardware-Codenamen. Eine Liste der Codenamen finden Sie unter Codenamen von Geräten.

Aktuelles Ziel ansehen

Führen Sie Folgendes aus, um die aktuellen Einstellungen für `lunch` zu sehen:

$ 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 Zeit.

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 erstellt den Build von der obersten Ebene der Struktur aus. Sie können m also in Unterverzeichnissen ausführen. Wenn die Umgebungsvariable TOP festgelegt ist, verwendet der Befehl m sie. Wenn TOP nicht festgelegt ist, sucht der Befehl m in der Struktur vom aktuellen Verzeichnis aus nach der obersten Ebene.

Der Befehl m kann parallele Aufgaben mit dem Argument -jN 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-Image erstellen, indem Sie die Modulnamen in der Befehlszeile m auflisten. Außerdem bietet der Befehl m einige Pseudo-Ziele, sogenannte Goals. Mit m nothing wird beispielsweise nichts erstellt, aber die Build-Struktur wird geparst und validiert. Eine Liste gültiger Ziele erhalten Sie mit dem Befehl m help.

Build-Fehler beheben

In diesem Abschnitt finden Sie eine Anleitung zum Beheben von Build-Fehlern.

Fehler im schreibgeschützten Dateisystem (Android 17 und höher)

Während des Builds ist die AOSP-Quellstruktur schreibgeschützt. Wenn der ausgeführte Build versucht, die Quellstruktur während der Produktkonfiguration oder in einem anderen Teil des Builds zu ändern, kann der Build fehlschlagen und Fehler im schreibgeschützten Dateisystem melden. Mit diesen Optionen können Sie die Quellstruktur vorübergehend in „Lesen/Schreiben“ ändern:

Wenn Sie die gesamte Quellstruktur während des Builds in „Lesen/Schreiben“ ändern möchten, fügen Sie der Build-Umgebung BUILD_BROKEN_SRC_DIR_IS_WRITABLE=true hinzu.
Wenn Sie einen Teil der Struktur während des Builds in „Lesen/Schreiben“ ändern möchten, verwenden Sie BUILD_BROKEN_SRC_DIR_RW_ALLOWLIST="path1, path2, ...". Die Pfade sollten die Pfade der Verzeichnisse sein, in denen Schreibvorgänge zulässig sein sollen, relativ zur obersten Ebene des Arbeitsbereichs.

Falsche Java-Version (Android 8.0 und niedriger)

Wenn Sie Android 8.0 (API-Level 26) und niedriger erstellen, wird m möglicherweise abgebrochen, wenn ein Problem mit Ihrer Java-Version auftritt. Beispiel: Sie erhalten möglicherweise die folgende Meldung:

************************************************************
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:

Das richtige JDK ist nicht installiert. Weitere Informationen finden Sie unter Für die AOSP-Entwicklung einrichten (2.3–8.0).
In Ihrem Pfad ist ein anderes, zuvor installiertes JDK vorhanden. Fügen Sie das richtige JDK am Anfang des Pfads hinzu oder entfernen Sie das problematische JDK.