1. 程式人生 > >android repo中manifest.xml的詳解

android repo中manifest.xml的詳解

FROM:http://blog.csdn.net/shift_wwx/article/details/19557031


前言:最近配到一個關於manifest配置的問題,感覺還是需要總結一下,不然過一陣子又忘記了。但是記錄的不是很詳細,以後會補充的。下面的英文如果翻譯的不是很對,也請提出來!

A description of the elements and their attributes follows.

Element manifest

The root element of the file.

Element remote

One or more remote elements may be specified. Each remote element specifies a 

Git URL shared by one or more projects and (optionally) the Gerrit review server those projects upload changes through.

Attribute name: A short name unique to this manifest file. The name specified here is used as the remote name in each project's .git/config, and is therefore automatically available to commands likegit fetch

,git remote,git pull and git push.

Attribute alias: The alias, if specified, is used to override name to be set as the remote name in each project's .git/config. Its value can be duplicated while attributename has to be unique in the manifest file. This helps each project to be able to have same remote name which actually points to different remote url.

Attribute fetch: The Git URL prefix for all projects which use this remote. Each project's name is appended to this prefix to form the actual URL used to clone the project.

Attribute review: Hostname of the Gerrit server where reviews are uploaded to byrepo upload. This attribute is optional; if not specified thenrepo upload will not function.

Element default

At most one default element may be specified. Its remote and revision attributes are used when a project element does not specify its own remote or revision attribute.

Attribute remote: Name of a previously defined remote element. Project elements lacking a remote attribute of their own will use this remote.

Attribute revision: Name of a Git branch (e.g. master orrefs/heads/master). Project elements lacking their own revision attribute will use this revision.

Element manifest-server

At most one manifest-server may be specified. The url attribute is used to specify the URL of a manifest server, which is an XML RPC service that will return a manifest in which each project is pegged to a known good revision for the current branch and target.

The manifest server should implement:

GetApprovedManifest(branch, target)

The target to use is defined by environment variables TARGETPRODUCT and TARGETBUILDVARIANT. These variables are used to create a string of the form $TARGETPRODUCT-$TARGETBUILDVARIANT, e.g. passion-userdebug. If one of those variables or both are not present, the program will call GetApprovedManifest without the target paramater and the manifest server should choose a reasonable default target.

Element project

One or more project elements may be specified. Each element describes a single Git repository to be cloned into the repo client workspace.

Attribute name: A unique name for this project. The project's name is appended onto its remote's fetch URL to generate the actual URL to configure the Git remote with. The URL gets formed as:

${remotefetch}/${projectname}.git

where ${remotefetch} is the remote's fetch attribute and ${projectname} is the project's name attribute. The suffix ".git" is always appended as repo assumes the upstream is a forrest of bare Git repositories.

The project name must match the name Gerrit knows, if Gerrit is being used for code reviews.

Attribute path: An optional path relative to the top directory of the repo client where the Git working directory for this project should be placed. If not supplied the project name is used.

Attribute remote: Name of a previously defined remote element. If not supplied the remote given by the default element is used.

Attribute revision: Name of the Git branch the manifest wants to track for this project. Names can be relative to refs/heads (e.g. just "master") or absolute (e.g. "refs/heads/master"). Tags and/or explicit SHA-1s should work in theory, but have not been extensively tested. If not supplied the revision given by the default element is used.

Attribute groups: List of groups to which this project belongs, whitespace or comma separated. All projects belong to the group "default", and each project automatically belongs to a group of it's name:name and path:path. E.g. for , that project definition is implicitly in the following manifest groups: default, name:monkeys, and path:barrel-of.

Element annotation

Zero or more annotation elements may be specified as children of a project element. Each element describes a name-value pair that will be exported into each project's environment during a 'forall' command, prefixed with REPO__. In addition, there is an optional attribute "keep" which accepts the case insensitive values "true" (default) or "false". This attribute determines whether or not the annotation will be kept when exported with the manifest subcommand.

Element remove-project

Deletes the named project from the internal manifest table, possibly allowing a subsequent project element in the same manifest file to replace the project with a different source.

This element is mostly useful in the local_manifest.xml, where the user can remove a project, and possibly replace it with their own definition.

Element include

This element provides the capability of including another manifest file into the originating manifest. Normal rules apply for the target manifest to include- it must be a usable manifest on it's own.

Attribute name; the manifest to include, specified relative to the manifest repositories root.

Local Manifest

Additional remotes and projects may be added through a local manifest, stored in$TOP_DIR/.repo/local_manifest.xml.

For example:

$ cat .repo/local_manifest.xml

Users may add projects to the local manifest prior to a repo sync invocation, instructing repo to automatically download and manage these extra projects.

EXAMPLE:

