Explicação detalhada de cada tag no arquivo de manifesto padrão default.xml dos manifestos do Repo

Introdução ao Repo

"Repo" é uma ferramenta para gerenciar vários repositórios Git, frequentemente usada em projetos de desenvolvimento Android do Google. Ele permite sincronizar, baixar e gerenciar facilmente vários repositórios Git sob um único comando.

baixe e instale o repositório

Baixe da fonte do espelho Tsinghua

mkdir ~/bin  
PATH=~/bin:$PATH  
curl https://mirrors.tuna.tsinghua.edu.cn/git/git-repo -o ~/bin/repo #~/bin/repo为repo下载本地的存放路径
chmod a+x ~/bin/repo  

Na verdade, o arquivo repo baixado é apenas um script de inicialização escrito em Python (o Google o chama de Repo launcher, que é essencialmente um script python que pode ser aberto usando vim). O repositório completo (ou seja, a parte principal do repo) tem ainda não foi baixado..

ajuda do repositório

Veja a descrição da ajuda do repositório, que lista os subcomandos suportados pelo repositório e uma breve introdução a cada subcomando.
Se você precisar ver a introdução detalhada de um subcomando específico, basta executar o comando repo help. Por exemplo, para visualizar a ajuda do repo init, você pode inserir repo help init.

Conforme mencionado na seção anterior, o repositório baixado é apenas um script de inicialização e a ferramenta de repositório completa não foi baixada. Neste momento, ao executar o comando repo help, você só pode ver os dois subcomandos init e help, e a mensagem de ajuda também solicitará repo. Ainda não foi instalado, você precisa executar a instalação do repo init. (Deve-se observar que repo init requer parâmetros. O uso de repo init será introduzido separadamente posteriormente.)
Após executar repo init para baixar a ferramenta repo completa, execute repo help novamente e você verá mais subcomandos de repo.
Nota: repo init -u é seguido pelo endereço da URL. Se for seu próprio projeto, é o endereço do Repo editado pelo código-fonte do projeto de código-fonte do Android; se for o repositório oficial do AOSP e for oficialmente configurado, você pode comparar as duas maneiras a seguir de instalar a ferramenta repo:

repo init -u https://github.com/remote-android/platform_manifests.git -b redroid-11.0.0 --depth=1 --git-lfs # 自定义repo工具中描述源码仓库地址组织形式
repo init -u https://mirrors.tuna.tsinghua.edu.cn/git/AOSP/platform/manifest -b android-12.0.0_r1 # 官方AOSP repo中源码仓库组织形式
或者
repo init -u https://android.googlesource.com/platform/manifest -b android-12.0.0_r12
如果需要某个特定的 Android 版本,特定版本标记查看
<https://source.android.google.cn/docs/setup/about/build-numbers?hl=zh-cn#source-code-tags-and-builds>

O efeito do comando repo init -u
primeiro cria um diretório .repo no diretório atual
e, em seguida, clona uma cópia do código-fonte do repositório para .repo/repo, que armazena outros subcomandos do repositório, ou seja, a parte principal do repositório.
Em seguida, clone a biblioteca de manifestos do endereço do warehouse manifest_git_path para os diretórios .repo/manifests e .repo/manifests.git.
Ao mesmo tempo, o diretório .repo também inclui o conteúdo do manifest warehouse (biblioteca de manifestos)

Introdução à pasta .repo
Após executar o comando repo init, uma pasta .repo será criada no diretório atual.

文件夹            描述
manifests          manifest仓库(清单库)内容,即repo init的-u选项对应的仓库
manifests.git      manifest仓库(清单库)的.git目录
manifest.xml      指明当前生效的Manifest文件,即repo init的-m选项对应的参数(没有该选项时默认为default.xml)
repo                 repo命令的主体,包含了最新的 repo 命令

Análise de arquivo de manifesto

O chamado armazém de manifesto (biblioteca de manifesto) é na verdade um armazém que armazena arquivos de manifesto (manifesto). Na verdade, pode ser qualquer armazém, desde que o arquivo de manifesto especificado pela opção -m do comando repo init exista no armazém A biblioteca de manifestos chama-se manifest.É apenas uma forma convencional de escrever.
O armazém de manifesto geralmente possui um arquivo manifests\default.xml, que é o arquivo de manifesto padrão.

