Enviar patches

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.

Observação: para mudar projetos upstream usados pelo Android, talvez seja necessário fazer isso diretamente no projeto. Consulte Projetos upstream.

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 [e-mail]
    

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

Sempre forneça uma descrição detalhada da mudança a cada confirmação. Siga as orientações e o formato fornecidos nas Descrições das mudanças. Isso é muito importante, já que a descrição da mudança é enviada ao repositório AOSP público. Siga estas orientações ao enviar patches ou confirmar mudanças para um novo recurso.

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.

1. Select the SUGGEST OWNERS link in the Gerrit UI to see a list of code owners for the files in your patch.

   

   Figure 1. Suggest owners link in Gerrit

2. 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

Figure 2. Example of files with icons showing code owner approval status

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.

Note: If you made other commits since uploading this patch, you must manually move your Git HEAD.

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).