Sie können dazu beitragen, das Betriebssystem zu entwickeln, das in der Geschichte der Erde am weitesten verbreitet ist. Ja, du bist hier, um dich auf den Weg zum Android-Plattformentwickler zu machen.
Auch wenn der Weg schwierig ist, ist das Android-Team bestrebt, Ihre Reise bei jedem Release zu vereinfachen. Und das Team verbessert jeden Tag durch direkte Arbeit im Android Open Source Project (AOSP).
Lehnen Sie sich also zurück, starten Sie ein Terminal und lassen Sie uns Geschichte schreiben.
Ziele
Dieses Codelab verfolgt zwei Ziele:
- Damit du einen kleinen Vorgeschmack darauf erhältst, wie der Entwicklerworkflow für Android-Entwickler aussieht, die an der Plattform (dem Betriebssystem) arbeiten.
- Wir empfehlen dir, uns Feedback zu den Tools, der Dokumentation und dem Entwicklerworkflow von Android zu geben.
Voraussetzungen
Die Liste der Anforderungen für dieses Codelab wurde von den Anforderungen für die allgemeine Plattformentwicklung (AOSP) abgeleitet. Für dieses Codelab müssen Sie Folgendes einrichten:
- Physische Linux-Workstation, die alle öffentlichen Anforderungen erfüllt.
- Repository und die Git-Konfiguration, die zum Bearbeiten der Android-Codebasis erforderlich sind.
Umgebung
In der Regel erfolgt die Erstellung und Entwicklung direkt auf der Workstation. Da Sie möglicherweise in verschiedenen Terminals arbeiten und viele der verwendeten Befehle Terminal-spezifisch sind, müssen Sie sie in jeder Terminalsitzung neu ausführen. Dazu gehören insbesondere die Befehle source build/envsetup.sh
und lunch
.
Workstation einrichten
- Installieren Sie die erforderlichen Pakete auf Ihrer Workstation.
- Installieren Sie das Repository und rufen Sie Anmeldedaten für alle Git-Repositories ab, während Sie sich noch in einem Terminal befinden.
Code initialisieren und synchronisieren
Wechseln Sie zu Ihrem Basisverzeichnis:
cd ~
Erstellen Sie darin ein lokales Arbeitsunterverzeichnis:
mkdir aosp
Wechseln Sie in das Verzeichnis:
cd aosp
Initialisieren Sie den Hauptzweig des AOSP-Repositorys (Standardeinstellung):
repo init -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 -j8
Die erste Synchronisierung kann eine Stunde oder länger dauern.
Jeder Repository-Bezahlvorgang wird durch eine Manifestdatei dargestellt. Es ist zulässig, mehrere Repository-Checkout-Vorgänge gleichzeitig zu haben, sofern diese in unterschiedlichen Verzeichnissen vorhanden sind. Beachten Sie jedoch, dass jeder Checkout- und Build-Vorgang eine Nutzung von etwa 300 GB ausmacht (Tendenz steigend). Sie können sich also entweder auf 2 Repository-Bezahlvorgänge beschränken oder Ihr System mit einem sekundären Laufwerk erweitern.
Code erstellen
Wenn Sie Android erstellen möchten, müssen Sie einen Zielgerätetyp für die Erstellung mit dem Befehl lunch
auswählen. Ein Ziel ist eine Gerätepermutation, z. B. ein bestimmtes Modell oder einen Formfaktor.
Mit dem Geräteziel aosp_cf_x86_64_phone-userdebug
können Sie das virtuelle Android-Gerät Cuttlefish für Tests ohne physisches Gerät erstellen.
Wenn Sie stattdessen ein physisches Gerät erstellen und aktualisieren möchten, wählen Sie ein anderes Ziel aus und folgen Sie der Anleitung unter Flash-Geräte.
Richten Sie Ihre Umgebung für das Erstellen von Android-Geräten ein, indem Sie den folgenden Befehl im Stammverzeichnis des Quellcodes ausführen:
source build/envsetup.sh
Übergeben Sie das Build-Ziel wie folgt an den Lunch-Befehl:
lunch aosp_cf_x86_64_phone-trunk_staging-userdebug
Erstellen Sie den Code an einer beliebigen Stelle an Ihrem Bezahlvorgang:
m
Der erste Build wird voraussichtlich Stunden dauern. Nachfolgende Builds nehmen erheblich weniger Zeit in Anspruch.
Sepien werfen
Cuttlefish ist der Android-Emulator zum Testen Ihrer Builds.
Wenn Sie Cuttlefish noch nie installiert haben, müssen Sie die erforderlichen Cuttlefish-Abhängigkeiten installieren. Führen Sie in einem Terminalfenster die folgenden Befehle aus, um die Debian-Hostpakete 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
Der Neustart löst die Installation zusätzlicher Kernelmodule aus und wendet
udev
-Regeln an.Sepien starten:
launch_cvd --daemon
Stellen Sie eine Verbindung zum Cuttlefish-Gerät her. Rufen Sie dazu
https://localhost:8443
in Ihrem Webbrowser auf. Sie werden mit einem Videostream des gerade entwickelten Android-Geräts begrüßt.
Änderungen vornehmen
Aktualisieren Sie den Quellcode gemäß dieser Beispieländerungsliste.
Gehen Sie im Stammverzeichnis des Checkouts (Verzeichnis
aosp/
) zum Git-Projektframeworks/native
:cd frameworks/native
Starten Sie mit diesem Befehl ein temporäres Projekt:
repo start <some-name> .
Bearbeiten Sie
SurfaceFlinger.cpp
, um die Aktualisierungen aus der Änderungsliste an folgendem Speicherort aufzunehmen:aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
Suchen Sie nach dieser Zeile:
void SurfaceFlinger::updateColorMatrixLocked() {
Fügen Sie diese beiden Zeilen 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 den Build auf dem Gerät:
adb root
adb remount
adb sync
adb reboot
Prüfen Sie, ob auf dem ausgewählten Gerät eine Farbänderung wie in Abbildung 1 zu sehen ist.
Abbildung 1: Bildschirmdarstellung nach erfolgreicher Farbänderung
Code testen
In diesem Teil des Codelabs wird ein Beispieltest verwendet, der sich in der Quellstruktur befindet und fehlschlägt. Dabei wird Atest verwendet, um den Test lokal auszuführen und den Code zu testen.
So verwenden Sie den Test:
Führen Sie Folgendes aus:
atest DevCodelabTest
Der Test schlägt fehl. Um das Problem zu beheben, suchen Sie den Quellcode des fehlgeschlagenen Tests:
atest --info android.test.example.devcodelab.DevCodelabTest#testHelloWorld
Dann sieh hier nach
platform_testing/tests/example/devcodelab
Geben Sie zum Abrufen der zu bearbeitenden Datei den Namen des Tests in
android.test.example.devcodelab.DevCodelabTest
ein und ersetzen Sie.
durch/
, um dieses Ergebnis zu erhalten:src/android/test/example/devcodelab/DevCodelabTest.java
Bearbeiten
platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
zum Ersetzen
Assert.assertTrue(false)
mit
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 Nutzung von Git, indem Befehle wie git clone
so gebündelt werden, dass sie in zahlreichen Git-Repositories (oder Projekten) gleichzeitig funktionieren.
Unter Source Control Tools finden Sie einen Überblick über Git und Repository mit Links zur vollständigen Dokumentation zum Arbeiten mit Android-Quellcode. Die vollständige Liste der Git-Projekte und der einzelnen Projekte (Pfade) für die mit jedem Projekt verknüpften Zweige finden Sie im AOSP-Repository.
Für die Codeüberprüfung Ihrer Projekte in Git verwenden Sie das webbasierte Codeüberprüfungssystem Gerrit.
Wenn Sie im Projekt
frameworks/native
Änderungen vorgenommen haben, führen Sie die folgenden Befehle aus, um sie hochzuladen:cd frameworks/native
repo start codelab .
git add .
git commit
Geben Sie für die Commit-Nachricht Folgendes ein:
Android codelab change Test: manual atest
Laden Sie die Änderung hoch:
repo upload
Ist dies erfolgreich, sehen Sie eine Nachricht wie diese:
Upload project frameworks/native/ to remote branch main:
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/main
Deine Änderung in Gerrit ansehen
Rufen Sie den im Terminal angezeigten Link auf, der in etwa so aussieht:
https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432
Damit ist das Start-Codelab für die Android-Plattformentwicklung abgeschlossen. Weitere Informationen finden Sie unter Patches senden. Ausführliche Informationen zur Entwicklung von Android finden Sie auf dieser Website.
Änderung rückgängig machen
Normalerweise reichen Sie nach dem Testen sowie nach Überprüfung und Genehmigung Ihre Änderung in Gerrit ein und führen sie mit dem Repository zusammen.
Setzen Sie Ihre Änderungsliste in diesem Codelab stattdessen zurück, indem Sie in Gerrit auf Abandon (Verwerfen) klicken.
Verwerfen Sie dann den zugehörigen temporären Zweig im Projektverzeichnis frameworks/native
(oder seinen Unterverzeichnissen):
repo abandon codelab .
Vergessen Sie nicht, die Änderungen, die Sie an der Testdatei vorgenommen haben, rückgängig zu machen. Da Sie die Änderung nicht mit repo start
, git commit
und repo upload
ausgeführt haben, können Sie die Datei selbst zurücksetzen. Wenn Sie sich im aosp/platform_testing directory
befinden, können Sie die Datei so zurücksetzen:
git reset HEAD tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
git checkout .
Damit sind Sie fertig. Gut gemacht!
Hilfe aufrufen
Wenn in diesem Codelab Fehler auftreten, können Sie diese über den Link Problemverfolgung melden, der sich unten auf jeder Seite befindet. Senden Sie Fragen an die Gruppe android-building.