Auf dieser Seite wird der gesamte Prozess zum Einreichen einer Codeänderung an das Android Open Source Project (AOSP) beschrieben, einschließlich der Schritte zum Anfordern einer Überprüfung und zum Überwachen Ihrer Änderungen.
AOSP verwendet Gerrit, ein webbasiertes Code-Review-System für Projekte, die Git verwenden.
Lizenzvereinbarungen für Mitwirkende unterzeichnen
Bevor Sie Codeänderungen für AOSP einreichen, müssen Sie die Lizenzvereinbarungen und ‑header für Mitwirkende lesen und eine der folgenden Vereinbarungen unterzeichnen:
- Wenn Sie als Einzelperson Beiträge nur in Ihrem Namen leisten, unterzeichnen Sie die Lizenzvereinbarung für Einzelpersonen.
- Wenn Sie für ein Unternehmen arbeiten, muss dieses die Lizenzvereinbarung für Unternehmensmitarbeiter unterzeichnet haben, die Sie dazu berechtigt, Beiträge im Namen des Unternehmens zu leisten.
Zweig starten
Führen Sie für jede Codeänderung, die Sie vornehmen möchten, die folgenden Schritte aus:
Erstellen Sie einen neuen Branch im entsprechenden Git-Repository. Ein Branch ist keine Kopie der ursprünglichen Dateien, sondern ein Verweis auf einen bestimmten Commit. Das Erstellen lokaler Branches und das Wechseln zwischen ihnen ist daher ein einfacher Vorgang. Mithilfe von Branches können Sie Änderungen voneinander unterscheiden. Führen Sie diesen Befehl aus, um einen Branch zu erstellen:
repo start BRANCH_NAME
Sie können mehrere unabhängige Branches gleichzeitig im selben Repository starten. Der Branch BRANCH_NAME ist lokal für Ihren Arbeitsbereich und ist weder in Gerrit noch im endgültigen Quellbaum enthalten. Branches sind auch für das Projekt spezifisch, in dem Sie sich befinden. Wenn Sie also Dateien in verschiedenen Projekten im Rahmen derselben Änderung ändern müssen, benötigen Sie in jedem Projekt, in dem Sie Dateien ändern, einen Branch.
Optional: Prüfen Sie, ob der Branch erstellt wurde:
repo status .
Der neu erstellte Branch sollte angezeigt werden. Beispiel:
project frameworks/native/ branch mynewbranch
Änderung vornehmen und testen
So nehmen Sie die Änderung vor und testen sie:
Führen Sie eine Synchronisierung der gesamten Codebasis durch, um sicherzustellen, dass Sie mit der aktuellen Codebasis arbeiten:
repo sync
Wenn während der Synchronisierung Konflikte auftreten, lesen Sie die Schritte 2 bis 4 unter Synchronisierungskonflikte beheben.
Suchen Sie den Code, den Sie ändern möchten. Sie können die Android Code Search verwenden, um Code zu finden. Mit der Android Code Search können Sie sich den AOSP-Quellcode in der Darstellung ansehen, die er bei der tatsächlichen Verwendung hat. Weitere Informationen finden Sie unter Einstieg in die Code Search. Wenn Sie sich den gesamten Code im
main
-Branch in der Android-Codesuche ansehen möchten, rufen Siehttps://cs.android.com/android/platform/superproject/main
auf.Quelldateien ändern oder hinzufügen Für alle vorgenommenen Änderungen gilt:
Prüfen Sie, ob Sie Flags für die Einführung von Funktionen verwenden müssen, und implementieren Sie sie gegebenenfalls für Ihren neuen Code.
Beachte die Best Practices unter Lizenzheader einfügen.
Beachten Sie für Java-Code den AOSP-Java-Codestil für Mitwirkende.
Einige Teile von AOSP sind in Kotlin (
.kt
) geschrieben. Sie können Kotlin in Bereichen der Plattform verwenden, die bereits in Kotlin geschrieben sind. Weitere Informationen zu Kotlin in Android finden Sie im Kotlin-Styleguide und im Leitfaden zur Kotlin-Java-Interoperabilität. Weitere Informationen zu Kotlin finden Sie auf der Kotlin-Website.Beachten Sie beim Erstellen von APIs die Android API-Richtlinien. Anhand dieser Richtlinien können Sie den Kontext hinter den API-Entscheidungen von Android nachvollziehen. Ergänzungen und Änderungen an Plattform-APIs werden von Metalava validiert.
Änderungen in die Staging-Umgebung verschieben und committen
Ein Commit ist die grundlegende Einheit der Versionskontrolle in Git und besteht aus einem Snapshot der Verzeichnisstruktur und des Dateiinhalts für das gesamte Projekt. So nehmen Sie die Änderung vor:
Standardmäßig registriert Git die von Ihnen vorgenommenen Änderungen, verfolgt sie aber nicht. Damit Git Ihre Änderungen verfolgen kann, müssen Sie diese Änderungen für die Aufnahme in ein Commit kennzeichnen oder in die Staging-Area verschieben. Führen Sie diesen Befehl aus, um die Änderung zu steuern:
git add -A
Mit diesem Befehl werden Änderungen an Dateien erfasst.
Führen Sie einen Commit für die Dateien im Staging-Bereich aus oder speichern Sie sie in Ihrer lokalen Datenbank:
git commit -s
Standardmäßig wird ein Texteditor geöffnet und Sie werden aufgefordert, eine Commit-Nachricht anzugeben.
Geben Sie eine Commit-Nachricht im folgenden Format an:
Zeile 1: Anzeigentitel. Geben Sie eine Zusammenfassung der Änderung in einer Zeile an (maximal 50 Zeichen). Sie können Präfixe verwenden, um den geänderten Bereich zu beschreiben, gefolgt von einer Beschreibung der Änderung, die Sie in diesem Commit vorgenommen haben. Das folgende Beispiel enthält eine Änderung an der Benutzeroberfläche:
ui: Removes deprecated widget
Zeile 2: Leere Zeile. Fügen Sie nach der Überschrift eine leere Zeile ein.
Zeile 3: Textkörper. Geben Sie eine lange Textzeile ein, die bei maximal 72 Zeichen automatisch umgebrochen wird. Beschreiben Sie, welches Problem durch die Änderung gelöst wird und wie. Der Textkörper ist zwar optional, aber hilfreich für andere, die sich auf die Änderung beziehen müssen. Geben Sie auch alle Annahmen oder Hintergrundinformationen an, die für andere Mitbearbeiter wichtig sein könnten, die an dieser Funktion arbeiten.
Einen Blogpost zu guten Commit-Beschreibungen (mit Beispielen) finden Sie unter How to Write a Git Commit Message.
Speichern Sie den Commit.
Ihrer Commit-Nachricht werden automatisch eine eindeutige Änderungs-ID sowie Ihr Name und Ihre E-Mail-Adresse hinzugefügt, die Sie bei repo init
angegeben haben.
Änderung zur Überprüfung hochladen
Nachdem Sie die Änderung in Ihrem persönlichen Git-Verlauf gespeichert haben, laden Sie sie in Gerrit hoch:
Führen Sie den folgenden Befehl aus, um alle Commits in allen Ihren Projekten hochzuladen:
repo upload
Alle Änderungen in allen Projekten sind im Upload enthalten.
.Sie werden aufgefordert, Hook-Scripts auszuführen.
Drücken Sie a und dann die Eingabetaste.
Sie werden aufgefordert, den Upload zu genehmigen:
Upload project frameworks/native/ to remote branch main: branch BRANCH_NAME ( 1 commit, Wed Aug 7 09:32:33 2019 -0700): ff46b36d android codelab change to https://android-review.googlesource.com/ (y/N)?
Drücken Sie y und dann die Eingabetaste, um den Upload zu genehmigen.
Sie sollten eine Meldung ähnlich der folgenden erhalten:remote: SUCCESS
Überprüfung beantragen
Nach einem erfolgreichen Upload erhalten Sie in Repo einen Link zu Ihren Änderungen in Gerrit. Klicken Sie auf den Link, um Ihre Änderungen auf dem Überprüfungsserver anzusehen, Kommentare hinzuzufügen oder bestimmte Prüfer für Ihre Änderung anzufordern. Alle Änderungen am Code müssen von den entsprechenden Codeinhabern überprüft werden.
So beantragen Sie eine Überprüfung:
Klicken Sie in Gerrit auf INHABER VORSCHLAGEN:
Abbildung 1: Link für Inhaber in Gerrit vorschlagen
Das Dialogfeld für die Rezension wird angezeigt. Dieses Dialogfeld enthält eine Liste der Codeinhaber, die Ihre Änderung prüfen können.
Klicken Sie auf einen Codeinhaber, um ihn der Überprüfung hinzuzufügen.
Die Schaltfläche SENDEN ist aktiviert.
Optional: Geben Sie die E-Mail-Adresse einer weiteren Person ein, die die Änderung prüfen soll.
Optional: Klicken Sie neben „Automatisch einreichen“ auf +1, damit die Änderung automatisch eingereicht wird, sobald Sie die Genehmigungen erhalten haben. Wenn Sie diese Schaltfläche nicht anklicken, muss ein Google-Mitarbeiter die Änderung für Sie einreichen.
Klicken Sie auf SENDEN, um die Änderung zur Überprüfung zu senden.
Codeinhaber überprüfen Ihre Codeänderungen und geben Ihnen entweder Feedback, um die Änderungen zu beheben, oder genehmigen sie.
Status der Änderung ermitteln
Um den Status der Dateien in Ihrer Änderung zu ermitteln, sehen Sie sich die folgenden Symbole neben den Dateien in der Änderung an:
- (Kästchensymbol): Vom Codeinhaber genehmigt
- (Kreuzsymbol): Nicht vom Codeinhaber genehmigt
- (Uhrsymbol): Genehmigung durch Codeinhaber ausstehend
In der folgenden Abbildung sind diese Statussymbole zu sehen, die auf Dateien in einer Änderung angewendet werden:
Abbildung 2: Beispiel für Dateien mit Symbolen, die die Genehmigung des Codeinhabers anzeigen
Feedback beheben und Ersatzänderung hochladen
Wenn ein Prüfer eine Änderung an Ihrem Update anfordert, können Sie Ihr Commit in Git ändern. Dies führt zu einem neuen Patch-Set für dieselbe Änderung.
So beheben Sie Feedback und ändern Ihre Änderung:
Führen Sie die Schritte 2 bis 4 unter Änderung vornehmen und testen aus.
Führen Sie die folgenden Befehle aus, um die Änderung zu korrigieren:
git add -A git commit --amend
Wenn Sie die geänderte Änderung hochladen, wird die ursprüngliche Version sowohl in Gerrit als auch in Ihrem lokalen Git-Verlauf ersetzt.
Synchronisierungskonflikte beheben
Wenn andere Änderungen an den Quellcode gesendet werden, die mit Ihren Änderungen in Konflikt stehen, erhalten Sie eine Benachrichtigung. So lösen Sie die Konflikte:
Prüfen Sie, ob Sie mit dem aktuellen Code arbeiten:
repo sync .
Der Befehl
repo sync
ruft die Updates vom Quellserver ab und versucht dann, IhreHEAD
automatisch auf die neue Remote-HEAD
umzustellen.Wenn der automatische Rebase fehlschlägt, führen Sie einen manuellen Rebase aus:
repo rebase .
Lösen Sie Zusammenführungskonflikte. Wenn Sie keine bevorzugte Methode zur Behebung von Zusammenführungskonflikten haben, können Sie
git mergetool
verwenden, um Konflikte zwischen Dateien manuell zu beheben.Wenn Sie die Konfliktdateien behoben haben, führen Sie diesen Befehl aus, um die neuen Commits anzuwenden:
git rebase --continue
Änderung senden
Nachdem eine Einreichung den Überprüfungs- und Bestätigungsprozess durchlaufen hat, muss ein Google-Prüfer den Code für Sie einreichen. Andere Nutzer können repo sync
ausführen, um das Update in ihre jeweiligen lokalen Clients zu ziehen.
Nachdem Ihre Einreichung zusammengeführt wurde, können Sie im Dashboard Android Continuous Integration nachsehen, wann Ihre Einreichungen in den Stammbaum integriert werden.