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 acompanhar suas alterações com Gerrit . Gerrit é um sistema de revisão de código baseado na web para projetos que usam Git. Gerrit incentiva um uso mais centralizado do Git, permitindo que todos os usuários autorizados enviem alterações, que serão automaticamente mescladas se passarem na revisão do código. Além disso, Gerrit facilita a revisão, exibindo as alterações lado a lado no navegador e permitindo comentários embutidos.

Pré-requisitos

Para começar, certifique-se de ter feito o seguinte:

• Inicializou seu ambiente de construção
• Baixei a fonte
• Criou uma senha usando o gerador de senha.
• Assine os contratos de licença de contribuidor

Recursos

• Para obter detalhes sobre Repo e Git, consulte a página Ferramentas de controle de origem .
• Para obter informações sobre diferentes funções na comunidade Android Open Source, consulte a página Funções do projeto .
• Para obter informações de licenciamento sobre como contribuir com código para a plataforma Android, consulte a página Licenças .

Observação: para fazer alterações em projetos upstream usados ​​pelo Android, talvez seja necessário fazê-las diretamente nesse projeto. Consulte Projetos upstream .

Configurar o Git

Para usar o Gerrit, seu e-mail deve estar associado a uma Conta do Google registrada. Execute os seguintes comandos para configurar o Git com um nome e endereço de e-mail associados a uma Conta do Google registrada:

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 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 de tempo. O acesso autenticado utiliza uma cota separada para cada usuário, independentemente do endereço IP. Para ler sobre como ativar o acesso autenticado, consulte Usando autenticação .

Inicie uma ramificação Repo

Para cada alteração que você pretende fazer, inicie uma nova ramificação no 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 com cada commit. Siga o formato e as diretrizes fornecidas em Descrições de alterações . Isto é muito importante; a descrição da mudança é enviada para o repositório público do AOSP. Siga esta orientação se você estiver enviando patches ou confirmando alterações para um novo recurso.

Alterar descrições

• Linha 1: Título

  Forneça um resumo de uma linha ( máximo de 50 caracteres)

  Este formato é usado pelo Git e Gerrit para diversas exibições. É a parte mais importante e mais densa da sua mensagem de commit. Considere usar prefixos para descrever a área que você alterou, seguido de uma descrição da alteração que você fez neste commit, como este que tem ui como prefixo:

  ui: Removes deprecated widget

• Linha 2: Em branco

  Mantenha esta linha em branco, sempre.

• Linha 3: Corpo

  Escreva uma descrição mais longa, começando nesta linha.

  Deve ter no máximo 72 caracteres. Descreva qual problema a mudança resolve e como. Embora isso seja opcional ao implementar novos recursos, será muito útil para outros posteriormente se eles se referirem a essa mudança, especialmente para depuração.

  Inclua uma breve nota sobre quaisquer suposições ou informações básicas que possam ser importantes quando outro colaborador trabalhar neste recurso.

Um ID de alteração exclusivo e seu nome e e-mail, fornecidos durante repo init , são adicionados automaticamente à sua mensagem de commit.

Aqui está um exemplo de mensagem de commit:

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ê carrega o patch alterado, ele substitui o original no Gerrit e no histórico local do Git.

Resolver conflitos de sincronização

Se outros patches forem enviados para a árvore de origem que entre em conflito com o seu, rebaseie seu patch no 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 tenta rebasear automaticamente seu HEAD no novo HEAD remoto.

Se o rebase automático não for bem-sucedido, execute um rebase manual.

repo rebase

Outra ferramenta para lidar com o conflito de rebase é git mergetool . Depois de mesclar com êxito os arquivos conflitantes, execute este comando:

git rebase --continue

Após a conclusão do rebase automático ou manual, execute repo upload para enviar seu patch rebaseado.

Depois que um envio for aprovado

Depois que um envio passa pelo processo de revisão e verificação, Gerrit mescla automaticamente a alteração no repositório público. Outros usuários podem executar repo sync para enviar a atualização para seus respectivos clientes locais.

Para projetos upstream

O Android faz uso de vários outros projetos de código aberto, como o kernel Linux e o WebKit, conforme descrito em Android Software Management . Para a maioria dos projetos que residem em external/ , faça as alterações no upstream e informe aos mantenedores do Android sobre a nova versão do upstream que contém suas alterações.

Você também pode fazer upload de patches que façam com que uma nova versão upstream seja rastreada. Observe que essas alterações podem ser difíceis de fazer se o projeto for amplamente utilizado no Android, como a maioria dos maiores mencionados abaixo, que geralmente são atualizados a cada lançamento.

Um caso especial interessante é o Bionic. Grande parte do código vem do BSD, então, a menos que a mudança seja em um código novo no Bionic, faça uma correção upstream e, em seguida, extraia um arquivo totalmente novo do BSD apropriado.

Kernel do Android

Faça todas as alterações no upstream. Para obter orientação geral, siga as Diretrizes de contribuição do kernel do Android e a página Desenvolver código do kernel para GKI .

UTI

Faça todas as alterações no projeto ICU em external/icu (pastas icu4c/ e icu4j/ ) na página inicial do ICU-TC . Consulte Enviando bugs de ICU e solicitações de recursos para obter mais informações. Adicione o rótulo “android” a todas as solicitações upstream do Jira.

CLDR

A maioria dos dados linguísticos na UTI vem do projeto Unicode CLDR . Envie todas as solicitações upstream de acordo com Contributing to CLDR e adicione o rótulo “android”.

LLVM/Clang/Compilador-rt

Faça todas as alterações nos projetos relacionados ao LLVM ( external/clang , external/compiler-rt , external/llvm ) na página LLVM Compiler Infrastructure .

mksh

Faça todas as alterações no projeto MirBSD Korn Shell em external/mksh enviando um e-mail para miros-mksh no domínio mirbsd.org (não é necessária assinatura para enviar lá) ou em Launchpad .

OpenSSL

Faça todas as alterações no projeto OpenSSL em external/openssl na página OpenSSL .

V8

Envie todas as alterações no projeto V8 em external/v8 na página de problemas do V8 . Consulte Contribuindo para V8 para obter detalhes.

Kit Web

Faça todas as alterações no projeto WebKit em external/webkit na página do WebKit . Inicie o processo registrando um bug do WebKit . No bug, use Android para os campos Plataforma e SO somente se o bug for específico do Android. É muito mais provável que os bugs recebam a atenção dos revisores depois que uma correção proposta é adicionada e os testes são incluídos. Consulte Contribuindo com código para o WebKit para obter detalhes.

zlib

Faça todas as alterações no projeto zlib em external/zlib na página inicial do zlib .