Einreichen von Patches

Auf dieser Seite wird der vollständige Prozess zum Einreichen eines Patches an das Android Open Source Project (AOSP) beschrieben, einschließlich der Anforderung einer Überprüfung und der Verfolgung Ihrer Änderungen mit Gerrit .

Voraussetzungen

Stellen Sie zunächst sicher, dass Sie Folgendes getan haben:

Ressourcen

  • Weitere Informationen zu Repo und Git finden Sie auf der Seite Quellcodeverwaltungstools .
  • Informationen zu verschiedenen Rollen in der Android Open Source-Community finden Sie auf der Seite Projektrollen .
  • Lizenzinformationen zum Beitragen von Code zur Android-Plattform finden Sie auf der Seite Lizenzen .

Für Mitwirkende

Authentifizierung mit dem Server

Wenn Sie eine IP-Adresse mit anderen Nutzern teilen, können auch bei regelmäßigen Nutzungsmustern Kontingente ausgelöst werden. Dies kann beispielsweise passieren, wenn viele Benutzer innerhalb kurzer Zeit neue Clients von derselben IP-Adresse synchronisieren. Beim authentifizierten Zugriff wird für jeden Benutzer unabhängig von der IP-Adresse ein separates Kontingent verwendet. Informationen zum Aktivieren des authentifizierten Zugriffs finden Sie unter Verwenden der Authentifizierung .

Starten einer Repo-Filiale

Starten Sie für jede Änderung, die Sie vornehmen möchten, einen neuen Branch innerhalb des entsprechenden Git-Repositorys:

repo start NAME .

Sie können mehrere unabhängige Zweige gleichzeitig im selben Repository starten. Der Branch NAME ist lokal in Ihrem Workspace und ist weder auf Gerrit noch im endgültigen Quellbaum enthalten.

Machen Sie Ihre Änderung

Ändern Sie die Quelldateien und validieren Sie Ihre Änderungen.

Übertragen Sie die Änderungen mit diesen Befehlen in Ihr lokales Repository:

git add -A
git commit -s

Beschreibungen ändern

  • Zeile 1: Überschrift

    Geben Sie eine einzeilige Zusammenfassung an ( maximal 50 Zeichen)

    Dieses Format wird von Git und Gerrit für verschiedene Displays verwendet. Es ist der wichtigste und dichteste Teil Ihrer Commit-Nachricht. Ziehen Sie in Erwägung, Präfixe zu verwenden, um den geänderten Bereich zu beschreiben, gefolgt von einer Beschreibung der Änderung, die Sie in diesem Commit vorgenommen haben, wie beispielsweise diese mit ui als Präfix:

    ui: Removes deprecated widget

  • Zeile 2: Leerzeichen

    Lassen Sie diese Zeile immer leer.

  • Zeile 3: Körper

    Schreiben Sie eine längere Beschreibung, beginnend mit dieser Zeile.

    Dieser muss mit maximal 72 Zeichen fest umbrochen werden. Beschreiben Sie, welches Problem die Änderung löst und wie. Obwohl dies beim Implementieren neuer Funktionen optional ist, ist es für andere später sehr hilfreich, wenn sie sich auf diese Änderung beziehen, insbesondere beim Debuggen.

    Fügen Sie eine kurze Anmerkung zu Annahmen oder Hintergrundinformationen hinzu, die wichtig sein könnten, wenn ein anderer Mitwirkender an dieser Funktion arbeitet.

Eine eindeutige Änderungs-ID sowie Ihr Name und Ihre E-Mail-Adresse, die während repo init bereitgestellt werden, werden Ihrer Commit-Nachricht automatisch hinzugefügt.

Hier ist eine Beispiel-Commit-Nachricht:

Line 1, Headline - a short description

Line 3, Body - Add the detailed description of your patch here. Use as many lines
as needed. You can write an overall description, then list specifics.

I6e3c64e7a:Added a new widget.
I60c539a8f:Fixed the spinning image.
Um einen Blog über gute Commit-Beschreibungen (mit Beispielen) zu lesen, siehe How to Write a Git Commit Message von Chris Beams.

Hochladen auf Gerrit

Nachdem Sie Ihre Änderung in Ihren persönlichen Verlauf übernommen haben, laden Sie sie mit diesem Befehl zu Gerrit hoch:

repo upload

Wenn Sie mehrere Branches im selben Repository gestartet haben, werden Sie aufgefordert, auszuwählen, welche hochgeladen werden sollen.

Nach einem erfolgreichen Upload stellt Ihnen Repo die URL einer neuen Seite auf Gerrit zur Verfügung . Klicken Sie auf den von Repo bereitgestellten Link, um Ihren Patch auf dem Review-Server anzuzeigen, Kommentare hinzuzufügen oder bestimmte Reviewer für Ihren Patch anzufordern.

Eine Überprüfung anfordern

Nachdem Sie Ihre Änderungen in Gerrit hochgeladen haben, muss der Patch von den entsprechenden Codebesitzern überprüft und genehmigt werden. OWNERS in OWNERS Dateien.

Gehen Sie folgendermaßen vor, um die entsprechenden Codebesitzer zu finden und sie als Prüfer für Ihre Änderung hinzuzufügen.

  1. Wählen Sie den Link EIGENTÜMER VORSCHLAGEN in der Gerrit-Benutzeroberfläche aus, um eine Liste der Codebesitzer für die Dateien in Ihrem Patch anzuzeigen .

    Eigentümerlink in Gerrit . vorschlagen
    Abbildung 1. Eigentümer-Link in Gerrit vorschlagen
  2. Fügen Sie Codebesitzer aus der Liste als Prüfer für Ihren Patch hinzu.

