Na tej stronie opisano pełny proces przesyłania poprawki do projektu Android Open Source Project (AOSP), w tym sposób zgłaszania prośby o sprawdzenie i śledzenia zmian za pomocą Gerrit .
Warunki wstępne
Na początek upewnij się, że wykonałeś następujące czynności:
- Zainicjuj swoje środowisko kompilacji
- Pobrano ź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 o różnych rolach w społeczności Android Open Source, zobacz stronę Role projektu .
- Aby uzyskać informacje licencyjne dotyczące wnoszenia kodu na platformę Android, zobacz stronę Licencje .
Dla współtwórców
Uwierzytelnianie z serwerem
Jeśli udostępnisz adres IP innym użytkownikom, limity mogą zostać uruchomione nawet w przypadku regularnych wzorców użytkowania. Może się tak 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 osobny przydział dla każdego użytkownika, niezależnie od adresu IP. Aby przeczytać o aktywowaniu dostępu uwierzytelnionego, zobacz Korzystanie z uwierzytelniania .
Rozpoczęcie oddziału Repo
Dla każdej zmiany, którą zamierzasz wprowadzić, zacznij nową gałąź w odpowiednim repozytorium Git:
repo start NAME .
Możesz uruchomić kilka niezależnych oddziałów jednocześnie w tym samym repozytorium. Gałąź NAME
jest lokalna w Twoim obszarze roboczym i nie jest zawarta ani w Gerrit, ani w końcowym drzewie źródłowym.
Dokonywanie zmian
Zmodyfikuj pliki źródłowe i zweryfikuj swoje zmiany.
Zatwierdź zmiany w lokalnym repozytorium za pomocą tych poleceń:
git add -A
git commit -s
Zmień opisy
- Linia 1: Nagłówek
Podaj jednowierszowe podsumowanie ( maksymalnie 50 znaków )
Ten format jest używany przez Git i Gerrit dla różnych wyświetlaczy. Jest to najważniejsza, najgęstsza część Twojego komunikatu o zatwierdzeniu. Rozważ użycie prefiksów do opisania zmienionego obszaru, a następnie opisu zmiany, którą wprowadziłeś w tym zatwierdzeniu, na przykład tej, która ma
ui
jako prefiks:ui: Removes deprecated widget
- Linia 2: Pusta
Zawsze pozostaw tę linię pustą.
- Linia 3: Ciało
Napisz dłuższy opis, zaczynając od tej linii.
Musi to trwać maksymalnie 72 znaki. Opisz, jaki problem rozwiązuje zmiana i jak. Chociaż jest to opcjonalne podczas wdrażania nowych funkcji, jest to bardzo pomocne dla innych później, jeśli odwołują się do tej zmiany, szczególnie w przypadku debugowania.
Dołącz krótką notatkę o wszelkich założeniach lub podstawowych informacjach, które mogą być ważne, gdy inny współtwórca 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 Twojej wiadomości o zatwierdzeniu.
Oto przykładowy komunikat dotyczący 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.Aby przeczytać blog o dobrych opisach zmian (z przykładami), zobacz How to Write a Git Commit Message autorstwa Chrisa Beamsa.
Przesyłanie do Gerrit
Po zatwierdzeniu zmiany w swojej osobistej historii prześlij ją do Gerrit za pomocą tego polecenia:
repo upload
Jeśli uruchomiłeś wiele gałęzi w tym samym repozytorium, zostaniesz poproszony o wybranie tych do przesłania.
Po pomyślnym przesłaniu Repo udostępnia adres URL nowej strony w Gerrit . Kliknij łącze, które udostępnia Repo, aby wyświetlić swoją poprawkę na serwerze recenzji, dodać komentarze lub poprosić określonych recenzentów o poprawkę.
Prośba o recenzję
Po przesłaniu zmian do Gerrit poprawka musi zostać przejrzana i zatwierdzona przez odpowiednich właścicieli kodu. Znajdź właścicieli kodu w plikach OWNERS
.
Aby znaleźć odpowiednich właścicieli kodu i dodać ich jako recenzentów zmiany, wykonaj następujące kroki.
Wybierz link ZASUGERUJ WŁAŚCICIELI w interfejsie Gerrit, aby zobaczyć listę właścicieli kodu dla plików w twojej łatce.
Rysunek 1. Zasugeruj link właścicieli w Gerrit Dodaj właścicieli kodu z listy jako recenzentów swojej poprawki.
Aby określić stan plików w łatce, sprawdź następujące ikony obok plików w łatce.
- (ikona zaznaczenia): Zatwierdzone przez właściciela kodu
- (ikona z krzyżykiem): niezatwierdzone przez właściciela kodu
- (ikona zegara): Oczekuje na zatwierdzenie przez właściciela kodu

