Questa pagina descrive l'intero processo di invio di una patch all'Android Open Source Project (AOSP), incluso come richiedere una revisione e tenere traccia delle modifiche con Gerrit .
Prerequisiti
Per iniziare, assicurati di aver eseguito quanto segue:
- Inizializzato il tuo ambiente di compilazione
- Scaricato il sorgente
- Creata una password utilizzando il generatore di password.
Risorse
- Per informazioni dettagliate su Repo e Git, vedere la pagina degli strumenti di controllo del codice sorgente .
- Per informazioni sui diversi ruoli all'interno della community Android Open Source, vedere la pagina Ruoli del progetto .
- Per informazioni sulle licenze relative al contributo del codice alla piattaforma Android, vedere la pagina Licenze .
Per i contributori
Autenticazione con il server
Se condividi un indirizzo IP con altri utenti, le quote possono essere attivate anche per schemi di utilizzo regolari. Ciò può accadere quando, ad esempio, molti utenti sincronizzano nuovi client dallo stesso indirizzo IP in un breve periodo di tempo. L'accesso autenticato utilizza una quota separata per ciascun utente, indipendentemente dall'indirizzo IP. Per informazioni sull'attivazione dell'accesso autenticato, vedere Utilizzo dell'autenticazione .
Avvio di un ramo Repo
Per ogni modifica che intendi apportare, avvia un nuovo ramo all'interno del relativo repository Git:
repo start NAME .
Puoi avviare diversi rami indipendenti contemporaneamente nello stesso repository. Il ramo NAME
è locale nel tuo spazio di lavoro e non è incluso né su Gerrit né nell'albero dei sorgenti finale.
Fai il tuo cambiamento
Modifica i file di origine e convalida le modifiche.
Applica le modifiche al tuo repository locale con questi comandi:
git add -A
git commit -s
Cambia le descrizioni
- Riga 1: Titolo
Fornire un riepilogo di una riga ( massimo 50 caratteri)
Questo formato è utilizzato da Git e Gerrit per vari display. È la parte più importante e più densa del tuo messaggio di commit. Prendi in considerazione l'utilizzo di prefissi per descrivere l'area che hai modificato, seguito da una descrizione della modifica che hai apportato in questo commit, come questo che ha
ui
come prefisso:ui: Removes deprecated widget
- Riga 2: Vuoto
Mantieni questa riga vuota, sempre.
- Riga 3: Corpo
Scrivi una descrizione più lunga, iniziando da questa riga.
Questo deve eseguire il wrapping rigido a un massimo di 72 caratteri. Descrivi quale problema risolve il cambiamento e come. Sebbene questo sia facoltativo quando si implementano nuove funzionalità, è molto utile per gli altri in seguito se fanno riferimento a questa modifica, in particolare per il debug.
Includi una breve nota di eventuali presupposti o informazioni di base che potrebbero essere importanti quando un altro collaboratore lavora su questa funzionalità.
Un ID di modifica univoco e il tuo nome e indirizzo email, che vengono forniti durante repo init
, vengono aggiunti automaticamente al tuo messaggio di commit.
Ecco un esempio di messaggio di commit:
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.Per leggere un blog sulle buone descrizioni di commit (con esempi), vedere How to Write a Git Commit Message di Chris Beams.
Caricamento su Gerrit
Dopo aver eseguito il commit della modifica alla tua cronologia personale, caricala su Gerrit con questo comando:
repo upload
Se hai avviato più rami nello stesso repository, ti verrà chiesto di selezionare quali caricare.
Dopo un caricamento riuscito, Repo ti fornisce l'URL di una nuova pagina su Gerrit . Fare clic sul collegamento fornito da Repo per visualizzare la patch sul server di revisione, aggiungere commenti o richiedere revisori specifici per la patch.
Richiesta di revisione
Dopo aver caricato le modifiche in Gerrit, la patch deve essere esaminata e approvata dai proprietari del codice appropriati. Individua i proprietari del codice nei file OWNERS
.
Per trovare i proprietari del codice appropriati e aggiungerli come revisori per la modifica, procedi nel seguente modo.
Selezionare il collegamento SUGGERIMENTO PROPRIETARI nell'interfaccia utente di Gerrit per visualizzare un elenco dei proprietari del codice per i file nella patch.
Figura 1. Suggerisci collegamento proprietari in Gerrit Aggiungi i proprietari del codice dall'elenco come revisori per la tua patch.
Per determinare lo stato dei file nella patch, controlla le seguenti icone accanto ai file nella patch.
- (icona segno di spunta): approvato dal proprietario del codice
- (icona a forma di croce): non approvato dal proprietario del codice
- (icona dell'orologio): In attesa di approvazione da parte del proprietario del codice

Caricamento di una patch sostitutiva
Supponiamo che un revisore abbia esaminato la tua patch e abbia richiesto una piccola modifica. Puoi modificare il tuo commit all'interno di Git, il che si traduce in una nuova patch su Gerrit che ha lo stesso ID di modifica dell'originale.
git add -A
git commit --amend
Quando carichi la patch modificata, questa sostituisce l'originale sia su Gerrit che nella tua cronologia Git locale.
Risoluzione dei conflitti di sincronizzazione
Se all'albero dei sorgenti vengono inviate altre patch che sono in conflitto con le tue, rebase la tua patch sopra il nuovo HEAD
del repository dei sorgenti. Per fare ciò, esegui questo comando:
repo sync
Il comando repo sync
recupera gli aggiornamenti dal server di origine, quindi tenta di ribasare automaticamente il tuo HEAD
sul nuovo HEAD
remoto.
Se il rebase automatico non riesce, eseguire un rebase manuale.
repo rebase
Un altro strumento per gestire il conflitto di rebase è git mergetool
. Dopo aver unito correttamente i file in conflitto, esegui questo comando:
git rebase --continue
Al termine del rebase automatico o manuale, eseguire repo upload
per inviare la patch rebase.
Dopo che una presentazione è stata approvata
Dopo che un invio ha superato il processo di revisione e verifica, Gerrit unisce automaticamente la modifica nel repository pubblico. Altri utenti possono eseguire repo sync
per eseguire il pull dell'aggiornamento nei rispettivi client locali.
Per progetti a monte
Android fa uso di una serie di altri progetti open source, come il kernel Linux e WebKit, come descritto in Android Software Management . Per la maggior parte dei progetti che risiedono in external/
, apportare le modifiche a monte, quindi informare i manutentori di Android della nuova versione a monte che contiene le modifiche.
Potresti anche caricare patch che fanno sì che una nuova versione upstream venga tracciata. Tieni presente che queste possono essere modifiche difficili da apportare se il progetto è ampiamente utilizzato all'interno di Android, come la maggior parte di quelli più grandi menzionati di seguito, che di solito vengono aggiornati ad ogni versione.
Un caso speciale interessante è Bionic. Gran parte del codice proviene da BSD, quindi, a meno che la modifica non riguardi un codice nuovo per Bionic, apporta una correzione a monte, quindi un pull di un file completamente nuovo dal BSD appropriato.
Kernel Android
Apporta tutte le modifiche a monte. Per indicazioni generali, segui le linee guida per il contributo del kernel Android e la pagina Sviluppo del codice del kernel per GKI .
terapia intensiva
Apportare tutte le modifiche al progetto ICU in external/icu
(cartelle icu4c/
e icu4j/
) nella home page ICU-TC . Vedere Invio di bug in terapia intensiva e richieste di funzionalità per ulteriori informazioni.
CLDR
La maggior parte dei dati linguistici in terapia intensiva proviene dal progetto Unicode CLDR . Invia tutte le richieste a monte utilizzando le richieste di modifica CLDR e aggiungi l'etichetta "Android".
LLVM/Clang/Compilatore-rt
Apporta tutte le modifiche ai progetti relativi a LLVM ( external/clang
, external/compiler-rt
, external/llvm
) nella pagina LLVM Compiler Infrastructure .
mksh
Apporta tutte le modifiche al progetto MirBSD Korn Shell su external/mksh
inviando un'e-mail a miros-mksh
sul dominio mirbsd.org
(non è richiesto alcun abbonamento per inviare lì) o su Launchpad .
OpenSSL
Apporta tutte le modifiche al progetto OpenSSL in external/openssl
nella pagina OpenSSL .
V8
Invia tutte le modifiche al progetto V8 su external/v8
nella pagina del problema V8 . Vedere Contribuire a V8 per i dettagli.
WebKit
Apporta tutte le modifiche al progetto WebKit in external/webkit
nella pagina WebKit . Avviare il processo segnalando un bug di WebKit . Nel bug, usa Android
per i campi Platform e OS solo se il bug è specifico di Android. È molto più probabile che i bug ricevano l'attenzione dei revisori dopo che è stata aggiunta una correzione proposta e sono stati inclusi i test. Vedere Contributo del codice a WebKit per i dettagli.
zlib
Apporta tutte le modifiche al progetto zlib su external/zlib
nella home page di zlib .