Como enviar patches

Esta página descreve o processo completo de envio de um patch para o Android Open Source Project (AOSP), incluindo revisão e acompanhamento de mudanças com o Gerrit (link em inglês).

Pré-requisitos

Antes de seguir as instruções fornecidas nesta página, será preciso inicializar seu ambiente de build, fazer o download da origem, criar uma senha e seguir as instruções da página do gerador de senhas.
Para ver mais detalhes sobre o Repo e o Git, consulte Desenvolvimento.
Para ver informações sobre as diferentes funções que você pode desempenhar na comunidade do Android Open Source, consulte Funções do projeto.
Se você pretende contribuir com código para a plataforma Android, leia as informações de licenciamento do AOSP.
Observe que as mudanças em alguns dos projetos ascendentes usados pelo Android precisam ser feitas diretamente nesses projetos, conforme descrito em Projetos ascendentes.

Para colaboradores

Como autenticar com o servidor

Antes de fazer upload para o Gerrit, é preciso definir uma senha que identifique você no servidor. Siga as instruções na página do gerador de senhas. É necessário fazer isso apenas uma vez. Consulte Como usar a autenticação para ver mais detalhes.

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

Depois de modificar os arquivos de origem e validá-los, confirme as mudanças no seu repositório local:

git add -A
git commit -s

Forneça uma descrição detalhada da mudança na sua mensagem de confirmação. Essa descrição é enviada ao repositório AOSP público. Portanto, siga as seguintes diretrizes para escrever as descrições da lista de mudanças:

Comece com um resumo de apenas uma linha (máximo de 50 caracteres), seguido por uma linha em branco. Esse formato é usado pelo Git e Gerrit para várias exibições.
A partir da terceira linha, insira uma descrição mais longa, que precisa ser limitada ao tamanho máximo de 72 caracteres. Descreva o problema que a mudança resolve e como ela o resolve. A segunda parte é, de certa forma, opcional na implementação de novos recursos, embora seja desejável.
Inclua uma breve observação das suposições ou informações básicas que possam ser importantes quando outro colaborador trabalhar nesse recurso.

Veja um exemplo de mensagem de confirmação:

Short description on first line

More detailed description of your patch,
which is likely to take up multiple lines.

Uma código de mudança exclusivo e seu nome e e-mail fornecidos durante o repo init serão automaticamente adicionados à sua mensagem de confirmação.

Como fazer o upload para o Gerrit

Depois de confirmar a mudança do seu histórico pessoal, envie-a para o Gerrit com

repo upload

Se você tiver iniciado várias ramificações no mesmo repositório, será necessário selecionar qual será enviada por upload.

Após a conclusão do upload, o Repo fornecerá o URL de uma nova página no Gerrit (link em inglês). Acesse esse link para ver seu patch no servidor de análise, adicionar comentários ou solicitar revisores específicos para seu patch.

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.

Observação: caso você tenha feito outras confirmações desde o upload desse patch, será necessário mover manualmente seu HEAD do Git.

git add -A
git commit --amend

Quando você fizer upload do patch corrigido, 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, você precisará realocar seu patch sobre o novo HEAD do repositório de origem. A maneira mais fácil de fazer isso é executar

repo sync

Esse comando busca primeiro 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, realize uma realocação manual.

repo rebase

Usar o git mergetool pode ajudar você a lidar com o conflito de realocação. Depois de ter mesclado os arquivos conflitantes, execute:

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 análise 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 o cliente local deles.

Projetos ascendentes

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 em external/, as mudanças precisam ser feitas de forma ascendente e, em seguida, os administradores do Android são informados da nova versão ascendente que contém essas mudanças. Também pode ser útil fazer upload de patches que nos levem a rastrear uma nova versão ascendente, embora essas possam ser mudanças difíceis de realizar se o projeto for amplamente usado no Android, como a maioria das grandes modificações mencionadas abaixo, onde a tendência é que o upgrade seja feito 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, é preferível ter uma correção ascendente para então extrair um novo arquivo completo do BSD apropriado.

ICU4C

Faça todas as mudanças no projeto ICU4C em external/icu4c na Página inicial do ICU-TC (link em inglês). Consulte Como enviar solicitações de recursos e bugs de ICU para ver mais informações (link em inglês).

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 em external/v8 usando a página de problemas do V8 (link em inglês). Consulte Como contribuir para o V8 para ver mais detalhes (link 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 ver mais detalhes (links todos em inglês).

zlib

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