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 Entwicklung allgemeiner Plattformen ( 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 unten enthaltenen 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-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.
Erstellen Sie eine Acloud-Instanz
Acloud ist ein Befehlszeilentool in AOSP, das Benutzer beim Erstellen virtueller Android-Geräte, in diesem Fall Cuttlefish, unterstützt.
Wenn Sie sich in derselben Terminalsitzung befinden, die zum Erstellen des Codes verwendet wurde, fahren Sie fort. Andernfalls führen Sie das Skript envsetup.sh
und denselben lunch
Befehl erneut aus, den Sie dort zuerst verwendet haben. Dann
Installieren Sie die Abhängigkeiten für die lokale Ausführung eines virtuellen Cuttlefish-Geräts mit:
acloud setup
Wenn Sie dazu aufgefordert werden, starten Sie Ihre Workstation neu, damit alle Änderungen wirksam werden.
Erstellen Sie eine lokale
acloud
Instanz mit:acloud create --local-image --local-instance
Wählen Sie das Cuttlefish-Gerät aus.
Sie sollten mit einer VNC-Sitzung mit einem Android-Gerät begrüßt werden!
Sie können mit Ihrer Maus und Tastatur mit dem virtuellen Gerät auf Ihrer Workstation interagieren. Sie können die Aktivität in den Protokollen auch verfolgen, während Sie Ihr Gerät verwenden, indem Sie den logcat
Befehl Android Debug Bridge (adb) verwenden:
adb logcat
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
acloud reconnect
Wenn Sie aufgefordert werden, ein Gerät auszuwählen, wählen Sie das Gerät aus, das die kürzeste verstrichene Zeit anzeigt. (Dies ist wahrscheinlich die letzte in der Liste, die Sie sehen.) Um alle virtuellen Geräteinstanzen anzuzeigen, verwenden Sie die Befehle
acloud list
undacloud list -v
.
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 Befehle wie git clone
gebündelt werden, um in zahlreichen 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 übermitteln Sie Ihre Änderung nach dem Test und nach Überprüfung und Genehmigung in Gerrit und führen sie in das Repository ein.
Stattdessen setzen Sie 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
haben, 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 bitte über den Issue Tracker- Link unten auf jeder Seite. Senden Sie Fragen an die Android-Building -Gruppe.