Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Android-Entwicklung ausprobieren
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

In dieser Anleitung können Sie zum ersten Mal die Entwicklung des Android-Betriebssystems ausprobieren.

Für die Android-Entwicklung einrichten

Bevor Sie den android-latest-release-Manifest-Branch der Android-Quelle herunterladen und erstellen, prüfen Sie, ob Ihre Hardware die erforderlichen Anforderungen erfüllt und die erforderliche Software richtig installiert ist. Außerdem sollten Sie mit den folgenden Begriffen vertraut sein:

Git: Git ist ein kostenloses und Open-Source-verfügbares verteiltes Versionskontrollsystem. Android verwendet Git für lokale Vorgänge wie Verzweigung, Commits, Differenzen und Änderungen. Informationen zum Erlernen von Git finden Sie in der Git-Dokumentation.
Repository: Repo ist ein Python-Wrapper für Git, der die Ausführung komplexer Vorgänge in mehreren Git-Repositories vereinfacht. Repo ersetzt Git nicht für alle Versionskontrollvorgänge, sondern vereinfacht nur komplexe Git-Vorgänge. Repo verwendet Manifestdateien, um Git-Projekte im Android-Superprojekt zusammenzuführen.
Manifestdatei: Eine Manifestdatei ist eine XML-Datei, in der angegeben ist, wo die verschiedenen Git-Projekte in der Android-Quelle in einem AOSP-Quellbaum abgelegt werden.

Hardwareanforderungen erfüllen

Ihre Entwicklungs-Workstation sollte die folgenden Hardwareanforderungen erfüllen oder übertreffen:

Ein 64-Bit-x86-System.

Hinweis :AOSP-Versionen vor 2.3.x können auf 32-Bit-Systemen kompiliert werden.
Mindestens 400 GB freier Speicherplatz zum Auschecken und Erstellen des Codes (250 GB zum Auschecken + 150 GB zum Erstellen).

Hinweis: Wenn Sie einen Mirror auschecken, benötigen Sie mehr Speicherplatz, da die vollständigen AOSP-Mirrors (Android Open Source Project) alle Git-Repositories enthalten, die jemals verwendet wurden.
Mindestens 64 GB RAM Google verwendet Maschinen mit 72 Kernen und 64 GB RAM, um Android zu entwickeln. Bei dieser Hardwarekonfiguration dauert ein vollständiger Android-Build etwa 40 Minuten und ein inkrementeller Android-Build nur wenige Minuten. Im Vergleich dazu dauert ein vollständiger Build mit einem 6‑Kern-Rechner mit 64 GB RAM etwa 6 Stunden.

Anforderungen an das Betriebssystem erfüllen

Auf Ihrer Entwicklungs-Workstation muss eine beliebige 64-Bit-Linux-Distribution mit GNU C Library (glibc) 2.17 oder höher ausgeführt werden.

Erforderliche Pakete installieren

Führen Sie den folgenden Befehl aus, um die erforderlichen Pakete für Ubuntu 18.04 oder höher zu installieren:

sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev libc6-dev-i386 x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig

Erforderliche Software installieren

Bevor Sie mit AOSP arbeiten können, müssen Sie OpenJDK, Make, Python 3 und Repo installiert haben. Der aktuelle Release-Branch von Android enthält vorkonfigurierte Versionen von OpenJDK, Make und Python 3. Daher sind keine zusätzlichen Installationsschritte erforderlich. Im folgenden Abschnitt wird beschrieben, wie Sie Repo installieren.

Repo installieren

So installierst du Repo:

Laden Sie die aktuellen Paketinformationen herunter:
```
sudo apt-get update
```
Führen Sie den folgenden Befehl aus, um den Repo-Launcher zu installieren:
```
sudo apt-get install repo
```
Der Repo-Launcher bietet ein Python-Script, das eine Überprüfung initialisiert und das vollständige Repo-Tool herunterlädt.

Wenn der Vorgang erfolgreich war, fahren Sie mit Schritt 4 fort.
Optional: Installieren Sie Repo manuell mit den folgenden Befehlen:
```
export REPO=$(mktemp /tmp/repo.XXXXXXXXX)
curl -o ${REPO} https://storage.googleapis.com/git-repo-downloads/repo
gpg --recv-keys 8BB9AD793E8E6153AF0F9A4416530D5E920F5C65
curl -s https://storage.googleapis.com/git-repo-downloads/repo.asc | gpg --verify - ${REPO} && install -m 755 ${REPO} ~/bin/repo
```
Mit den ersten drei Befehlen wird eine temporäre Datei eingerichtet, Repo in die Datei heruntergeladen und überprüft, ob der angegebene Schlüssel mit dem erforderlichen Schlüssel übereinstimmt. Wenn diese Befehle erfolgreich sind, wird mit dem letzten Befehl der Repo-Launcher installiert.
Prüfen Sie die Version des Repo-Launchers:
```
repo version
```
Die Ausgabe sollte eine Version von 2.4 oder höher anzeigen, z. B.:

