Befolgen Sie diese Anweisungen, um mit der Entwicklung von Android zu beginnen.
Umgebung einrichten
Initialisieren Sie die Umgebung mit dem Skript envsetup.sh
:
source build/envsetup.sh
oder
. build/envsetup.sh
Im Skript unter platform/build/envsetup.sh finden Sie Beschreibungen verwandter Befehle, einschließlich Mittagessen zum Auswählen von Gerätezielen und Tapas zum Erstellen von entbündelten Apps, wie z. B. der Referenz-TV-App .
Sie müssen diesen Befehl nach jeder repo sync
erneut ausgeben, um Ä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, mit denen Sie mit dem Android-Quellcode arbeiten können, einschließlich der in dieser Übung verwendeten Befehle.
Führen Sie Folgendes aus, um die vollständige Liste der verfügbaren Befehle anzuzeigen:
hmm
Auswahl eines Ziels
Mittagessen
Wählen Sie aus, welches Ziel Sie mit lunch
aufbauen möchten. lunch product_name - build_variant
wählt product_name als das zu erstellende Produkt und build_variant als die zu erstellende Variante aus und speichert diese Auswahlen in der Umgebung, damit sie von nachfolgenden Aufrufen von m
und anderen ähnlichen Befehlen gelesen werden können.
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, fordert lunch
Sie auf, ein Ziel aus dem Menü auszuwählen, aber beachten Sie, 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 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 bestimmte Feature-Kombination bezieht. BUILDTYPE
ist einer der folgenden.
Bauart | Verwenden |
---|---|
Benutzer | Beschränkter Zugang; für die Produktion geeignet |
Benutzerdebug | Wie Benutzer, aber mit Root-Zugriff und Debug-Fähigkeit; bevorzugt zum Debuggen |
eng | Entwicklungskonfiguration mit zusätzlichen Debugging-Tools |
Der userdebug
Build sollte sich genauso verhalten wie der user
Build, mit der Möglichkeit, zusätzliches Debugging zu aktivieren, das normalerweise gegen das Sicherheitsmodell der Plattform verstößt. Dadurch eignet sich der userdebug
Build gut für Benutzertests mit größeren Diagnosemöglichkeiten. Befolgen Sie beim Entwickeln mit dem userdebug
Build die Userdebug-Richtlinien .
Der eng
Build priorisiert die Engineering-Produktivität für Ingenieure, die auf der Plattform arbeiten. Der eng
Build deaktiviert verschiedene Optimierungen, die verwendet werden, um eine gute Benutzererfahrung zu bieten. Ansonsten verhält sich der eng
Build ähnlich wie die user
und userdebug
Builds, sodass Geräteentwickler sehen können, wie sich der Code in diesen Umgebungen verhält.
Führen Sie den folgenden Befehl aus, um die aktuellen Mittagseinstellungen anzuzeigen:
echo "$TARGET_PRODUCT-$TARGET_BUILD_VARIANT"
Weitere Informationen zum Erstellen und Ausführen auf tatsächlicher Hardware finden Sie unter Flashen von Geräten .
Tapas
Der tapas
Befehl konfiguriert den Build von entbündelten Apps. Es wählt einzelne Apps aus, die vom Android-Build-System erstellt werden sollen. Im Gegensatz zum lunch
erfordert tapas
nicht das Erstellen von Bildern für ein Gerät.
Führen Sie tapas help
aus, um weitere Informationen zum Befehl zu erhalten.
Erstellen des Codes
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 Tasks aus, die es für Ihr System für optimal hält.
m
Wie oben erläutert, können Sie anstelle des vollständigen Geräte-Images spezifische Module erstellen, indem Sie ihre Namen in Ihrer m
Befehlszeile auflisten. Darüber hinaus bietet m
einige Pseudoziele für spezielle Zwecke. Einige Beispiele sind:
-
droid
-m droid
ist der normale Build. Dieses Ziel ist hier, weil das Standardziel einen Namen erfordert. -
all
-m all
baut alles, wasm droid
tut, plus alles, was nicht dasdroid
Tag hat. Der Build-Server führt dies aus, um sicherzustellen, dass alles, was sich im Baum befindet und über eineAndroid.mk
Datei verfügt, erstellt wird. -
m
- Führt Builds von der Spitze des Baums aus. Dies ist nützlich, da Siemake
innerhalb von Unterverzeichnissen ausführen können. Wenn Sie die UmgebungsvariableTOP
festgelegt haben, wird diese verwendet. Wenn Sie dies nicht tun, sucht es den Baum im aktuellen Verzeichnis nach oben 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 ihre 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 Erstellungsziel 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
Verwenden Sie zum Flashen eines Geräts 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 Ihrem Pfad automatisch durch den Erstellungsprozess hinzugefügt. Um den Emulator auszuführen, geben Sie Folgendes ein:
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 Beschreibung von FINGERPRINT im Abschnitt „Build Parameters“ des Android Compatibility Definition Document (CDD).
Der Build-Fingerabdruck repräsentiert eine bestimmte Android-Implementierung und -Revision. Mit diesem eindeutigen Schlüssel können App-Entwickler und andere Probleme mit bestimmten Firmware-Versionen melden. Siehe Melden von Fehlern für den Prozess zum Melden von Android-Problemen.
Ein Build-Fingerabdruck kapselt alle Details der Android-Implementierung:
- APIs: Android und nativ sowie weiches API-Verhalten
- Kern-API und einige System-UI-Verhalten
- Kompatibilitäts- und Sicherheitsanforderungen, die in der CDD definiert sind
- Produktspezifikationen und die Verwendungsfunktionseinstellung , die von Apps für Zielgeräte verwendet wird, die die erwarteten Anforderungen erfüllen
- Implementierungen von Hard- und Softwarekomponenten
Siehe CDD für vollständige Details und Hinzufügen eines neuen Geräts für Anweisungen zum Erstellen eines völlig neuen Android-Geräts.
Fehlerbehebung bei häufigen Build-Fehlern
Falsche Java-Version
Wenn Sie versuchen, eine Android-Version zu erstellen, die nicht mit Ihrer Java-Version übereinstimmt, make
Abbrüche mit einer Meldung wie der folgenden durch:
************************************************************ 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:
- Fehler bei der Installation des richtigen JDK gemäß den JDK-Anforderungen . Stellen Sie sicher, dass Sie die Schritte unter Einrichten der Umgebung und Auswählen eines Ziels befolgt haben.
- Ein anderes zuvor installiertes JDK, das in Ihrem Pfad erscheint. Stellen Sie das richtige JDK an den Anfang Ihres Pfads oder entfernen Sie das problematische JDK.
Keine USB-Berechtigung
Standardmäßig können nicht privilegierte Benutzer auf den meisten Linux-Systemen nicht auf USB-Anschlüsse zugreifen. Wenn der Fehler „Berechtigung verweigert“ angezeigt wird, befolgen Sie die Anweisungen unter Konfigurieren des USB-Zugriffs .
Wenn ADB bereits ausgeführt wurde und nach dem Einrichten dieser Regeln keine Verbindung zum Gerät herstellen kann, können Sie es mit adb kill-server
beenden. Dieser Befehl bewirkt, dass ADB mit der neuen Konfiguration neu gestartet wird.