Como enviar patches

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.

1. Selecione o link SUGGEST OWNERS na interface do Gerrit para conferir uma lista dos proprietários de código dos arquivos no seu patch.

   

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

• done (ícone de marca de verificação): aprovado pelo proprietário do código.
• clear (ícone de X): não aprovado pelo proprietário do código.
• access_time (í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).