Befolgen Sie diese Anweisungen, um mit der Entwicklung von Android zu beginnen.
Einrichten der Umgebung
Initialisieren Sie die Umgebung mit dem Skript envsetup.sh
:
source build/envsetup.sh
oder
. build/envsetup.sh
Beschreibungen verwandter Befehle finden Sie im Skript unter platform/build/envsetup.sh , einschließlich Lunch zum Auswählen von Gerätezielen und Tapas zum Erstellen entbündelter Apps, wie z. B. der Referenz-TV-App .
Sie müssen diesen Befehl nach jeder repo sync
erneut ausführen, um alle Änderungen an diesem Skript zu übernehmen. Beachten Sie, dass das Ersetzen source
durch .
(ein einzelner Punkt) spart einige Zeichen und die Kurzform wird häufiger in der Dokumentation verwendet.
Das Skript envsetup.sh
importiert mehrere Befehle, die es Ihnen ermöglichen, mit dem Android-Quellcode zu arbeiten, einschließlich der in dieser Übung verwendeten Befehle.
Um die vollständige Liste der verfügbaren Befehle anzuzeigen, führen Sie Folgendes aus:
hmm
Ein Ziel auswählen
Mittagessen
Wählen Sie, welches Ziel Sie mit lunch
aufbauen möchten. lunch product_name - build_variant
wählt product_name als zu erstellendes Produkt und build_variant als zu erstellende Variante aus und speichert diese Auswahl in der Umgebung, damit sie von nachfolgenden Aufrufen von m
und anderen ähnlichen Befehlen gelesen werden kann.
Die genaue Konfiguration kann als Argument übergeben werden. Der folgende Befehl bezieht sich beispielsweise auf einen vollständigen Build für den Emulator, bei dem das gesamte Debugging aktiviert ist:
lunch aosp_arm-eng
Wenn es ohne Argumente ausgeführt wird, werden Sie lunch
aufgefordert, ein Ziel aus dem Menü auszuwählen. Beachten Sie jedoch, dass das Menü nicht alle Möglichkeiten enthält. Siehe „Auswählen eines Geräte-Builds“ für die Build-Konfigurationen aller in AOSP unterstützten Geräte oder sprechen Sie mit den Leuten in Ihrem Team über das richtige Mittagessen für das Gerät, an dem Sie arbeiten.
Alle Build-Ziele haben die Form BUILD-BUILDTYPE
, wobei BUILD
ein Codename ist, der sich auf die jeweilige Funktionskombination bezieht. BUILDTYPE
ist einer der folgenden.
Buildtyp | Verwenden |
---|---|
Benutzer | Beschränkter Zugang; für die Produktion geeignet |
Benutzerdebug | Wie Benutzer, aber mit Root-Zugriff und Debug-Fähigkeit; sehr nah an der Produktionsleistung |
eng | Entwicklungskonfiguration mit schnellerer Buildzeit; am besten für die tägliche Entwicklung geeignet |
Der userdebug
Build sollte sich genauso verhalten wie der user
Build, mit der Möglichkeit, zusätzliches Debugging zu ermöglichen, das normalerweise das Sicherheitsmodell der Plattform verletzt. Dadurch ist der userdebug
Build gut geeignet, um die von der Version verwendete Leistung und Leistung zu verstehen. Befolgen Sie beim Entwickeln mit dem userdebug
Build die Userdebug-Richtlinien .
Der eng
Build priorisiert die technische Produktivität für Ingenieure, die auf der Plattform arbeiten. Der eng
Build deaktiviert verschiedene Optimierungen, die zur Maximierung der Laufzeitleistung verwendet werden. Ansonsten ist der eng
Build den user
und userdebug
Builds sehr ähnlich, sodass Geräteentwickler sehen können, wie sich der Code in diesen Umgebungen verhält.
Um die aktuellen Mittagseinstellungen anzuzeigen, führen Sie den folgenden Befehl aus:
echo "$TARGET_PRODUCT-$TARGET_BUILD_VARIANT"
Weitere Informationen zum Erstellen und Ausführen auf tatsächlicher Hardware finden Sie unter Flashing Devices .
Tapas
Der Befehl tapas
konfiguriert den Build entbündelter Apps. Es wählt einzelne Apps aus, die vom Android-Build-System erstellt werden sollen. Im Gegensatz zum lunch
erfordert tapas
nicht die Erstellung von Bildern für ein Gerät.
Führen Sie tapas help
aus, um weitere Informationen zum Befehl zu erhalten.
Den Code erstellen
Dieser Abschnitt ist eine kurze Zusammenfassung, um sicherzustellen, dass die Einrichtung abgeschlossen ist.
Baue alles mit m
. m
kann parallele Aufgaben mit einem -jN
Argument verarbeiten. Wenn Sie kein -j
Argument angeben, wählt das Build-System automatisch eine Anzahl paralleler Aufgaben aus, die seiner Meinung nach für Ihr System optimal ist.
m
Wie oben erläutert, können Sie anstelle des vollständigen Geräte-Images bestimmte Module erstellen, indem Sie deren Namen in Ihrer m
Befehlszeile auflisten. Darüber hinaus stellt m
einige Pseudoziele für spezielle Zwecke bereit. Einige Beispiele sind:
-
droid
-m droid
ist der normale Build. Dieses Ziel ist hier, weil das Standardziel einen Namen erfordert. -
all
–m all
erstellt alles, wasm droid
macht, plus alles, was nicht über dasdroid
Tag verfügt. Der Build-Server führt dies aus, um sicherzustellen, dass alles, was sich in der Baumstruktur befindet und über eineAndroid.mk
Datei verfügt, erstellt wird. -
m
– Führt Builds von der Spitze des Baums aus aus. Dies ist nützlich, da Siemake
aus Unterverzeichnissen ausführen können. Wenn Sie die UmgebungsvariableTOP
festgelegt haben, wird diese verwendet. Wenn Sie dies nicht tun, sucht es im aktuellen Verzeichnis nach dem Baum und versucht, die Spitze des Baums zu finden. Sie können entweder den gesamten Quellcodebaum erstellen, indem Siem
ohne Argumente ausführen, oder bestimmte Ziele erstellen, indem Sie deren Namen angeben. -
mma
– Erstellt alle Module im aktuellen Verzeichnis und ihre Abhängigkeiten. -
mmma
– Erstellt alle Module in den bereitgestellten Verzeichnissen und ihre Abhängigkeiten. -
croot
–cd
an die Spitze des Baums. -
clean
–m clean
löscht alle Ausgabe- und Zwischendateien für diese Konfiguration. Dies ist dasselbe wierm -rf out/
.
Führen Sie m help
aus, um zu sehen, welche anderen Pseudoziele m
bereitstellt.
Ausführen des Builds
Sie können Ihren Build entweder auf einem Emulator ausführen oder auf einem Gerät flashen. Da Sie Ihr Build-Ziel bereits mit lunch
ausgewählt haben, ist es unwahrscheinlich, dass es auf einem anderen Ziel ausgeführt wird, als es erstellt wurde.
Flashen mit Fastboot
Um ein Gerät zu flashen, verwenden Sie fastboot
, das nach einem erfolgreichen Build in Ihrem Pfad enthalten sein sollte. Anweisungen finden Sie unter Flashen eines Geräts .
Emulieren eines Android-Geräts
Der Emulator wird durch den Build-Prozess automatisch zu Ihrem Pfad hinzugefügt. Geben Sie Folgendes ein, um den Emulator auszuführen:
emulator
Build-Fingerabdrücke verstehen
Um Probleme im Zusammenhang mit einem bestimmten Android-Build zu verfolgen und zu melden, ist es wichtig, den Build-Fingerabdruck zu verstehen. Der Build-Fingerabdruck ist eine eindeutige, für Menschen lesbare Zeichenfolge, die Herstellerinformationen enthält, die für jeden Build ausgegeben werden. Die genaue Syntax finden Sie in der FINGERPRINT- Beschreibung im Abschnitt „Build-Parameter“ des Android Compatibility Definition Document (CDD).
Der Build-Fingerabdruck stellt eine bestimmte Android-Implementierung und -Revision dar. Mit diesem eindeutigen Schlüssel können App-Entwickler und andere Probleme mit bestimmten Firmware-Versionen melden. Informationen zum Meldevorgang für Android-Probleme finden Sie unter Fehler melden .
Ein Build-Fingerabdruck fasst alle Android-Implementierungsdetails zusammen:
- APIs: Android und native sowie weiche API-Verhaltensweisen
- Kern-API und einige Verhaltensweisen der System-Benutzeroberfläche
- In der CDD definierte Kompatibilitäts- und Sicherheitsanforderungen
- Produktspezifikationen und die Verwendungsfunktionseinstellung, die von Apps verwendet wird, um Geräte anzusprechen, die die erwarteten Anforderungen erfüllen
- Implementierungen von Hardware- und Softwarekomponenten
Ausführliche Informationen finden Sie im CDD. Anweisungen zum Erstellen eines völlig neuen Android-Geräts finden Sie unter „Hinzufügen eines neuen Geräts“.
Behebung häufiger Build-Fehler
Falsche Java-Version
Wenn Sie versuchen, eine Android-Version zu erstellen, die nicht mit Ihrer Java-Version übereinstimmt, brechen make
den Vorgang mit einer Meldung wie der folgenden ab:
************************************************************ You are attempting to build with the incorrect version of java. Your version is: WRONG_VERSION. The correct version is: RIGHT_VERSION. Please follow the machine setup instructions at https://source.android.com/source/initializing.html ************************************************************
Hier sind die wahrscheinlichen Ursachen und Lösungen:
- Es konnte nicht das richtige JDK installiert werden, wie in den JDK-Anforderungen angegeben. Stellen Sie sicher, dass Sie die Schritte unter Einrichten der Umgebung und Auswählen eines Ziels befolgt haben.
- Ein anderes zuvor installiertes JDK erscheint in Ihrem Pfad. Stellen Sie das richtige JDK am Anfang Ihres Pfads voran oder entfernen Sie das problematische JDK.
Keine USB-Berechtigung
Auf den meisten Linux-Systemen haben unprivilegierte Benutzer standardmäßig keinen Zugriff auf USB-Anschlüsse. Wenn die Fehlermeldung „Berechtigung verweigert“ angezeigt wird, befolgen Sie die Anweisungen unter „Konfigurieren des USB-Zugriffs“ .
Wenn ADB bereits ausgeführt wurde und nach der Einrichtung dieser Regeln keine Verbindung zum Gerät hergestellt werden kann, können Sie es mit adb kill-server
beenden. Dieser Befehl bewirkt, dass ADB mit der neuen Konfiguration neu gestartet wird.