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 Frage, wie Sie eine Überprüfung anfordern und Ihre Änderungen mit Gerrit nachverfolgen können.

Voraussetzungen

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

Ressourcen

  • Einzelheiten zu Repo und Git finden Sie auf der Seite Source Control Tools .
  • Informationen zu verschiedenen Rollen innerhalb der Android Open Source-Community finden Sie auf der Seite Projektrollen .
  • Lizenzierungsinformationen zum Beitragen von Code zur Android-Plattform finden Sie auf der Seite Lizenzen .

Für Mitwirkende

Authentifizierung beim Server

Wenn Sie eine IP-Adresse mit anderen Benutzern teilen, können Kontingente sogar für regelmäßige Nutzungsmuster ausgelöst werden. Dies kann beispielsweise passieren, wenn viele Benutzer innerhalb kurzer Zeit neue Clients von derselben IP-Adresse synchronisieren. Der authentifizierte Zugriff verwendet unabhängig von der IP-Adresse ein separates Kontingent für jeden Benutzer. Informationen zum Aktivieren des authentifizierten Zugriffs finden Sie unter Authentifizierung verwenden .

Starten eines Repo-Zweigs

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

repo start NAME .

You can start several independent branches at the same time in the same repository. The branch NAME is local to your workspace and isn't included either on Gerrit or in the final source tree.

Making your change

Modify the source files, and validate your changes.

Commit the changes to your local repository with these commands:

git add -A
git commit -s

Beschreibungen ändern

  • Zeile 1: Überschrift

    Geben Sie eine einzeilige Zusammenfassung ( maximal 50 Zeichen) an.

    Dieses Format wird von Git und Gerrit für verschiedene Anzeigen verwendet. Es ist der wichtigste und dichteste Teil Ihrer Commit-Nachricht. Erwägen Sie die Verwendung von Präfixen, um den Bereich zu beschreiben, den Sie geändert haben, gefolgt von einer Beschreibung der Änderung, die Sie in diesem Commit vorgenommen haben, wie z. B. dieser, der ui als Präfix hat:

    ui: Removes deprecated widget

  • Zeile 2: Leer

    Lassen Sie diese Zeile immer leer.

  • Zeile 3: Körper

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

    Dies muss maximal 72 Zeichen umfassen. Beschreiben Sie, welches Problem durch die Änderung gelöst wird und wie. Obwohl dies bei der Implementierung neuer Funktionen optional ist, ist es für andere später sehr hilfreich, wenn sie sich auf diese Änderung beziehen, insbesondere zum Debuggen.

    Fügen Sie eine kurze Notiz 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.
To read a blog about good commit descriptions (with examples), see How to Write a Git Commit Message by Chris Beams.

Uploading to Gerrit

After you commit your change to your personal history, upload it to Gerrit with this command: 

repo upload

If you started multiple branches in the same repository, you're prompted to select which ones to upload.

After a successful upload, Repo provides you with the URL of a new page on Gerrit. Click the link that Repo gives you to view your patch on the review server, add comments, or request specific reviewers for your patch.

Requesting a review

After you've uploaded your changes to Gerrit, the patch must be reviewed and approved by the appropriate code owners. Locate code owners in OWNERS files.

To find the appropriate code owners and add them as reviewers for your change, follow these steps.

  1. Select the SUGGEST OWNERS link in the Gerrit UI to see a list of code owners for the files in your patch.

    suggest owners link in Gerrit
    Figure 1. Suggest owners link in Gerrit

  2. Add code owners from the list as reviewers for your patch.

To determine the status of the files in your patch, check for the following icons next to the files in the patch.

  • (checkmark icon): Approved by code owner
  • (cross icon): Not approved by code owner
  • (clock icon): Pending approval by code owner
Figure 2. Example of files with icons showing code owner approval status

Uploading a replacement patch

Suppose a reviewer looked at your patch and requested a small modification. You can amend your commit within Git, which results in a new patch on Gerrit that has the same change ID as the original. 

git add -A
git commit --amend

Wenn Sie den geänderten Patch hochladen, ersetzt er das Original sowohl auf Gerrit als auch in Ihrem lokalen Git-Verlauf.

Synchronisierungskonflikte lösen

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

repo sync

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

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

repo rebase

Ein weiteres Tool 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 die automatische oder manuelle Rebase abgeschlossen ist, führen Sie repo upload aus, um Ihren rebasierten Patch zu übermitteln.

Nachdem eine Einreichung genehmigt wurde

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

Für Upstream-Projekte

Android nutzt eine Reihe anderer Open-Source-Projekte wie den Linux-Kernel und WebKit, wie in Android Software Management beschrieben. Nehmen Sie für die meisten Projekte, die sich unter external/ befinden, die Änderungen im Upstream vor und informieren Sie dann die Android-Betreuer ü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 nachverfolgt wird. Beachten Sie, dass diese Änderungen schwierig sein können, wenn das Projekt in Android weit verbreitet ist, wie die meisten der unten genannten größeren, die normalerweise mit jeder Version aktualisiert werden.

Ein interessanter Spezialfall ist Bionic. Ein Großteil des dortigen Codes stammt von BSD. Wenn die Änderung also nicht in Code geändert wird, der neu für Bionic ist, nehmen Sie bitte eine Upstream-Korrektur vor und ziehen Sie dann eine ganz neue Datei aus dem entsprechenden BSD.

Android-Kernel

Nehmen Sie alle Änderungen stromaufwärts vor. Als allgemeine Anleitung folgen Sie den Android Kernel Contribution Guidelines und der Seite Develop Kernel Code for GKI .

Intensivstation

Nehmen Sie alle Änderungen am ICU-Projekt unter external/icu (Ordner icu4c/ und icu4j/ ) auf der ICU-TC-Homepage vor . Weitere Informationen finden Sie unter Einreichen von ICU-Fehlern und Funktionsanfragen . Fügen Sie allen Upstream-Jira-Anfragen das Label „Android“ hinzu.

CLDR

Die meisten Sprachdaten in ICU stammen aus dem Unicode CLDR-Projekt . Senden Sie alle Anfragen gemäß Contributing to CLDR upstream und fügen Sie das Label „Android“ hinzu.

LLVM/Clang/Compiler-rt

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

mksch

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

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-Problemseite . Einzelheiten finden Sie unter Mitwirken an V8 .

WebKit

Nehmen Sie alle Änderungen am WebKit-Projekt unter external/webkit auf der WebKit-Seite vor. Beginnen Sie den Prozess, indem Sie einen WebKit-Fehler melden . Verwenden Sie im Fehler Android nur dann für die Felder Plattform und Betriebssystem , wenn der Fehler für Android spezifisch ist. Es ist viel wahrscheinlicher, dass Fehler die Aufmerksamkeit der Prüfer auf sich ziehen, nachdem ein vorgeschlagener Fix hinzugefügt und Tests aufgenommen wurden. Weitere Informationen finden Sie unter Beitragen von Code zu WebKit .

zlib

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