When you initialize an AOSP workspace using the repo init command, you are essentially downloading a single map that tells the Repo tool exactly where to find every other piece of the operating system. This map is called the Manifest File.
The default.xml Structure
Manifest files are written in XML and are typically stored in a hidden .repo/manifests/ directory. The primary entry point is usually a file named default.xml.
A manifest file primarily consists of two types of elements: remotes and projects.
Remote Elements
A <remote> element defines a hosting server where Git repositories are stored.
<remote name="aosp"
fetch="https://android.googlesource.com/"
review="https://android-review.googlesource.com/" />
In this example, the remote named "aosp" points to Google's public Git servers. The review attribute tells the Repo tool where to upload code for Gerrit code review.
Project Elements
A <project> element defines an individual Git repository that needs to be downloaded.
<project path="frameworks/base"
name="platform/frameworks/base"
remote="aosp"
revision="master" />
name: The name of the repository on the remote server.path: The exact folder structure where this repository should be downloaded on your local hard drive.remote: Which server to download it from.revision: The specific Git branch, tag, or commit hash to check out.
Pinning Revisions
By default, an AOSP branch manifest will set the revision attribute to a branch name (like refs/heads/android14-release). This means every time you run repo sync, you will pull the absolute latest commits pushed to that branch by Google.
However, when a final release is published (like a monthly security bulletin), Google publishes a specific manifest where every single revision is "pinned" to a static Git commit hash.
<!-- Example of a pinned revision for absolute reproducibility -->
<project path="system/core"
name="platform/system/core"
revision="a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0" />
Pinning ensures that if you sync the codebase today or five years from now, you will get the exact same byte-for-byte source code, allowing perfect reproduction of historical builds.
Reading the AOSP Manifest
As an AOSP developer, you will frequently need to open the manifest XML file. If you are ever unsure where a specific command-line tool or system app comes from, searching the manifest file for the local path will immediately tell you the remote repository name and which server it originates from.
You can view the exact manifest your current workspace is using right from the terminal:
# Print the current parsed manifest
repo manifest