Google is committed to advancing racial equity for Black communities. See how.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Invio di patch

Questa pagina descrive l'intero processo di invio di una patch all'Android Open Source Project (AOSP), inclusa la revisione e il monitoraggio delle modifiche con Gerrit .

Prerequisiti

Per i collaboratori

Autenticazione con il server

Prima di poter caricare su Gerrit, è necessario stabilire una password che ti identifichi con il server. Segui le istruzioni nella pagina del generatore di password. Devi farlo solo una volta. Vedere Utilizzo dell'autenticazione per ulteriori dettagli.

Avvio di un ramo Repo

Per ogni modifica che intendi apportare, avvia un nuovo ramo all'interno del repository Git pertinente:

repo start NAME .

È possibile avviare più rami indipendenti contemporaneamente nello stesso repository. Il ramo NAME è locale nel tuo spazio di lavoro e non è incluso in Gerrit o nell'albero dei sorgenti finale.

Apporta il tuo cambiamento

Dopo aver modificato i file di origine (e convalidati, per favore) salva le modifiche nel tuo repository locale:

git add -A
git commit -s

Fornisci una descrizione dettagliata della modifica nel messaggio di commit. Questa descrizione viene inviata al repository AOSP pubblico, quindi segui queste linee guida per scrivere le descrizioni degli elenchi di modifiche:

  • Inizia con un riepilogo di una riga (massimo 50 caratteri), seguito da una riga vuota. Questo formato è utilizzato da Git e Gerrit per vari display.

  • A partire dalla terza riga, inserisci una descrizione più lunga, che deve contenere un massimo di 72 caratteri. Descrivi quale problema risolve il cambiamento e come lo risolve. La seconda parte è in qualche modo facoltativa quando si implementano nuove funzionalità, sebbene desiderabile.

  • Includere una breve nota di eventuali presupposti o informazioni di base che potrebbero essere importanti quando un altro collaboratore lavora su questa funzione.

Ecco un esempio di messaggio di commit:

Short description on first line

More detailed description of your patch,
which is likely to take up multiple lines.

Al messaggio di commit vengono aggiunti automaticamente un ID di modifica univoco, il nome e l'indirizzo e-mail forniti durante l' repo init .

Caricamento su Gerrit

Dopo aver confermato la modifica alla tua cronologia personale, caricala su Gerrit con

repo upload

Se hai avviato più rami nello stesso repository, ti viene chiesto di selezionare quelli da caricare.

Dopo un caricamento riuscito, Repo ti fornisce l'URL di una nuova pagina su Gerrit . Visitare questo collegamento per visualizzare la patch sul server di revisione, aggiungere commenti o richiedere revisori specifici per la patch.

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 con lo stesso ID di modifica dell'originale.

git add -A
git commit --amend

Quando carichi la patch modificata, sostituisce l'originale su Gerrit e nella cronologia Git locale.

Risoluzione dei conflitti di sincronizzazione

Se vengono inviate altre patch all'albero dei sorgenti che sono in conflitto con il tuo, devi ribase la tua patch sopra il nuovo HEAD del repository dei sorgenti. Il modo più semplice per farlo è correre

repo sync

Questo comando recupera prima gli aggiornamenti dal server di origine, quindi tenta di ricondizionare automaticamente la tua HEAD sulla nuova HEAD remota.

Se il rebase automatico non riesce, eseguire un rebase manuale.

repo rebase

L'uso di git mergetool può aiutarti ad affrontare il conflitto di rebase. Quando hai unito con successo i file in conflitto, esegui:

git rebase --continue

Dopo aver completato il rebase automatico o manuale, eseguire il repo upload per inviare la patch rebase.

Dopo l'approvazione di una presentazione

Dopo che un invio ha superato il processo di revisione e verifica, Gerrit unisce automaticamente la modifica al repository pubblico. Altri utenti possono eseguire la repo sync per trasferire l'aggiornamento nel proprio client locale.

Progetti a monte

Android fa uso di una serie di altri progetti open source, come il kernel Linux e WebKit, come descritto in Gestione del software Android . Per la maggior parte dei progetti in external/ , apportare le modifiche a monte e quindi informare i manutentori di Android della nuova versione a monte contenente queste modifiche. Potrebbe anche essere utile caricare patch che ci spingano a tenere traccia di una nuova versione upstream, sebbene queste possano 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, dove tendiamo ad aggiornare ad ogni pubblicazione.

Un caso speciale interessante è Bionic. Gran parte del codice proviene da BSD, quindi a meno che la modifica non sia in codice nuovo per Bionic, preferiremmo una correzione a monte e quindi un pull di un file completamente nuovo dal BSD appropriato.

ICU4C

Apportare tutte le modifiche al progetto ICU4C in external/icu4c nella home page di ICU-TC . Vedere Invio di bug di ICU e richieste di funzionalità per ulteriori informazioni.

LLVM / Clang / Compiler-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 miros-mksh mail a miros-mksh sul dominio mirbsd.org (non è richiesto alcun abbonamento per mirbsd.org lì) o su Launchpad .

OpenSSL

Apporta tutte le modifiche al progetto OpenSSL su external/openssl nella pagina OpenSSL .

V8

Invia tutte le modifiche al progetto V8 su external/v8 nella pagina del problema V8 . Vedere Contribuire alla V8 per i dettagli.

WebKit

Apporta tutte le modifiche al progetto WebKit su external/webkit nella pagina WebKit . Avvia il processo segnalando un bug WebKit . Nel bug, utilizza Android per i campi Piattaforma e OS solo se il bug è specifico per Android. È molto più probabile che i bug ricevano l'attenzione dei revisori dopo che una correzione proposta è stata aggiunta e sono stati inclusi i test. Vedere Contributo del codice a WebKit per i dettagli.

zlib

Apporta tutte le modifiche al progetto zlib in external/zlib nella home page di zlib .