Na tej stronie opisano pełny proces przesyłania łatki do projektu Android Open Source Project (AOSP), w tym sposób żądania sprawdzenia i śledzenia zmian za pomocą Gerrita .
Warunki wstępne
Aby rozpocząć, upewnij się, że wykonałeś następujące czynności:
- Zainicjowano środowisko kompilacji
- Pobrałem źródło
- Utworzono hasło za pomocą generatora haseł.
Zasoby
- Aby uzyskać szczegółowe informacje na temat Repo i Git, zobacz stronę Narzędzia kontroli źródła .
- Aby uzyskać informacje na temat różnych ról w społeczności Android Open Source, zobacz stronę ról w projekcie .
- Informacje o licencjach na temat udostępniania kodu na platformę Android można znaleźć na stronie Licencje .
Dla autorów
Uwierzytelnij się na serwerze
Jeśli udostępniasz adres IP innym użytkownikom, limity mogą zostać uruchomione nawet w przypadku regularnych wzorców użytkowania. Może się to zdarzyć, gdy na przykład wielu użytkowników synchronizuje nowych klientów z tego samego adresu IP w krótkim czasie. Dostęp uwierzytelniony wykorzystuje oddzielny limit dla każdego użytkownika, niezależnie od adresu IP. Aby przeczytać o aktywowaniu uwierzytelnionego dostępu, zobacz Korzystanie z uwierzytelniania .
Uruchom oddział Repo
Dla każdej zmiany, którą zamierzasz wprowadzić, rozpocznij nową gałąź w odpowiednim repozytorium Git:
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.
Make 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
Zmień opisy
- Wiersz 1: Nagłówek
Podaj jednoliniowe podsumowanie ( maksymalnie 50 znaków)
Ten format jest używany przez Git i Gerrit do różnych wyświetlaczy. To najważniejsza, najgęstsza część wiadomości o zatwierdzeniu. Rozważ użycie przedrostków do opisania zmienionego obszaru, po którym należy podać opis zmiany wprowadzonej w tym zatwierdzeniu, na przykład ten, który ma przedrostek
ui
:ui: Removes deprecated widget
- Linia 2: Pusta
Zawsze pozostawiaj tę linię pustą.
- Linia 3: Ciało
Napisz dłuższy opis, zaczynając od tej linijki.
Musi to być zawinięte na stałe i mieć maksymalnie 72 znaki. Opisz, jaki problem rozwiązuje ta zmiana i w jaki sposób. Chociaż jest to opcjonalne przy wdrażaniu nowych funkcji, jest bardzo pomocne dla innych osób później, jeśli odwołują się do tej zmiany, szczególnie w przypadku debugowania.
Dołącz krótką notatkę na temat wszelkich założeń lub informacji ogólnych, które mogą być ważne, gdy inny współautor pracuje nad tą funkcją.
Unikalny identyfikator zmiany oraz Twoje imię i nazwisko oraz adres e-mail, które są podawane podczas repo init
, są automatycznie dodawane do wiadomości zatwierdzenia.
Oto przykładowy komunikat zatwierdzenia:
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.
Sign contributor license agreement
Before you can upload a change to Gerrit, you must sign an Individual Contributor License Agreement. If you work for a corporation, you might also need your coproration to sign a Corporation Contributor License Agreement. For more information on these agreements, including links to each, see Contributor license agreements.
Upload 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.
Request 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.
-
Select the SUGGEST OWNERS link in the Gerrit UI to see a list of code owners for the files in your patch.
Figure 1. Suggest owners link in Gerrit 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

