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