repo launcher version 2.45

Android-Quellcode herunterladen

Die Android-Quelle befindet sich in einer Sammlung von Git-Repositories, die von Google gehostet werden. Jedes Git-Repository enthält den gesamten Verlauf der Android-Quelle, einschließlich Änderungen an der Quelle und dem Zeitpunkt, zu dem die Änderungen vorgenommen wurden. So laden Sie die Android-Quelle herunter:

Wechseln Sie zu Ihrem Basisverzeichnis:
```
cd ~
```
Erstellen Sie darin ein lokales Arbeitsunterverzeichnis:
```
mkdir aosp
```
Rufen Sie das Verzeichnis auf:
```
cd aosp
```

Initialisieren Sie den neuesten Release-Branch des AOSP-Repository-Quellcodes (android-latest-release):

repo init --partial-clone -b android-latest-release -u https://android.googlesource.com/platform/manifest

Geben Sie Ihre Git-Anmeldedaten (Name, E-Mail-Adresse) ein oder akzeptieren Sie sie.
Synchronisieren Sie den Quellcode:
```
repo sync -c -j8
```
Wenn beim Herunterladen Probleme auftreten, lesen Sie den Hilfeartikel Synchronisierungsprobleme beheben.

Code erstellen

So erstellen Sie den Code:

Rufen Sie im Arbeitsverzeichnis das envsetup.sh-Script auf, um die Buildumgebung einzurichten:
```
source build/envsetup.sh
```

Geben Sie mit dem Befehl lunch einen Ziel-Gerätetyp an, der erstellt werden soll. Ein Ziel ist eine Gerätevariante, z. B. ein bestimmtes Modell oder ein bestimmter Formfaktor. Geben Sie dieses Ziel an:

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
============================================

Erstellen Sie das Ziel:
```
m
```

Der erste Build kann mehrere Stunden dauern. Nachfolgende Builds dauern deutlich kürzer. Die Ausgabe des Builds wird in $OUT_DIR angezeigt.

Cuttlefish starten

Cuttlefish ist der Android-Emulator, mit dem Ihre Builds getestet werden.

Führen Sie die folgenden Befehle aus, um die Debian-Pakete für den Host herunterzuladen, zu erstellen und zu installieren:

sudo apt install -y git devscripts equivs config-package-dev debhelper-compat golang curl
git clone https://github.com/google/android-cuttlefish
cd android-cuttlefish
for dir in base frontend; do
pushd $dir
# Install build dependencies
sudo mk-build-deps -i
dpkg-buildpackage -uc -us
popd
done
sudo dpkg -i ./cuttlefish-base_*_*64.deb || sudo apt-get install -f
sudo dpkg -i ./cuttlefish-user_*_*64.deb || sudo apt-get install -f
sudo usermod -aG kvm,cvdnetwork,render $USER
sudo reboot

Durch den Neustart werden zusätzliche Kernelmodule installiert und udev-Regeln angewendet.

Cuttlefish starten:
```
launch_cvd --daemon
```
Stellen Sie eine Verbindung zum Cuttlefish-Gerät her, indem Sie in Ihrem Webbrowser https://localhost:8443 aufrufen. Ihr virtuelles Android-Gerät wird angezeigt.

Änderungen vornehmen

Aktualisieren Sie den Quellcode anhand dieser Änderungsliste.

Rufen Sie im Stammverzeichnis Ihrer Kopie (aosp/-Verzeichnis) das Git-Projekt frameworks/native auf:
```
cd frameworks/native
```
Starten Sie ein temporäres Projekt mit diesem Befehl:
```
repo start <some-name> .
```
Bearbeiten Sie SurfaceFlinger.cpp an folgendem Speicherort mit Ihrem Editor:
```
aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
```

Suchen Sie nach dieser Zeile:

