Ta strona opisuje pełny proces przesyłania poprawki do Android Open Source Project (AOSP), w tym jak poprosić o sprawdzenie i śledzić zmiany za pomocą Gerrita .
Wymagania wstępne
Aby rozpocząć, upewnij się, że wykonałeś następujące czynności:
- Zainicjowano środowisko kompilacji
- Pobrano źródło
- Utworzono hasło za pomocą generatora haseł.
Zasoby
- Aby uzyskać szczegółowe informacje na temat repozytorium i usługi 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 w projekcie .
- Aby uzyskać informacje na temat licencjonowania dotyczącego udostępniania kodu na platformę Android, zobacz stronę Licencje .
Dla współtwórców
Uwierzytelnianie z serwerem
Jeśli udostępniasz 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 okresie czasu. Uwierzytelniony dostęp wykorzystuje oddzielny limit dla każdego użytkownika, niezależnie od adresu IP. Aby przeczytać o aktywowaniu uwierzytelnionego dostępu, zobacz Korzystanie z uwierzytelniania .
Uruchomienie oddziału Repo
Dla każdej zmiany, którą zamierzasz wprowadzić, uruchom 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 uwzględniona ani w Gerrit, ani w ostatecznym drzewie źródłowym.
Dokonywanie zmiany
Zmodyfikuj pliki źródłowe i zatwierdź 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 do różnych wyświetlaczy. To najważniejsza, najgęstsza część wiadomości dotyczącej zatwierdzenia. Rozważ użycie przedrostków do opisania zmienionego obszaru, a następnie opisu zmiany wprowadzonej w tym zatwierdzeniu, takiej jak ta, która ma przedrostek
ui
:ui: Removes deprecated widget
- Linia 2: pusta
Pozostaw tę linię pustą, zawsze.
- Linia 3: Ciało
Napisz dłuższy opis, zaczynając od tego wiersza.
To musi mieć maksymalnie 72 znaki. Opisz, jaki problem rozwiązuje zmiana i w jaki sposób. 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 ogólnych informacjach, które mogą być ważne, gdy inny współpracownik 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ładowa wiadomość 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 zatwierdzeń (z przykładami), zobacz How to Write a Git Commit Message autorstwa Chrisa Beamsa.
Przesyłanie do Gerrita
Po zatwierdzeniu zmiany w historii osobistej prześlij ją do Gerrit za pomocą tego polecenia:
repo upload
Jeśli uruchomiłeś wiele oddziałów w tym samym repozytorium, zostaniesz poproszony o wybranie, które z nich chcesz przesłać.
Po pomyślnym przesłaniu Repo udostępnia adres URL nowej strony na Gerrit . Kliknij link, który udostępnia Repo, aby wyświetlić poprawkę na serwerze recenzji, dodać komentarze lub poprosić o konkretnych recenzentów Twojej łatki.
Prośba o recenzję
Po przesłaniu zmian do Gerrit poprawka musi zostać sprawdzona 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 SUGGEST OWNERS w interfejsie użytkownika Gerrit, aby zobaczyć listę właścicieli kodu dla plików w Twojej łatce.
Rysunek 1. Link Sugeruj 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 znacznika wyboru): Zatwierdzone przez właściciela kodu
- (ikona krzyżyka): niezatwierdzone przez właściciela kodu
- (ikona zegara): oczekuje na zatwierdzenie przez właściciela kodu

Przesyłanie zastępczej poprawki
Załóżmy, że recenzent spojrzał na twoją poprawkę i poprosił o niewielką modyfikację. Możesz zmienić swoje zatwierdzenie w Git, co skutkuje nową łatką na Gerrit, która ma ten sam identyfikator zmiany, co oryginał.
git add -A
git commit --amend
Gdy prześlesz poprawioną poprawkę, zastępuje ona oryginał zarówno w Gerrit, jak iw lokalnej historii Git.
Rozwiązywanie konfliktów synchronizacji
Jeśli inne łatki są przesłane do drzewa źródłowego, które kolidują z twoim, zmień bazę łatki 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 nową zdalną 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 rebase uruchom repo upload
, aby przesłać poprawkę rebase.
Po zatwierdzeniu zgłoszenia
Po tym, jak zgłoszenie przejdzie przez proces recenzji 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 upstream
Android korzysta z wielu innych projektów open source, takich jak jądro Linuksa i WebKit, jak opisano w Android Software Management . W przypadku większości projektów, które znajdują się w katalogu external/
, wprowadź zmiany w górę, a następnie poinformuj opiekunów Androida o nowej wersji, która zawiera zmiany.
Możesz także przesyłać poprawki, które powodują śledzenie nowej wersji. Pamiętaj, że wprowadzenie tych zmian może być trudne, jeśli projekt jest szeroko stosowany w systemie Android, jak większość większych wymienionych poniżej, które zwykle są aktualizowane z każdą wersją.
Ciekawym przypadkiem specjalnym jest Bionic. Znaczna część kodu pochodzi z BSD, więc jeśli zmiana nie dotyczy kodu, który jest nowy w Bionic, proszę wprowadzić poprawkę, a następnie pobrać cały nowy plik z odpowiedniego BSD.
Jądro Androida
Wprowadź wszystkie zmiany na górze. Aby uzyskać ogólne wskazówki, postępuj zgodnie z wytycznymi dotyczącymi wkładu jądra systemu Android i stroną Tworzenie kodu jądra dla GKI .
OIOM
Wprowadź wszystkie zmiany w projekcie ICU w katalogu external/icu
(foldery icu4c/
i icu4j/
) na stronie głównej ICU-TC . Zobacz Przesyłanie błędów ICU i wniosków o nowe funkcje, aby uzyskać więcej informacji.
CLDR
Większość danych lingwistycznych w ICU pochodzi z projektu Unicode CLDR . Prześlij wszystkie prośby wcześniej, korzystając z żądań zmiany 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 Infrastruktura kompilatora LLVM .
mksz
Dokonaj wszystkich zmian w projekcie MirBSD Korn Shell na external/mksh
, wysyłając wiadomość e-mail do miros-mksh
w domenie mirbsd.org
(nie jest wymagana subskrypcja do przesłania tam) lub na Launchpad .
OpenSSL
Wprowadź wszystkie zmiany w projekcie OpenSSL pod 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 Przyczynianie się do V8 .
WebKit
Wprowadź wszystkie zmiany w projekcie WebKit pod external/webkit
na stronie WebKit . Rozpocznij proces, zgłaszając błąd WebKit . W błędzie użyj Android
dla pól Platforma i OS tylko wtedy, gdy błąd jest specyficzny dla Androida. Błędy znacznie częściej zwracają uwagę recenzentów po dodaniu proponowanej poprawki i dołączeniu testów. Zobacz Przekazywanie kodu do WebKit, aby uzyskać szczegółowe informacje.
zlib
Wprowadź wszystkie zmiany w projekcie zlib w pliku external/zlib
na stronie głównej zlib .