Esta página descreve o processo completo de envio de um patch para o Android Open Source Project (AOSP), incluindo como solicitar uma revisão e monitorar as mudanças com o Gerrit.
Pré-requisitos
Para começar, é necessário fazer o seguinte:
- Inicializar seu ambiente de build
- Fazer o download da origem
- Criar uma senha usando o gerador de senhas
Recursos
- Para detalhes sobre o Repo e o Git, consulte a página Ferramentas de controle de origem.
- Para ver informações sobre diferentes papéis na comunidade do Android Open Source, consulte a página Papéis do projeto.
- Para ver informações de licenciamento sobre contribuições de código para a Plataforma Android, consulte a página Licenças.
Para colaboradores
Como autenticar com o servidor
Se você compartilhar um endereço IP com outros usuários, as cotas poderão ser acionadas até mesmo para padrões de uso regulares. Isso pode acontecer quando, por exemplo, muitos usuários sincronizam novos clientes do mesmo endereço IP em um curto período. O acesso autenticado usa uma cota separada para cada usuário, independentemente do endereço IP. Para ver como ativar o acesso autenticado, consulte Como usar a autenticação.
Como iniciar uma ramificação do Repo
Para cada mudança que você pretende fazer, inicie uma nova ramificação dentro do repositório Git relevante:
repo start NAME .
É possível iniciar várias ramificações independentes ao mesmo tempo e no mesmo
repositório. O NAME
da ramificação é local em relação ao seu espaço de trabalho
e não é incluído no Gerrit ou na árvore de origem final.
Como fazer a mudança
Modifique os arquivos de origem e valide as mudanças.
Confirme as mudanças no repositório local com estes comandos:
git add -A
git commit -s
Descrições das mudanças
-
Linha 1: título
Forneça um resumo de uma linha (máximo de 50 caracteres)
Esse formato é usado pelo Git e Gerrit para várias exibições. É a parte mais importante e mais densa da mensagem de confirmação. Recomendamos o uso de prefixos para descrever a área que você mudou, seguidos por uma descrição da mudança feita nessa confirmação. Por exemplo, esta que tem
ui
como prefixo:ui: Removes deprecated widget
- Linha 2: espaço em branco
Sempre mantenha essa linha em branco.
- Linha 3: corpo
Escreva uma descrição mais longa, começando nessa linha.
O limite máximo é de 72 caracteres. Descreva o problema que a mudança resolve e como ela o resolve. Isso é opcional ao implementar novos recursos, mas é muito útil para outras pessoas posteriormente caso elas consultem essa mudança, especialmente para depuração.
Inclua uma breve observação das suposições ou informações contextuais que possam ser importantes quando outro colaborador trabalhar nesse recurso.
Um código de mudança exclusivo e seu nome e e-mail, que foram fornecidos durante a repo
init
(inicialização do Repo), são automaticamente adicionados à sua mensagem de confirmação.
Veja um exemplo de mensagem de confirmação:
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.Para saber mais sobre boas descrições de confirmação (com exemplos), consulte a postagem de blog Como escrever uma mensagem de confirmação do Git (link em inglês) de Chris Beams.
Como fazer upload para o Gerrit
Depois de confirmar a mudança do seu histórico pessoal, faça upload dela para o Gerrit com este comando:
repo upload
Se você tiver iniciado várias ramificações no mesmo repositório, você precisará selecionar quais serão enviadas por upload.
Após a conclusão do upload, o Repo fornecerá o URL de uma nova página no Gerrit. Clique no link que o Repo fornece para ver o patch no servidor de revisão, adicionar comentários ou solicitar revisores específicos para seu patch.
Como solicitar uma revisão
Depois que você fizer upload das mudanças para o Gerrit, o patch precisará ser revisado
e aprovado pelos proprietários de código adequados. Localize os proprietários de código nos
arquivos
OWNERS
.
Para encontrar os proprietários de código e adicioná-los como revisores da sua mudança, siga estas etapas.
Selecione o link SUGGEST OWNERS na IU do Gerrit para ver uma lista dos proprietários de código dos arquivos no seu patch.
Figura 1. Link "Suggest owners" no Gerrit. Adicione proprietários de código da lista como revisores para seu patch.
Para determinar o status dos arquivos no patch, consulte os seguintes ícones ao lado deles.
- (ícone de verificação): aprovado pelo proprietário do código
- (ícone de X): não aprovado pelo proprietário do código
- (ícone de relógio): aprovação pendente

