Sie können helfen, das am weitesten verbreitete Betriebssystem in der Geschichte der Erde zu entwickeln. Ja, Sie sind hier, um sich auf den Weg zu machen, ein Entwickler für Android-Plattformen zu werden.
Obwohl der Weg herausfordernd ist, ist das Android-Team bestrebt, Ihre Reise mit jeder Veröffentlichung zu vereinfachen. Und das Team verbessert sich jeden Tag durch die direkte Arbeit im Android Open Source Project (AOSP).
Also lehnen Sie sich 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 wurde von denen für die Entwicklung allgemeiner Plattformen ( AOSP ) abgeleitet. Um dieses Codelab zu nehmen, 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
Typischerweise bauen 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.
- Während Sie sich noch in einem Terminal befinden, installieren Sie Repo und erhalten Sie Anmeldeinformationen für alle Git-Repositories.
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 anfängliche Synchronisierung kann eine Stunde oder länger dauern.
Jeder Repo-Checkout wird durch eine Manifestdatei dargestellt. Es ist zulässig, mehr als 1 Repo-Checkout gleichzeitig zu haben, solange sie in unterschiedlichen Verzeichnissen vorhanden sind. Beachten Sie jedoch, dass jeder Checkout und Build ungefähr 300 GB Nutzung ausmacht (und wächst), also beschränken Sie sich entweder auf 2 Repo-Checkouts oder erweitern Sie Ihr System mit einem sekundären Laufwerk.
Erstellen Sie den Code
Um Android zu erstellen, müssen Sie einen Zielgerätetyp auswählen, der mit dem lunch
-Befehl erstellt werden soll. Ein Ziel ist eine Gerätepermutation, z. B. ein bestimmtes Modell oder Formfaktor.
Das unten enthaltene Geräteziel aosp_cf_x86_64_phone-userdebug
ermöglicht es Ihnen, das virtuelle Android-Gerät Cuttlefish zum Testen ohne ein physisches Gerät zu erstellen.
Um stattdessen ein physisches Gerät zu erstellen und zu aktualisieren, wählen Sie ein anderes Ziel aus 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
Erwarten Sie, dass der erste Build Stunden dauert. 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. Führen Sie andernfalls das envsetup.sh
Skript und denselben lunch
Befehl, den Sie dort zuerst verwendet haben, erneut aus. Dann
Erstellen Sie eine lokale Acloud-Instanz mit:
acloud create --local-image --local-instance
Akzeptieren Sie Updates für erforderliche Pakete.
Wenn Sie dazu aufgefordert werden, starten Sie Ihre Workstation neu, damit alle Änderungen wirksam werden.
Wählen Sie das Cuttlefish-Gerät aus.
Sie sollten mit einer VNC-Sitzung begrüßt werden, die ein Android-Gerät enthält!
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
Finde 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 mit der kürzesten verstrichenen Zeit. (Dies ist wahrscheinlich die letzte in der Liste, die Sie sehen.) Um alle Instanzen virtueller Geräte anzuzeigen, verwenden Sie die Befehle
acloud list
undacloud list -v
.
Vergewissern Sie sich, dass auf Ihrem ausgewählten Gerät eine Farbänderung ähnlich der in Abbildung 1 zu sehen ist.
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. Dies verwendet Atest , um den Test lokal auszuführen und den Code zu testen.
Befolgen Sie diese Anweisungen, um den Test zu verwenden:
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 Datei zu bearbeiten, nehmen Sie den Namen des Tests in
android.test.example.devcodelab.DevCodelabTest
und ersetzen Sie die.
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 mehreren Git-Repositories (oder Projekten) gleichzeitig zu funktionieren.
Siehe Source Control Tools für Übersichten über Git und Repo, mit 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 Branches, die jedem Projekt zugeordnet sind.
Für die Codeüberprüfung Ihrer Projekte in Git verwenden Sie das webbasierte Codeüberprüfungssystem von Gerrit .
Angenommen, 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, sehen Sie eine Nachricht ähnlich dieser:
Upload project frameworks/native/ to remote branch master:
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/master
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 Entwicklung der Android-Plattform abgeschlossen. Die nächsten Schritte finden Sie unter Einreichen von Patches . Vollständige Details zur Entwicklung von Android finden Sie auf dem Rest dieser Website.
Machen Sie Ihre Änderung rückgängig
Normalerweise übermitteln Sie nach dem Testen und nach Überprüfung und Genehmigung Ihre Änderung in Gerrit 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 Abandon klicken.
Verlassen Sie dann den zugehörigen temporären Zweig im Verzeichnis frameworks/native
project (oder dessen Unterverzeichnissen):
repo abandon codelab .
Denken Sie auch daran, die Änderungen rückgängig zu machen, die Sie an der Testdatei vorgenommen haben. 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.