Detaillierte Erläuterung jedes Tags in der Standard-Manifestdatei default.xml der Repo-Manifeste

Einführung in Repo

„Repo“ ist ein Tool zur Verwaltung mehrerer Git-Repositories, das häufig bei Android-Entwicklungsprojekten von Google verwendet wird. Sie können damit problemlos mehrere Git-Repositorys mit einem einzigen Befehl synchronisieren, herunterladen und verwalten.

Repo herunterladen und installieren

Von der Tsinghua-Spiegelquelle herunterladen

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

Tatsächlich handelt es sich bei der heruntergeladenen Repo-Datei nur um ein in Python geschriebenes Boot-Skript (Google nennt es Repo Launcher, bei dem es sich im Wesentlichen um ein Python-Skript handelt, das mit vim geöffnet werden kann). Das vollständige Repo (d. h. der Hauptteil des Repos) hat noch nicht heruntergeladen. .

Repo-Hilfe

Sehen Sie sich die Beschreibung der Repo-Hilfe an, in der die vom Repo unterstützten Unterbefehle sowie eine kurze Einführung zu jedem Unterbefehl aufgeführt sind.
Wenn Sie die detaillierte Einführung eines bestimmten Unterbefehls anzeigen möchten, führen Sie einfach die Befehls-Repo-Hilfe aus. Um beispielsweise die Hilfe von repo init anzuzeigen, können Sie repo help init eingeben.

Wie im vorherigen Abschnitt erwähnt, handelt es sich bei dem heruntergeladenen Repo nur um ein Boot-Skript und das vollständige Repo-Tool wurde nicht heruntergeladen. Wenn Sie zu diesem Zeitpunkt den Repo-Hilfebefehl ausführen, werden nur die beiden Unterbefehle init und help sowie angezeigt Die Hilfemeldung fordert Sie auch auf, repo zu installieren. Es wurde noch nicht installiert. Sie müssen eine Repo-Init-Installation durchführen. (Es ist zu beachten, dass für Repo Init Parameter erforderlich sind. Die Verwendung von Repo Init wird später separat vorgestellt.)
Nachdem Sie Repo Init ausgeführt haben, um das vollständige Repo-Tool herunterzuladen, führen Sie Repo Help erneut aus und Sie werden weitere Unterbefehle von Repo sehen.
Hinweis: Auf repo init -u folgt die URL-Adresse. Wenn es sich um Ihr eigenes Projekt handelt, handelt es sich um die Adresse des Repo, das durch den Quellcode des Android-Quellcodeprojekts bearbeitet wurde. Wenn es sich um das offizielle AOSP-Repo handelt, ist dies offiziell konfiguriert ist, können Sie die folgenden zwei Möglichkeiten vergleichen, das Repo-Tool zu installieren:

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>

Der Befehlseffekt „repo init -u“
erstellt zunächst ein .repo-Verzeichnis im aktuellen Verzeichnis
und klont dann eine Kopie des Repo-Quellcodes nach .repo/repo, in der andere Repo-Unterbefehle, also der Hauptteil des Repos, gespeichert werden.
Klonen Sie dann die Manifestbibliothek von der Warehouse-Adresse manifest_git_path in die Verzeichnisse .repo/manifests und .repo/manifests.git.
Gleichzeitig enthält das .repo-Verzeichnis auch den Inhalt des Manifest-Warehouses (Manifest-Bibliothek).

Einführung in den .repo-Ordner
Nach der Ausführung des repo-init-Befehls wird im aktuellen Verzeichnis ein .repo-Ordner erstellt.

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

Manifest-Dateianalyse

Das sogenannte Manifest-Warehouse (Manifest-Bibliothek) ist eigentlich ein Warehouse, das Manifest-Dateien (Manifest-Dateien) speichert. Es kann sich tatsächlich um jedes Warehouse handeln, solange die durch die Option -m des Befehls repo init angegebene Manifestdatei im Warehouse vorhanden ist . Die Manifest-Bibliothek heißt einfach manifest. Es handelt sich lediglich um eine herkömmliche Schreibweise.
Das Manifest-Warehouse verfügt im Allgemeinen über die Datei manifests\default.xml, bei der es sich um die Standard-Manifestdatei handelt.

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

Erläuterung jedes Elements der Manifestdatei