Przesyłanie poprawki zastępczej
Załóżmy, że recenzent spojrzał na twoją łatkę i poprosił o małą modyfikację. Możesz zmienić swoje zatwierdzenie w Git, co skutkuje powstaniem nowej łatki na Gerrit, która ma taki sam identyfikator zmiany jak oryginał.
git add -A
git commit --amend
Kiedy prześlesz poprawioną łatkę, zastąpi ona oryginał zarówno na Gerrit, jak i w Twojej lokalnej historii Git.
Rozwiązywanie konfliktów synchronizacji
Jeśli do drzewa źródłowego zostaną przesłane inne łaty, które są w konflikcie z twoim, zmień bazę łat na nowy 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 zmienić bazę HEAD
na nowy zdalny HEAD
.
Jeśli automatyczna zmiana bazy nie powiedzie się, przeprowadź ręczną zmianę bazy.
repo rebase
Innym narzędziem do radzenia sobie z konfliktem rebase jest git mergetool
. Po pomyślnym scaleniu 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ć poprawkę ze zmienioną bazą.
Po zatwierdzeniu zgłoszenia
Po przejściu zgłoszenia 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 klientów lokalnych.
Dla projektów upstream
Android korzysta z wielu innych projektów open source, takich jak jądro Linux i WebKit, zgodnie z opisem w Android Software Management . W przypadku większości projektów, które znajdują się w external/
, wprowadź zmiany na zewnątrz, a następnie poinformuj opiekunów systemu Android o nowej wersji nadrzędnej zawierającej zmiany.
Możesz także przesłać łatki, które powodują śledzenie nowej wersji nadrzędnej. Pamiętaj, że mogą to być trudne zmiany, jeśli projekt jest powszechnie używany w systemie Android, tak jak większość większych wymienionych poniżej, które są zwykle aktualizowane przy każdym wydaniu.
Ciekawym przypadkiem specjalnym jest Bionic. Większość kodu pochodzi z BSD, więc o ile zmiana nie dotyczy kodu, który jest nowy w Bionic, prosimy o wprowadzenie poprawki, a następnie ściągnięcie całego nowego pliku z odpowiedniego BSD.
Jądro Androida
Wolę dokonywać wszystkich zmian wcześniej. Aby uzyskać ogólne wskazówki, postępuj zgodnie z wytycznymi dotyczącymi wkładu jądra systemu Android .
OIOM
Wprowadź wszystkie zmiany w projekcie ICU w external/icu
( icu4c/
i icu4j/
) na stronie głównej ICU-TC . Zobacz Zgłaszanie błędów ICU i prośby o nowe funkcje, aby uzyskać więcej informacji.
CLDR
Większość danych językowych w ICU pochodzi z projektu Unicode CLDR . Prześlij wszystkie prośby w górę, korzystając z prośby o zmianę 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
Dokonaj wszystkich zmian w projekcie MirBSD Korn Shell w external/mksh
albo wysyłając e-mail do miros-mksh
w domenie mirbsd.org
(do przesłania tam nie jest wymagana subskrypcja) lub na Launchpad .
OpenSSL
Wprowadź wszystkie zmiany w projekcie OpenSSL w external/openssl
na stronie OpenSSL .
V8
Prześlij wszystkie zmiany w projekcie V8 na stronie external/v8
na stronie wydania V8 . Zobacz Wkład w V8, aby uzyskać szczegółowe informacje.
WebKit
Wprowadź wszystkie zmiany w projekcie WebKit w external/webkit
na stronie WebKit . Rozpocznij proces, zgłaszając błąd WebKit . W przypadku błędu użyj Android
w polach Platforma i OS tylko wtedy, gdy błąd dotyczy tylko Androida. Błędy znacznie częściej zwracają uwagę recenzentów po dodaniu proponowanej poprawki i włączeniu testów. Aby uzyskać szczegółowe informacje, zobacz Współtworzenie kodu do oprogramowania WebKit .
zlib
Dokonaj wszystkich zmian w projekcie zlib w external/zlib
na stronie głównej zlib .