<?xml version="1.0" encoding="UTF-8"?>
<manifest>

  <remote  name="aosp"
           fetch="https://mirrors.tuna.tsinghua.edu.cn/git/AOSP/"
           review="https://android-review.googlesource.com/" />
  <default revision="refs/tags/android-12.0.0_r32"
           remote="aosp"
           sync-j="4" />

  <superproject name="platform/superproject" remote="aosp" revision="android-12.0.0_r32" />
  <contactinfo bugurl="go/repo-bug" />

  <project path="build/make" name="platform/build" groups="pdk" >
    <copyfile src="core/root.mk" dest="Makefile" />
    <linkfile src="CleanSpec.mk" dest="build/CleanSpec.mk" />
    <linkfile src="buildspec.mk.default" dest="build/buildspec.mk.default" />
    <linkfile src="core" dest="build/core" />
    <linkfile src="envsetup.sh" dest="build/envsetup.sh" />
    <linkfile src="target" dest="build/target" />
    <linkfile src="tools" dest="build/tools" />
  </project>
  <project path="build/bazel" name="platform/build/bazel" groups="pdk" >
    <linkfile src="bazel.WORKSPACE" dest="WORKSPACE" />
    <linkfile src="bazel.sh" dest="tools/bazel" />
    <linkfile src="bazel.BUILD" dest="BUILD" />
  </project>
  <project path="build/blueprint" name="platform/build/blueprint" groups="pdk,tradefed" />
  <project path="build/pesto" name="platform/build/pesto" groups="pdk" />
  <project path="build/soong" name="platform/build/soong" groups="pdk,tradefed" >
    <linkfile src="root.bp" dest="Android.bp" />
    <linkfile src="bootstrap.bash" dest="bootstrap.bash" />
  </project>
  <project path="art" name="platform/art" groups="pdk" />
  <project path="bionic" name="platform/bionic" groups="pdk" />
  <project path="bootable/recovery" name="platform/bootable/recovery" groups="pdk" />
  <project path="bootable/libbootloader" name="platform/bootable/libbootloader" groups="vts,pdk" />
  <project path="compatibility/cdd" name="platform/compatibility/cdd" groups="pdk" />
  <project path="cts" name="platform/cts" groups="cts,pdk-cw-fs,pdk-fs" />
  <project path="dalvik" name="platform/dalvik" groups="pdk-cw-fs,pdk-fs" />
  <project path="developers/build" name="platform/developers/build" groups="developers,pdk" />
  省略一部分....
  <repo-hooks in-project="platform/tools/repohooks" enabled-list="pre-upload" />
</manifest>