Como fazer upload de um patch substituto
Suponha que um revisor analisou seu patch e solicitou uma pequena modificação. Você pode mudar sua confirmação no Git, o que resultará em um novo patch no Gerrit com o mesmo código de mudança que o original.
git add -A
git commit --amend
Quando você fizer upload do patch modificado, ele substituirá o original no Gerrit e no histórico do Git local.
Como resolver conflitos de sincronização
Se outros patches forem enviados à árvore de origem e entrarem em conflito com
o seu, realoque seu patch sobre o novo HEAD
do
repositório de origem. Para fazer isso, execute este comando:
repo sync
O comando repo sync
busca as atualizações do servidor de origem e, em seguida,
tenta realocar seu HEAD
automaticamente no novo HEAD
remoto.
Se a realocação automática não for bem-sucedida, faça uma manual.
repo rebase
Outra ferramenta para lidar com o conflito de realocação é a git mergetool
.
Após mesclar os arquivos conflitantes, execute este comando:
git rebase --continue
Depois que a realocação automática ou manual for concluída, execute repo
upload
para enviar o patch realocado.
Após a aprovação de um envio
Depois que um envio passa pelo processo de revisão e verificação,
o Gerrit mescla automaticamente a mudança no repositório público. Outros
usuários podem executar repo sync
para transferir a atualização para
os respectivos clientes locais.
Para projetos ascendentes
O Android usa diversos outros projetos de código aberto, como o
kernel do Linux e o WebKit, conforme descrito em
Gerenciamento de software Android.
Para a maioria dos projetos que residem em external/
, as mudanças
precisam ser feitas de forma ascendente e, em seguida, os mantenedores do Android precisam ser informados sobre a
nova versão ascendente que contém as mudanças.
Também é possível fazer upload de patches que causam o rastreamento de uma nova versão ascendente. Observe que pode ser difícil fazer essas mudanças se o projeto for amplamente usado no Android, como é o caso da maioria das grandes modificações mencionadas abaixo, que geralmente têm upgrade a cada versão.
Um caso especial interessante é o Bionic. Grande parte do código dele vem do BSD. Por esse motivo, a menos que a mudança seja realizada no código que é novo no Bionic, você precisa fazer uma correção ascendente e depois extrair um novo arquivo completo do BSD adequado.
Kernel do Android
Faça todas as mudanças de forma ascendente. Para ver orientações gerais, siga as Diretrizes de contribuição do kernel do Android.
ICU
Faça todas as mudanças no projeto ICU em external/icu
(pastas icu4c/
e icu4j/
)
na página inicial do ICU-TC.
Consulte Como enviar solicitações de recursos e
bugs de ICU (links em inglês) para ver mais informações.
CLDR
A maioria dos dados linguísticos em ICU vem do projeto Unicode CLDR. Envie todas as solicitações upstream usando as Solicitações de mudança de CLDR (links em inglês) e adicione o rótulo "Android".
LLVM/Clang/Compiler-rt
Faça todas as mudanças em projetos relacionados a LLVM (external/clang
,
external/compiler-rt
, external/llvm
) na
página LLVM Compiler Infrastructure (link em inglês).
mksh
Faça todas as mudanças no projeto MirBSD Korn Shell em external/mksh
enviando um e-mail para miros-mksh
no domínio mirbsd.org
(não
é necessário ter uma assinatura para realizar o envio) ou no Launchpad (link em inglês).
OpenSSL
Faça todas as mudanças no projeto OpenSSL em external/openssl
na
página OpenSSL (link em inglês).
V8
Envie todas as mudanças no projeto V8 em external/v8
usando a
página de problemas do V8 (link em inglês).
Consulte Como contribuir para o V8 para ver mais detalhes (link em inglês).
WebKit
Faça todas as mudanças no projeto WebKit em external/webkit
na página WebKit. Inicie o processo registrando um bug do WebKit.
No bug, só use Android
para os campos Plataforma e SO se o bug for específico para Android. Incluir uma proposta de correção e os testes realizados aumenta as chances do bug ser analisado pelos revisores. Consulte Como contribuir com código para o WebKit para ver mais detalhes (links todos em inglês).
zlib
Faça todas as mudanças no projeto zlib em external/zlib
na
página inicial do zlib.