[javascript] view plain copy 在CODE上檢視程式碼片派生到我的程式碼片
  1. <?xml version="1.0" encoding="UTF-8"?>  
  2. <manifest>  
  3.   <remote  name="shift"
  4.            fetch="git://git.mygit.com/" />  
  5.   <default revision="kk-shift"
  6.            remote="shift"
  7.            sync-j="1" />  
  8.   <project path="packages/shift/VideoPlayer" name="platform/packages/shift/VideoPlayer" />  
  9. </manifest>  


前面是從別處摘取的英文部分的敘述,結合上面的例子來詳細解釋一下。

1. manifest

這個是配置的頂層元素,即根標誌

2. remote

  • name:在每一個.git/config檔案的remote項中用到這個name,即表示每個git的遠端伺服器的名字(這個名字很關鍵,如果多個remote屬性的話,default屬性中需要指定default remote)。git pull、get fetch的時候會用到這個remote name。
  • alias :可以覆蓋之前定義的remote name,name必須是固定的,但是alias可以不同,可以用來指向不同的remote url
  • fetch :所有git url真正路徑的字首,所有git 的project name加上這個字首,就是git url的真正路徑
  • review :指定Gerrit的伺服器名,用於repo upload操作。如果沒有指定,則repo upload沒有效果

3. default 

設定所有projects的預設屬性值,如果在project元素裡沒有指定一個屬性,則使用default元素的屬性值。

  • remote :遠端伺服器的名字(上面remote屬性中提到過,多個remote的時候需要指定default remote,就是這裡設定了
  • revision :所有git的預設branch,後面project沒有特殊指出revision的話,就用這個branch
  • sync_j : 在repo sync中預設並行的數目
  • sync_c :如果設定為true,則只同步指定的分支(revision 屬性指定),而不是所有的ref內容
  • sync_s : 如果設定為true,則會同步git的子專案

4. manifest-server

它的url屬性用於指定manifest服務的URL,通常是一個XML RPC 服務

它要支援一下RPC方法:

  • GetApprovedManifest(branch, target) :返回一個manifest用於指示所有projects的分支和編譯目標。
        target引數來自環境變數TARGET_PRODUCT和TARGET_BUILD_VARIANT,組成$TARGET_PRODUCT-$TARGET_BUILD_VARIANT
  • GetManifest(tag) :返回指定tag的manifest

5. project

需要clone的單獨git

  • name :git 的名稱,用於生成git url。URL格式是:${remote fetch}/${project name}.git 其中的 fetch就是上面提到的remote 中的fetch元素,name 就是此處的name
  • path :clone到本地的git的工作目錄,如果沒有配置的話,跟name一樣
  • remote :定義remote name,如果沒有定義的話就用default中定義的remote name
  • revision :指定需要獲取的git提交點,可以定義成固定的branch,或者是明確的commit 雜湊值
  • groups :列出project所屬的組,以空格或者逗號分隔多個組名。所有的project都自動屬於"all"組。每一個project自動屬於
    name:'name' 和path:'path'組。例如<project name="monkeys" path="barrel-of"/>,它自動屬於default, name:monkeys, and path:barrel-of組。如果一個project屬於notdefault組,則,repo sync時不會下載
  • sync_c :如果設定為true,則只同步指定的分支(revision 屬性指定),而不是所有的ref內容。
  • sync_s : 如果設定為true,則會同步git的子專案
  • upstream :在哪個git分支可以找到一個SHA1。用於同步revision鎖定的manifest(-c 模式)。該模式可以避免同步整個ref空間
  • annotation :可以有0個或多個annotation,格式是name-value,repo forall命令是會用來定義環境變數

6. include

通過name屬性可以引入另外一個manifest檔案(路徑相對與當前的manifest.xml 的路徑)

  • name :另一個需要匯入的manifest檔名字

EXAMPLE :

[javascript] view plain copy 在CODE上檢視程式碼片派生到我的程式碼片
  1. <?xml version="1.0" encoding="UTF-8"?>  
  2. <manifest>  
  3.   <remote  name="shift"
  4.            fetch="git://git.mygit.com/" />  
  5.   <default revision="kk-shift"
  6.            remote="shift"
  7.            sync-j="1" />  
  8.   <project path="packages/shift/VideoPlayer" name="platform/packages/shift/VideoPlayer" />  
  9.   <include name="another_manifest.xml" />  
  10. </manifest>  
可以在當前的路徑下新增一個another_manifest.xml,這樣可以在另一個xml中新增或刪除project

7. remove-project 

從內部的manifest表中刪除指定的project。經常用於本地的manifest檔案,使用者可以替換一個project的定義

如果瞭解repo命令的話,還有另外一種管理manifest的方法,那就是用另外一個local_manifest.xml,然後在repo init的時候用repo init -u *** -b *** -m local_manifest.xml即可,一般不用-m的時候預設是用default.xml