Sie können dabei helfen, das am weitesten verbreitete Betriebssystem in der Geschichte der Erde zu entwickeln. Ja, Sie sind hier, um sich auf den Weg zum Android-Plattform-Ingenieur zu machen.
Obwohl der Weg herausfordernd ist, ist das Android-Team bestrebt, Ihre Reise bei jeder Veröffentlichung zu vereinfachen. Und das Team verbessert sich jeden Tag durch die 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
Die Mission dieses Codelabs ist zweifach:
- Um Ihnen einen kleinen Vorgeschmack darauf zu geben, wie der Entwickler-Workflow für Android-Ingenieure aussieht, die an der Plattform (dem Betriebssystem) arbeiten.
- Ermutigen Sie Sie, Feedback zu den Tools, der Dokumentation und dem Entwickler-Workflow von Android zu geben.
Voraussetzungen
Die Liste der Anforderungen für dieses Codelab leitet sich von denen für die allgemeine Plattformentwicklung ( AOSP ) ab. Um dieses Codelab zu verwenden, richten Sie Folgendes ein:
- Physische Linux-Workstation, die alle öffentlichen Anforderungen erfüllt.
- Repo und die Git-Konfiguration, die zum Bearbeiten der Android-Codebasis erforderlich sind.
Umfeld
Normalerweise erstellen und entwickeln Benutzer direkt auf der Workstation. Da Sie möglicherweise in verschiedenen Terminals arbeiten und viele der verwendeten Befehle terminalspezifisch sind, müssen Sie sie in jeder Terminalsitzung erneut ausführen. Dazu gehören insbesondere die Befehle source build/envsetup.sh
und lunch
.
Arbeitsplatz einrichten
- Installieren Sie die erforderlichen Pakete auf Ihrer Workstation.
- Installieren Sie Repo, während Sie sich noch in einem Terminal befinden, und erhalten Sie Anmeldeinformationen für alle Git-Repositorys.
Initialisieren und synchronisieren Sie den Code
Navigieren Sie in Ihr Home-Verzeichnis:
cd ~
Erstellen Sie darin ein lokales Arbeitsunterverzeichnis:
mkdir aosp
Navigieren Sie in das Verzeichnis:
cd aosp
Initialisieren Sie den Hauptzweig des AOSP-Repository-Quellcodes (Standard):
repo init -u https://android.googlesource.com/platform/manifest
Geben Sie Ihre Git-Anmeldeinformationen (Name, E-Mail-Adresse) ein oder akzeptieren Sie sie.
Synchronisieren Sie den Quellcode:
repo sync -j8
Die ersten Synchronisierungen können eine Stunde oder länger dauern.
Jeder Repo-Checkout wird durch eine Manifestdatei dargestellt. Es ist zulässig, mehr als einen Repo-Checkout gleichzeitig durchzuführen, solange diese in unterschiedlichen Verzeichnissen vorhanden sind. Beachten Sie jedoch, dass jedes Auschecken und Erstellen etwa 300 GB verbraucht (Tendenz steigend). Beschränken Sie sich also entweder auf zwei Repo-Auschecken oder erweitern Sie Ihr System mit einem sekundären Laufwerk.
Erstellen Sie den Code
Um Android zu erstellen, müssen Sie mit dem lunch
Befehl einen Zielgerätetyp zum Erstellen auswählen. Ein Ziel ist eine Gerätepermutation, beispielsweise ein bestimmtes Modell oder ein bestimmter Formfaktor.
Mit dem Geräteziel aosp_cf_x86_64_phone-userdebug
können Sie das virtuelle Android-Gerät Cuttlefish zum Testen ohne physisches Gerät erstellen.
Um stattdessen ein physisches Gerät zu erstellen und zu aktualisieren, wählen Sie ein anderes Ziel und befolgen Sie die Anweisungen zum Flashen von Geräten .
Richten Sie Ihre Umgebung zum Erstellen von Android-Geräten ein, indem Sie den folgenden Befehl im Stammverzeichnis Ihres Quellcode-Checkouts 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 von überall in Ihrem Checkout mit:
m
Rechnen Sie damit, dass der erste Build Stunden dauern wird. Nachfolgende Builds nehmen deutlich weniger Zeit in Anspruch.
Starten Sie Tintenfisch
Cuttlefish ist der Android-Emulator, der zum Testen Ihrer Builds verwendet wird.
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 Host-Debian-Pakete 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.Tintenfisch starten:
launch_cvd --daemon</code>
Stellen Sie eine Verbindung zum Cuttlefish-Gerät her, indem Sie in Ihrem Webbrowser zu
https://localhost:8443
navigieren. Sie werden mit einem Videostream des gerade erstellten Android-Geräts begrüßt.
Nehmen Sie eine Änderung vor
Aktualisieren Sie den Quellcode gemäß dieser Beispiel- Änderungsliste .
Navigieren Sie im Stammverzeichnis Ihres Checkouts (
aosp/
-Verzeichnis) zumframeworks/native
Git-Projekt:cd frameworks/native
Starten Sie ein temporäres Projekt mit diesem Befehl:
repo start <some-name> .
Bearbeiten Sie
SurfaceFlinger.cpp
um die Aktualisierungen aus der Änderungsliste am folgenden Speicherort einzuschließen:aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
Finden Sie diese Zeile:
postComposition();
Ersetzen Sie diese beiden Zeilen durch Folgendes:
postComposition(); 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}); updateColorMatrixLocked();
Erstellen Sie den Code:
m
Aktualisieren Sie den Build auf dem Gerät:
adb root
adb remount
adb sync
adb reboot
Stellen Sie sicher, dass Sie auf Ihrem ausgewählten Gerät eine Farbänderung sehen, die der in Abbildung 1 ähnelt.
Abbildung 1. Bildschirmdarstellung nach erfolgreichem Farbwechsel
Testen Sie Ihren Code
Dieser Teil des Codelabs verwendet einen Beispieltest, der sich im Quellbaum befindet und fehlschlägt. Dabei wird Atest verwendet, um den Test lokal auszuführen und den Code zu testen.
Um den Test zu verwenden, befolgen Sie diese Anweisungen:
Laufen:
atest DevCodelabTest
Der Test wird fehlschlagen. Um das Problem zu beheben, suchen Sie den Quellcode des fehlgeschlagenen Tests:
atest --info android.test.example.devcodelab.DevCodelabTest#testHelloWorld
Dann schauen Sie hier
platform_testing/tests/example/devcodelab
Um die zu bearbeitende Datei zu erhalten, nehmen Sie den Namen des Tests in
android.test.example.devcodelab.DevCodelabTest
und ersetzen Sie ihn durch.
mit/
, um dieses Ergebnis zu erhalten:src/android/test/example/devcodelab/DevCodelabTest.java
Dann bearbeiten
platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
ersetzen
Assert.assertTrue(false)
mit
Assert.assertTrue(true)
Führen Sie den Test erneut aus, um zu überprüfen, ob Sie das Problem behoben haben:
atest DevCodelabTest
Laden Sie Ihren Code zur Überprüfung hoch
Repo vereinfacht die Git-Nutzung, indem es Befehle wie git clone
bündelt, um in mehreren Git-Repositorys (oder Projekten) gleichzeitig zu arbeiten.
Unter Source Control Tools finden Sie einen Überblick über Git und Repo sowie Links zur vollständigen Dokumentation zum Arbeiten mit Android-Quellcode. Im AOSP-Repository finden Sie die vollständige Liste der Git-Projekte und die einzelnen Projekte (Pfade) für die mit jedem Projekt verknüpften Zweige.
Für die Codeüberprüfung Ihrer Projekte in Git verwenden Sie das webbasierte Codeüberprüfungssystem Gerrit .
Vorausgesetzt, Sie haben Ihre Änderungen im
frameworks/native
Projekt vorgenommen, führen Sie diese Befehle aus, um sie hochzuladen:cd frameworks/native
repo start codelab .
git add .
git commit
Geben Sie für Ihre Commit-Nachricht Folgendes ein:
Android codelab change Test: manual atest
Laden Sie Ihre Änderung hoch:
repo upload
Wenn Sie erfolgreich sind, wird eine Meldung ähnlich dieser angezeigt:
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
Sehen Sie sich Ihre Veränderung in Gerrit an
Gehen Sie zu dem im Terminal gedruckten Link, der diesem ähnelt:
https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432
Damit ist das Starter-Codelab für die Android-Plattformentwicklung abgeschlossen. Die nächsten Schritte finden Sie unter „Einreichen von Patches“ . Ausführliche Informationen zur Entwicklung von Android finden Sie im Rest dieser Website.
Machen Sie Ihre Änderung rückgängig
Normalerweise reichen Sie Ihre Änderung nach dem Test und nach Prüfung und Genehmigung in Gerrit ein und führen sie in das Repository ein.
Setzen Sie stattdessen für die Zwecke dieses Codelabs Ihre Änderungsliste zurück, indem Sie in Gerrit auf „Abbrechen“ klicken.
Verlassen Sie dann den zugehörigen temporären Zweig im Verzeichnis frameworks/native
project“ (oder seinen Unterverzeichnissen):
repo abandon codelab .
Denken Sie auch daran, die an der Testdatei vorgenommenen Änderungen rückgängig zu machen. Da Sie die Änderung nicht repo start
, git commit
und repo upload
, können Sie die Datei selbst zurücksetzen. Angenommen, Sie befinden sich im aosp/platform_testing directory
, verwenden Sie Folgendes, um die Datei zurückzusetzen:
git reset HEAD tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
git checkout .
An diesem Punkt sind Sie fertig! Gute Arbeit!
Hilfe bekommen
Wenn Sie während dieses Codelabs auf Fehler stoßen, melden Sie diese über den Link „Issue Tracker“ unten auf jeder Seite. Senden Sie Fragen an die Android-Building- Gruppe.