<Manifest- >Root-Tag
Dies ist das Element der obersten Ebene der Konfiguration, das Root-Tag.
<Das Remote- >Tag kann mehrere Remote-Elemente enthalten
, die verwendet werden, wenn mehrere Git-Remote-Server vorhanden sind.
- Name stellt den Namen jedes Git-Remote-Servers dar (dieser Name ist sehr wichtig, wenn mehrere Remote-Attribute vorhanden sind, muss im Standardattribut die Standard-Remote angegeben werden). Dieser Remote-Name wird beim Ausführen von Git Pull und Get Fetch verwendet.
- fetch: Das Präfix des tatsächlichen Pfads aller Git-URLs. Alle Git-Projektnamen (d. h. die Namenselemente der folgenden Projekt-Tags) plus dieses Präfix sind die tatsächlichen Pfade der Git-URLs; wenn die Präfixe aller Projekte diese Fernbedienung verwenden befinden sich vor dem Manifest- Warehouse. Wenn die Einstellungen konsistent sind, können Sie stattdessen ... verwenden.
  
  repo init -u https://github.com/remote-android/platform_manifests.git -b redroid-11.0.0's Manifest-Warehouse-Front https://github.com/remote-android/
- Bewertung: Der Hostname des Gerrit-Servers, auf den Bewertungen per Repo-Upload hochgeladen werden. Dieses Attribut ist optional. Wenn es nicht angegeben wird, hat der Repo-Upload keine Auswirkung.
- alias: Dieses Attribut kann weggelassen werden. Wenn dieses Attribut angegeben wird, kann das Namensattribut überschrieben werden, um den Remote-Namen in der .git/config jedes Projekts festzulegen. Die Alias-Attribute verschiedener Remote-Elemente können gleich sein. Beispielsweise können die Alias-Attribute verschiedener Remote-Elemente alle origin sein.
<Standard- >Tag-Element
Es kann nur ein Standardelement geben. Legt den Standardattributwert für alle Projekt-Tags fest. Wenn im Projektelement kein Attribut angegeben ist, wird der Attributwert des Standardelements verwendet.
- remote: Der Name des Remote-Servers (wie im Remote-Attribut oben erwähnt, müssen Sie bei mehreren Remotes das Standard-Remote angeben, das hier festgelegt wird)
- Revision: Der Standardzweig von allen Git. Wenn das Projekt später keine Revision angibt, wird dieser Zweig verwendet.
- sync_j: Die Standardanzahl von Parallelen in der Repo-Synchronisierung
<Das Superproject- >Tag ist ein Element in der Manifestdatei, das ein Superprojekt (auch „Manifestprojekt“ genannt) definiert.
Ein Superprojekt ist ein spezielles Projekt, das häufig zur Organisation mehrerer Teilprojekte verwendet wird. Bei der Android-Quellcodeverwaltung können diese Teilprojekte unterschiedliche Softwarekomponenten, Bibliotheken, Anwendungen usw. sein. Das Superprojekt selbst enthält in der Regel nicht den eigentlichen Quellcode, sondern dient hauptsächlich der Verwaltung und Synchronisierung des Codes dieser Unterprojekte.
Das Superproject-Tag in der Datei default.xml enthält hauptsächlich die folgenden Informationen:
- Namensattribut: Gibt den Namen des Superprojekts an. Dieser Name ist normalerweise eine eindeutige Kennung, die zur Unterscheidung verschiedener Superprojekte verwendet wird.
- path-Attribut: Gibt den Pfad des Superprojekts an. Dies ist der relative Pfad des Superprojekts im lokalen Dateisystem. Repo erstellt unter diesem Pfad einen Ordner, um das Superprojekt zu verwalten.
- Remote-Attribut: Gibt den Namen des Git-Remote-Repositorys an, das dem Superprojekt zugeordnet ist. Dieses Remote-Repository enthält normalerweise Informationen zur Manifestdatei und verwaltet alle Unterprojekte.
- Revisionsattribut: Gibt den zu verwendenden Git-Zweig, das zu verwendende Tag oder die Commit-ID an. Dies bestimmt die Version der vom Superprojekt verwalteten Teilprojekte.
<Das Projekt- >Tag
erfordert einen separaten Git-Klon. Jeder stellt ein Warehouse dar, das in den Arbeitsbereich geklont werden kann und die Konfigurationsinformationen eines Git-Warehouse-Projekts definiert.
- Name: Der Name von Git, der zum Generieren der Git-URL verwendet wird. Das URL-Format ist: ${remote fetch}/$ {Projektname}.git wobei fetch das Abrufattribut des oben erwähnten Tags in remote ist und name hier der Name ist; wenn dieses Projekt ein übergeordnetes Attribut hat, dann ist das Projekt das Die endgültige URL wird wie folgt zusammengesetzt:
  ${remote_fetch}/$ {project_parent}/${project_name}.git