Explicação de cada elemento do arquivo de manifesto

  1. <>tag raiz do manifesto
    Este é o elemento de nível superior da configuração, a tag raiz.

  2. <>Pode haver vários elementos remotos na tag remota
    , que são usados ​​quando há vários servidores remotos git.

    • name representa o nome de cada servidor remoto git (este nome é muito importante, se houver vários atributos remotos, o remoto padrão precisa ser especificado no atributo padrão). Este nome remoto será usado ao executar git pull e get fetch.

    • fetch: O prefixo do caminho real de todos os URLs git. Todos os nomes de projetos git (ou seja, os elementos de nome das seguintes tags do projeto) mais este prefixo são os caminhos reais dos URLs git; se os prefixos de todos os projetos que usam este controle remoto estão na frente do armazém de manifesto. Se as configurações forem consistentes, você pode usar... em vez disso.

      repo init -u https://github.com/remote-android/platform_manifests.git -b frente do armazém de manifesto do redroid-11.0.0 https://github.com/remote-android/

    • review: O nome do host do servidor Gerrit para o qual as avaliações são carregadas por meio de upload de repositório. Este atributo é opcional; se não for especificado, o upload do repositório não terá efeito.

    • alias: Este atributo pode ser omitido. Quando este atributo é especificado, o atributo name pode ser substituído para definir o nome remoto em .git/config de cada projeto. Os atributos de alias de diferentes elementos remotos podem ser iguais. Por exemplo, os atributos de alias de diferentes elementos remotos podem ser todos originados.

  3. <>elemento de tag padrão
    Só pode haver um elemento padrão. Define o valor do atributo padrão para todas as tags do projeto. Se um atributo não for especificado no elemento do projeto, o valor do atributo do elemento padrão será usado.

    • remoto: O nome do servidor remoto (conforme mencionado no atributo remoto acima, você precisa especificar o controle remoto padrão quando houver vários controles remotos, que é definido aqui)
    • revisão: o branch padrão de todo o git.Se o projeto não especificar a revisão posteriormente, este branch será usado.
    • sync_j: O número padrão de paralelos na sincronização do repositório
  4. <A >tag superproject é um elemento no arquivo de manifesto que define um superprojeto (também chamado de "projeto manifesto").
    Um superprojeto é um projeto especial frequentemente usado para organizar vários subprojetos. No gerenciamento de código-fonte do Android, esses subprojetos podem ser diferentes componentes de software, bibliotecas, aplicativos, etc. O superprojeto em si geralmente não contém o código-fonte real, ele é usado principalmente para gerenciar e sincronizar o código desses subprojetos.
    A tag superproject no arquivo default.xml contém principalmente as seguintes informações:

    • atributo name: especifica o nome do superprojeto. Esse nome geralmente é um identificador exclusivo usado para distinguir diferentes superprojetos.
    • atributo path: especifica o caminho do superprojeto. Este é o caminho relativo do superprojeto no sistema de arquivos local. O Repo criará uma pasta neste caminho para gerenciar o superprojeto.
    • Atributo remoto: especifica o nome do repositório remoto Git associado ao superprojeto. Este repositório remoto geralmente contém informações sobre o arquivo de manifesto e gerencia todos os subprojetos.
    • atributo de revisão: especifica o branch, tag ou ID de commit do Git a ser usado. Isto determina a versão dos subprojetos gerenciados pelo superprojeto.
  5. <A >tag do projeto
    requer um clone git separado. Cada um representa um armazém que pode ser clonado no espaço de trabalho e define as informações de configuração de um projeto de armazém Git.

    • nome: o nome do git, usado para gerar o url do git. O formato do URL é: remotefetch / {remote fetch}/re m o t e f e t c h / {project name}.git onde fetch é o atributo fetch da tag remota mencionada acima, e name é o nome aqui; se este projeto tiver um atributo pai, então o projeto O o URL final será reunido assim
      remotefetch / {remote_fetch}/re m o t efe t c h / {project_parent}/${project_name}.git
    • caminho: Especifique o caminho do repositório no sistema de arquivos local. Clone para o diretório de trabalho local do git.Se não estiver configurado,use o valor do atributo name;um caminho relativo ao diretório raiz do repositório;
    • remoto: Especifica o nome do armazém remoto usado por este armazém. Defina o nome remoto. Se não estiver definido, use o nome remoto definido por padrão.
    • revisão: Especifique o branch, tag ou commit usado por este repositório. Especifique o ponto de commit do git a ser obtido, que pode ser definido como uma ramificação fixa ou um valor de hash de commit claro
    • grupos: Especifique o grupo ao qual pertence o armazém, utilizado para organizar o armazém. Liste os grupos aos quais o projeto pertence. Separe os nomes dos vários grupos com espaços ou vírgulas. Todos os projetos pertencem automaticamente ao grupo “todos”. Cada projeto pertence automaticamente aos grupos name:'name' e path:'path'. Por exemplo, ele pertence automaticamente aos grupos padrão name:monkeys e path:barrel-of. Se um projeto pertencer ao grupo notdefault, ele não será baixado durante a sincronização do repositório.
  6. A tag copyfile é
    um elemento filho do elemento do projeto. Cada elemento descreve um par de arquivos src-dest. Durante a sincronização (ou seja, quando o comando repo sync é executado), o arquivo src será copiado para dest. Normalmente usado em README ou Makefile ou outros scripts de construção.

    • dest: é o caminho relativo ao diretório atual (o diretório onde os comandos repo init e repo sync são executados)
    • src: é um caminho relativo ao valor do atributo path da tag do projeto
  7. A tag linkfile
    é semelhante a copyfile, exceto que em vez de copiar, ela cria um link simbólico.

  8. A tag include
    pode introduzir outro arquivo de manifesto através do atributo name (o caminho é relativo ao caminho do manifest.xml atual). name: o nome de outro arquivo de manifesto que precisa ser importado. Você pode adicionar another_manifest.xml
    sob o caminho atual, para que você possa adicionar outro arquivo de manifesto no caminho atual. Adicione ou exclua o projeto em um xml

  9. tag remove-project
    Remove o projeto especificado da tabela de manifesto interna. Usado para remover um item do arquivo de manifesto. Isso pode ser usado para interromper a sincronização do código de um projeto.

  10. A tag de anotação
    fornece anotações no elemento para descrever a finalidade do armazém ou outras informações.

  11. A tag repo-hooks
    é usada para definir os scripts de hooks que o Repo deve acionar ao executar operações específicas. Os ganchos de repositório são um mecanismo que permite executar automaticamente alguns scripts ou comandos personalizados quando ocorrem operações específicas do Git.

    • in-project: especifica o caminho relativo do script de gancho, que é relativo ao caminho do Repo atual. Esta propriedade normalmente é usada para definir scripts de gancho para um repositório específico, em vez de configurá-lo globalmente.
    • lista habilitada: uma lista separada por vírgulas de nomes de ganchos especificando quais ganchos devem ser habilitados no repositório atual. Isso permite ativar ou desativar seletivamente o gancho Repo.

Criar serviço de repositório

  • Resumindo:
    implante o repositório de ferramentas comum git-repo.git.
    Implante seu próprio repositório de manifestos manifests.git.
    Escreva o arquivo manifests.xml
    para criar subrepositórios de projetos e fazer upload de códigos-fonte em lotes.

Acho que você gosta

Origin blog.csdn.net/ezconn/article/details/132473051
Recomendado
Clasificación