Um den Status der Dateien in Ihrem Patch zu ermitteln, suchen Sie nach den folgenden Symbolen neben den Dateien im Patch.

  • (Häkchen-Symbol): Vom Code-Eigentümer genehmigt
  • (Kreuzsymbol): Nicht vom Codebesitzer genehmigt
  • ( ): Genehmigung durch ausstehend
Abbildung 2. Beispiel für Dateien mit Symbolen, die den Genehmigungsstatus des Codebesitzers anzeigen

Hochladen eines Ersatz-Patches

Angenommen, ein Prüfer hat sich Ihren Patch angesehen und eine kleine Änderung angefordert. Sie können Ihren Commit innerhalb von Git ändern, was zu einem neuen Patch auf Gerrit führt, der dieselbe Änderungs-ID wie das Original hat.

git add -A
git commit --amend

Wenn Sie den geänderten Patch hochladen, ersetzt dieser das Original sowohl auf Gerrit als auch in Ihrer lokalen Git-Historie.

Synchronisierungskonflikte lösen

Wenn andere Patches an den Quellbaum gesendet werden, die mit Ihrem in Konflikt stehen, bauen Sie Ihren Patch auf den neuen HEAD des Quell-Repositorys um. Führen Sie dazu diesen Befehl aus:

repo sync

Der Befehl repo sync ruft die Updates vom Quellserver ab und versucht dann, Ihren HEAD automatisch auf den neuen Remote- HEAD umzubasieren.

Wenn die automatische Neubasis nicht erfolgreich ist, führen Sie eine manuelle Neubasis durch.

repo rebase

Ein weiteres Werkzeug zum Umgang mit dem Rebase-Konflikt ist git mergetool . Wenn Sie die widersprüchlichen Dateien erfolgreich zusammengeführt haben, führen Sie diesen Befehl aus:

git rebase --continue

Nachdem das automatische oder manuelle Rebase abgeschlossen ist, führen Sie den repo upload , um Ihren rebasierten Patch einzureichen.

Nachdem eine Einreichung genehmigt wurde

Nachdem eine Einreichung den Überprüfungs- und Verifizierungsprozess durchlaufen hat, führt Gerrit die Änderung automatisch in das öffentliche Repository ein. Andere Benutzer können die repo sync ausführen, um das Update in ihre jeweiligen lokalen Clients zu übertragen.

Für Upstream-Projekte

Android verwendet eine Reihe anderer Open-Source-Projekte, wie den Linux-Kernel und WebKit, wie in Android Software Management beschrieben . Nehmen Sie bei den meisten Projekten, die sich unter external/ , die Änderungen im Upstream vor und informieren Sie dann die Android-Maintainer über die neue Upstream-Version, die Ihre Änderungen enthält.

Sie können auch Patches hochladen, die dazu führen, dass eine neue Upstream-Version verfolgt wird. Beachten Sie, dass dies schwierige Änderungen sein können, wenn das Projekt in Android weit verbreitet ist, wie die meisten der unten aufgeführten größeren, die normalerweise mit jeder Version aktualisiert werden.

Ein interessanter Sonderfall ist Bionic. Ein Großteil des Codes stammt von BSD. Wenn es sich also nicht um neuen Code für Bionic handelt, machen Sie bitte einen Upstream-Fix und ziehen Sie dann eine ganz neue Datei aus dem entsprechenden BSD.

Android-Kernel

Nehmen Sie lieber alle Änderungen im Upstream vor. Eine allgemeine Anleitung finden Sie in den Richtlinien für Beiträge zum Android-Kernel .

ICU4C

Nehmen Sie alle Änderungen am ICU4C-Projekt unter external/icu4c auf der ICU-TC- external/icu4c vor. Weitere Informationen finden Sie unter Einreichen von Fehlern auf der Intensivstation und Funktionsanfragen .

LLVM/Clang/Compiler-rt

external/llvm Sie alle Änderungen an LLVM-bezogenen Projekten ( external/clang , external/compiler-rt , external/llvm ) auf der Seite LLVM Compiler Infrastructure vor .

mksh

Nehmen Sie alle Änderungen am MirBSD Korn Shell-Projekt unter external/mksh indem external/mksh entweder eine E miros-mksh Mail an miros-mksh in der Domain mirbsd.org (kein Abonnement zum Einreichen dort erforderlich) oder über Launchpad senden.

OpenSSL

Nehmen Sie alle Änderungen am OpenSSL-Projekt unter external/openssl auf der OpenSSL-Seite vor .

V8

Senden Sie alle Änderungen am V8-Projekt unter external/v8 auf der V8-Ausgabeseite . Weitere Informationen finden Sie unter Beitrag zu V8 .

WebKit

external/webkit Sie alle Änderungen am WebKit-Projekt unter external/webkit auf der WebKit-Seite vor . Starten Sie den Prozess, indem Sie einen WebKit-Fehler melden . Verwenden Sie im Fehler nur Android für die Felder Plattform und Betriebssystem , wenn der Fehler spezifisch für Android ist. Fehler erhalten viel eher die Aufmerksamkeit der Prüfer, nachdem ein vorgeschlagener Fix hinzugefügt wurde und Tests enthalten sind. Weitere Informationen finden Sie unter Code zu WebKit beitragen .

zlib

Nehmen Sie alle Änderungen am zlib-Projekt unter external/zlib auf der zlib-Homepage vor .