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 conferir informações sobre diferentes papéis na comunidade do Android Open Source, consulte a página Funções do projeto.
- Para conferir 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 normais. 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, independente do endereço IP. Para conferir 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 caso elas consultem essa mudança no futuro, especialmente para depuração.
Inclua uma breve explicaçã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.
Confira 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, 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 conferir o patch no servidor de revisão, adicionar comentários ou solicitar revisores específicos para seu patch.
Como solicitar uma análise
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
(link em inglês).
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 interface do Gerrit para conferir 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 estes ícones ao lado deles.
- (ícone de marca 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 upstream
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 upstream. Em seguida, os mantenedores do Android precisam ser informados sobre a nova versão upstream
que contém as mudanças.
Também é possível fazer upload de patches que causam o rastreamento de uma nova versão upstream. 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 upstream e depois extrair um novo arquivo completo do BSD adequado.
Kernel do Android
Faça todas as mudanças upstream. Para conferir orientações gerais, siga as Diretrizes de contribuição do kernel do Android e a página Desenvolver código do kernel para GKI.
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 mais informações. Adicione o rótulo "Android" a todas as solicitações upstream do Jira.
CLDR
A maioria dos dados linguísticos em ICU vem do projeto Unicode CLDR. Envie todas as solicitações upstream de acordo com a página Como contribuir para o 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 para external/v8
usando a
página de problemas do V8. Consulte
Como contribuir para o V8
para mais detalhes (links 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 mais detalhes (links em inglês).
zlib
Faça todas as mudanças no projeto zlib em external/zlib
na
página inicial do zlib (link em inglês).