Upload 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
Gdy prześlesz poprawioną łatkę, zastępuje ona oryginał zarówno w Gerrit, jak i w lokalnej historii Git.
Rozwiązuj konflikty synchronizacji
Jeśli do drzewa źródłowego przesłane zostaną inne łatki, które kolidują z twoim, ponownie oprzyj łatkę na nowym HEAD
repozytorium źródłowego. Aby to zrobić, uruchom to polecenie:
repo sync
Polecenie repo sync
pobiera aktualizacje z serwera źródłowego, a następnie próbuje automatycznie ponownie bazować HEAD
na nowym zdalnym HEAD
.
Jeśli automatyczna zmiana bazy nie powiedzie się, wykonaj ręczną zmianę bazy.
repo rebase
Innym narzędziem do radzenia sobie z konfliktem rebase jest git mergetool
. Po pomyślnym połączeniu plików będących w konflikcie uruchom to polecenie:
git rebase --continue
Po zakończeniu automatycznej lub ręcznej zmiany bazy uruchom repo upload
, aby przesłać łatkę ponownie opartą.
Po zatwierdzeniu zgłoszenia
Gdy zgłoszenie przejdzie przez proces przeglądu i weryfikacji, Gerrit automatycznie łączy zmianę z publicznym repozytorium. Inni użytkownicy mogą uruchomić repo sync
, aby pobrać aktualizację do swoich lokalnych klientów.
Dla projektów typu upstream
Android korzysta z wielu innych projektów open source, takich jak jądro Linuksa i WebKit, jak opisano w Zarządzanie oprogramowaniem Androida . W przypadku większości projektów znajdujących się w folderze external/
wprowadź zmiany wcześniej, a następnie poinformuj opiekunów Androida o nowej wersji źródłowej, która zawiera Twoje zmiany.
Możesz także przesłać poprawki, które umożliwią śledzenie nowej wersji źródłowej. Pamiętaj, że wprowadzenie tych zmian może być trudne, jeśli projekt jest szeroko używany w systemie Android, jak większość większych projektów wymienionych poniżej, które zwykle są aktualizowane z każdą wersją.
Ciekawym przypadkiem specjalnym jest Bionic. Duża część kodu pochodzi z BSD, więc jeśli zmiana nie dotyczy kodu, który jest nowy dla Bionic, proszę dokonać wcześniejszej poprawki, a następnie pobrać zupełnie nowy plik z odpowiedniego BSD.
Jądro Androida
Wprowadź wszystkie zmiany powyżej. Aby uzyskać ogólne wskazówki, postępuj zgodnie z wytycznymi dotyczącymi wkładu jądra systemu Android i stroną opracowywania kodu jądra dla GKI .
OIOM
Wprowadź wszystkie zmiany w projekcie ICU w external/icu
(foldery icu4c/
i icu4j/
) na stronie głównej ICU-TC . Aby uzyskać więcej informacji, zobacz Przesyłanie błędów ICU i próśb o nowe funkcje . Dodaj etykietę „Android” do wszystkich nadrzędnych żądań Jira.
CLDR
Większość danych językowych w ICU pochodzi z projektu Unicode CLDR . Prześlij wszystkie żądania w górę zgodnie z częścią „Wkład w CLDR ” i dodaj etykietę „Android”.
LLVM/Clang/Compiler-rt
Wprowadź wszystkie zmiany w projektach związanych z LLVM ( external/clang
, external/compiler-rt
, external/llvm
) na stronie infrastruktury kompilatora LLVM .
mksz
Wprowadź wszystkie zmiany w projekcie MirBSD Korn Shell na external/mksh
, wysyłając wiadomość e-mail na adres miros-mksh
w domenie mirbsd.org
(do przesłania nie jest wymagana subskrypcja) lub na Launchpad .
OtwórzSSL
Wprowadź wszystkie zmiany w projekcie OpenSSL w pliku external/openssl
na stronie OpenSSL .
V8
Prześlij wszystkie zmiany do projektu V8 na external/v8
na stronie wydania V8 . Aby uzyskać szczegółowe informacje, zobacz Wkład w V8 .
WebKita
Wprowadź wszystkie zmiany w projekcie WebKit w lokalizacji external/webkit
na stronie WebKit . Rozpocznij proces od zgłoszenia błędu WebKit . W przypadku błędu użyj Android
w polach Platforma i System operacyjny tylko wtedy, gdy błąd jest specyficzny dla Androida. Błędy są znacznie bardziej prawdopodobne, że zwrócą uwagę recenzentów po dodaniu proponowanej poprawki i uwzględnieniu testów. Aby uzyskać szczegółowe informacje, zobacz Współtworzenie kodu do WebKit .
zlib
Wprowadź wszystkie zmiany w projekcie zlib w katalogu external/zlib
na stronie głównej zlib .