Einreichen von Patches

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 .

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

Nehmen Sie Ihre Änderung vor

Ä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 ( 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 der 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 Branches hochgeladen werden sollen.

Nach erfolgreichem Hochladen stellt Ihnen Repo die URL einer neuen Seite auf Gerrit zur Verfügung. Klicken Sie auf den Link, den Repo Ihnen gibt, um Ihren Patch auf dem Überprüfungsserver anzuzeigen, Kommentare hinzuzufügen oder bestimmte Prüfer für Ihren Patch anzufordern.

Beantragung einer Überprüfung

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

Führen Sie die folgenden Schritte aus, um die entsprechenden Codeinhaber 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 Code-Eigentümer für die Dateien in Ihrem Patch anzuzeigen.

    Eigentümerlink in Gerrit vorschlagen
    Abbildung 1. Link „Eigentümer vorschlagen“ in Gerrit
  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, prüfen Sie die folgenden Symbole neben den Dateien im Patch.

  • (Häkchensymbol): Genehmigt vom Codeinhaber
  • (Kreuzsymbol): Nicht vom Code-Inhaber genehmigt
  • (Uhrsymbol): Ausstehende Genehmigung durch den Codebesitzer
Abbildung 2. Beispiel für Dateien mit Symbolen, die den Genehmigungsstatus des Codeinhabers anzeigen

Hochladen eines Ersatzpatches

Angenommen, ein Prüfer hat sich Ihren Patch angesehen und eine kleine Änderung angefordert. Sie können Ihr 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 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 den 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 die 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 lieber alle Änderungen im Upstream vor. Befolgen Sie für eine allgemeine Anleitung die Android-Kernel-Beitragsrichtlinien .

Intensivstation

Nehmen Sie alle Änderungen am ICU-Projekt unter external/icu (Ordner icu4c/ und icu4j/ ) auf der ICU-TC-Startseite vor. Weitere Informationen finden Sie unter Einreichen von ICU-Fehlern und Funktionsanfragen .

CLDR

Die meisten Sprachdaten in ICU stammen aus dem Unicode CLDR-Projekt . Bitte reichen Sie alle Anfragen im Upstream mithilfe der CLDR-Änderungsanfragen ein 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 , indem Sie entweder eine E-Mail an miros-mksh in der Domain mirbsd.org (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.