Esta página descreve o processo completo de envio de um patch para o Android Open Source Project (AOSP), incluindo como pedir uma revisão e monitorar as mudanças com o Gerrit. O Gerrit é um sistema de análise de código baseado na Web para projetos que usam o Git. O Gerrit incentiva o uso mais centralizado do Git, permitindo que todos os usuários autorizados enviem mudanças, que são automaticamente fundidas se forem aprovadas na análise do código. Além disso, o Gerrit facilita a análise, mostrando as mudanças lado a lado no navegador e permitindo comentários in-line.
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
- Assinar os contratos de licença de colaborador
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.
Configurar o Git
Para usar o Gerrit, seu e-mail precisa estar associado a uma Conta do Google. Execute os comandos abaixo para configurar o Git com um nome e endereço de e-mail associados a uma Conta do Google:
git config --global user.name Your Name
git config --global user.email your_email@gmail.com
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.
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 .
You can start several independent branches at the same time in the same
repository. The branch NAME
is local to your
workspace and isn't included either on Gerrit or in the final source tree.
Make your change
Modify the source files, and test your changes.
For any changes made, follow License header best practices.
Commit your change
Commit the changes to your local repository with these commands:
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.To read a blog about good commit descriptions (with examples), see How to Write a Git Commit Message by Chris Beams.
Upload to Gerrit
After you commit your change to your personal history, upload it to Gerrit with this command:
repo upload
If you started multiple branches in the same repository, you're prompted to select which ones to upload.
After a successful upload, Repo provides you with the URL of a new page on Gerrit. Click the link that Repo gives you to view your patch on the review server, add comments, or request specific reviewers for your patch.
Request a review
After you've uploaded your changes to Gerrit, the patch must be reviewed
and approved by the appropriate code owners. Locate code owners in
OWNERS
files.
To find the appropriate code owners and add them as reviewers for your change, follow these steps.
-
Select the SUGGEST OWNERS link in the Gerrit UI to see a list of code owners for the files in your patch.
Add code owners from the list as reviewers for your patch.
To determine the status of the files in your patch, check for the following icons next to the files in the patch.
- (checkmark icon): Approved by code owner
- (cross icon): Not approved by code owner
- (clock icon): Pending approval by code owner
Upload a replacement patch
Suppose a reviewer looked at your patch and requested a small modification. You can amend your commit within Git, which results in a new patch on Gerrit that has the same change ID as the 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.
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 saber mais. 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).