void SurfaceFlinger::updateColorMatrixLocked() {

Fügen Sie diese Zeile am Anfang von updateColorMatrixLocked() hinzu:

mClientColorMatrix = mat4(vec4{1.0f, 0.0f, 0.0f, 0.0f}, vec4{0.0f, -1.0f, 0.0f, 0.0f},
                         vec4{0.0f, 0.0f, -1.0f, 0.0f}, vec4{0.0f, 1.0f, 1.0f, 1.0f});

Erstellen Sie den Code:
```
m
```

Aktualisieren Sie die Version auf dem Gerät:

adb root
adb remount -R
adb root
adb sync
adb reboot

Prüfen Sie, ob auf dem ausgewählten Gerät eine Farbänderung ähnlich wie in Abbildung 1 zu sehen ist.

Abbildung 1: Bildschirmdarstellung nach erfolgreicher Farbänderung

Test korrigieren

In diesem Teil des Codelabs wird ein Beispieltest verwendet, der sich im Stammverzeichnis befindet und fehlschlägt.

So führen Sie den Test aus, beheben Fehler und korrigieren ihn:

Führen Sie Folgendes aus:
```
atest DevCodelabTest
```
Der Test schlägt fehl.

Hinweis: atest ist ein Befehlszeilentool, mit dem Sie Android-Tests lokal erstellen, installieren und ausführen können.

Prüfen Sie den Stack-Trace des fehlgeschlagenen Tests:

STACKTRACE:
java.lang.AssertionError
 at org.junit.Assert.fail(Assert.java:87)
 at org.junit.Assert.assertTrue(Assert.java:42)
 at org.junit.Assert.assertTrue(Assert.java:53)
 at android.test.example.devcodelab.DevCodelabTest.testHelloWorld(DevCodelabTest.java:29)

Die letzte Zeile des Stack-Traces zeigt den Test an, der fehlschlägt (testHelloWorld). Dieser Test befindet sich in der Datei DevCodelabTest.java.

Um den Speicherort des zu korrigierenden Tests zu ermitteln, fügen Sie der letzten Zeile des Stack-Traces bis einschließlich des Namens der Testdatei WORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/ hinzu. Aus android.test.example.devcodelab.DevCodelabTest wird also WORKING_DIRECTORY/platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java.
Bearbeiten Sie platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java und ersetzen Sie Assert.assertTrue(false) durch Assert.assertTrue(true).
Führen Sie den Test noch einmal aus, um zu prüfen, ob das Problem behoben wurde:
```
atest DevCodelabTest
```

Code zur Überprüfung hochladen

Repo vereinfacht die Verwendung von Git, indem Befehle wie git clone gebündelt werden, um gleichzeitig in mehreren Git-Repositories (oder Projekten) zu arbeiten.

Verwenden Sie für die Codeüberprüfung Ihrer Projekte in Git das webbasierte Codeüberprüfungssystem Gerrit.

Angenommen, Sie haben Ihre Änderungen im Projekt frameworks/native vorgenommen, führen Sie die folgenden Befehle aus, um sie hochzuladen:
```
cd frameworks/native
repo start codelab .
git add .
git commit
```
Geben Sie als Commit-Nachricht Folgendes ein:
```
Android codelab change
Test: manual atest
```

Laden Sie die Änderung hoch:

repo upload

Wenn der Vorgang erfolgreich war, wird eine Meldung wie die folgende angezeigt:

Upload project frameworks/native/ to remote branch android15-qpr2-release:
 branch codelab ( 1 commit, Wed Aug 7 09:32:33 2019 -0700):
        ff46b36d android codelab change
to https://android-review.googlesource.com/ (y/N)? y
remote: Processing changes: refs: 1, new: 1, done
remote:
remote: SUCCESS
remote:
remote:   https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432 android codelab change [NEW]
remote:
To https://android-review.googlesource.com/platform/frameworks/native
* [new branch]          codelab -> refs/for/android15-qpr2-release

Änderung in Gerrit ansehen

Wenn Sie die Änderung in Gerrit sehen möchten, rufen Sie die Linkausgabe im Terminal auf. Der Link sieht in etwa so aus:

https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432

Änderung rückgängig machen

Normalerweise reichen Sie Ihre Änderung nach dem Testen, der Überprüfung und Genehmigung in Gerrit ein und führen sie in das Repository ein. Kehren Sie stattdessen für dieses Codelab zu Ihrer ursprünglichen Arbeit zurück:

Klicken Sie in Gerrit auf Verlassen.
Verwerfen Sie den zugehörigen temporären Branch im Projektverzeichnis frameworks/native (oder in seinen Unterverzeichnissen):
```
repo abandon codelab .
```
Setzen Sie die Änderungen an der Testdatei zurück. Da Sie repo start, git commit und repo upload nicht für die Teständerung ausgeführt haben, können Sie die Datei selbst zurücksetzen. Angenommen, Sie befinden sich im Verzeichnis aosp/platform_testing directory, verwenden Sie den folgenden Befehl, um die Datei zurückzusetzen:
```
git reset HEAD tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
git checkout .
```

Damit ist das Codelab zur Entwicklung für die Android-Plattform abgeschlossen.

Hilfe

Wenn während dieses Codelabs Fehler auftreten, melden Sie sie über den Link Issue Tracker unten auf jeder Seite. Senden Sie Fragen an die Gruppe android-building.

Geben Sie ps -A | grep crosvm ein, um zu prüfen, ob crosvm bereits ausgeführt wird. Wenn crossvm ausgeführt wird, geben Sie stop_cvd || true oder kill crosvm Prozess mit der Prozess-PID ein.