- Pfad: Geben Sie den Pfad des Repositorys im lokalen Dateisystem an. Klonen Sie in das lokale Git-Arbeitsverzeichnis. Wenn nicht konfiguriert, verwenden Sie den Namensattributwert; einen relativen Pfad relativ zum Stammverzeichnis des Repos;
- remote: Gibt den Namen des Remote-Warehouses an, das von diesem Warehouse verwendet wird. Definieren Sie den Remote-Namen. Wenn er nicht definiert ist, verwenden Sie den standardmäßig definierten Remote-Namen.
- Revision: Geben Sie den Zweig, das Tag oder das Commit an, das von diesem Repository verwendet wird. Geben Sie den zu erhaltenden Git-Commit-Punkt an, der als fester Zweig oder als klarer Commit-Hash-Wert definiert werden kann
- Gruppen: Geben Sie die Gruppe an, zu der das Lager gehört, und verwenden Sie diese zur Organisation des Lagers. Listen Sie die Gruppen auf, zu denen das Projekt gehört. Trennen Sie mehrere Gruppennamen durch Leerzeichen oder Kommas. Alle Projekte gehören automatisch zur Gruppe „Alle“. Jedes Projekt gehört automatisch zu den Gruppen name:'name' und path:'path'. Beispielsweise gehört es automatisch zu den Standardgruppen name:monkeys und path:barrel-of. Wenn ein Projekt zur Gruppe „notdefault“ gehört, wird es während der Repo-Synchronisierung nicht heruntergeladen.
Das Copyfile-Tag ist
ein untergeordnetes Element des Projektelements. Jedes Element beschreibt ein Paar von src-dest-Dateien. Während der Synchronisierung (d. h. wenn der Repo-Synchronisierungsbefehl ausgeführt wird) wird die Quelldatei in das Ziel kopiert. Wird normalerweise in README oder Makefile oder anderen Build-Skripten verwendet.
- dest: ist der Pfad relativ zum aktuellen Verzeichnis (das Verzeichnis, in dem die Befehle repo init und repo sync ausgeführt werden)
- src: ist ein relativer Pfad relativ zum Pfadattributwert des Projekt-Tags
Das Linkfile-Tag
ähnelt dem Copyfile-Tag, mit der Ausnahme, dass statt eines Kopierens ein symbolischer Link erstellt wird.
Das Include-Tag
kann über das Namensattribut eine weitere Manifestdatei einführen (der Pfad ist relativ zum Pfad der aktuellen manifest.xml). Name: Der Name einer anderen Manifestdatei, die importiert werden muss. Sie können eine andere_manifest.xml
unter hinzufügen Aktueller Pfad, damit Sie eine weitere Manifestdatei unter dem aktuellen Pfad hinzufügen können. Projekt in einer XML hinzufügen oder löschen
Remove-Project-Tag
Entfernt das angegebene Projekt aus der internen Manifesttabelle. Wird verwendet, um ein Element aus der Manifestdatei zu entfernen. Dies kann verwendet werden, um die Synchronisierung des Codes eines Projekts zu stoppen.
Das Annotation-Tag
stellt Anmerkungen zum Element bereit, um den Zweck des Warehouses oder andere Informationen zu beschreiben.
Das Repo-Hooks-Tag
wird verwendet, um die Hook-Skripte zu definieren, die Repo bei der Ausführung bestimmter Vorgänge auslösen soll. Repo-Hooks sind ein Mechanismus, der es Ihnen ermöglicht, einige benutzerdefinierte Skripte oder Befehle automatisch auszuführen, wenn bestimmte Git-Vorgänge ausgeführt werden.
- im Projekt: Gibt den relativen Pfad des Hook-Skripts an, der relativ zum Pfad des aktuellen Repos ist. Diese Eigenschaft wird normalerweise verwendet, um Hook-Skripte für ein bestimmtes Repo festzulegen, anstatt sie global festzulegen.
- aktivierte Liste: Eine durch Kommas getrennte Liste von Hook-Namen, die angibt, welche Hooks im aktuellen Repo aktiviert werden sollen. Dadurch können Sie den Repo-Hook gezielt aktivieren oder deaktivieren.

Erstellen Sie einen Repo-Dienst

Kurz gesagt:
Stellen Sie das gemeinsame Tool-Repository git-repo.git bereit.
Stellen Sie Ihr eigenes Manifest-Repository manifests.git bereit.
Schreiben Sie die Datei manifests.xml,
um Projekt-Unterrepositorys zu erstellen und Quellcodes stapelweise hochzuladen.