AndroidRepoCheckout
Android code is developed internally and pushed to the android.googlesource.com git repositories at regular intervals. Such a code drop consists of pushes to many git repositories. The tool called repo and a meta git repository called manifest make it possible to get all the code needed to build your own Android system.
The complexity of the git/repo tools itself combined by a general lack of information about branching makes it h
8000
ard to really know what to checkout. If you just follow the guide on
the Android website you will end-up checking out the master version of the meta (manifest) repository. This manifest checkout on it’s turn will checkout the master branch version of all the components (Have a lolook at .repo/manifest.xml and specially the default revision tag). This certainly doesn’t match any released version of the source code.
To know what branch/tag you want to checkout you can either look at the git log of the manifest git go into .repo/manifest and run
git branch -r ; git tag or run git gui to get a better understanding of what is going on. If you want to checkout a specific version e.g. “2.3” and not the head of the branch you should checkout using a tag. Once you did a init of your repo using repo init you can afterwards do a repo sync to sunc all the projects.
The android project published a list of known tags/versions to use http://source.android.com/source/build-numbers.html
running git gui on the manifest git repo
I hope this is right (if not please help me!).
mkdir android-gingerbread
repo init -u https://android.googlesource.com/platform/manifest -b gingerbread
#
# Check that the manifest is correct open .repo.manifest.xml
# <default revision="gingerbread"
# remote="korg" />
repo sync..If you are getting the sources of Android you must be in the busyness of changing
the code and you therefore probably want to have a local server running and hosting.
People from cyanogenmod or rowboat
clone and host Android repositories to create an share their own modifications to Android.
The Android source code consists of many git trees and branches. The repo tool uses a file called manifest.xml to obtain meta data about all these git repository and is itself hosted in a git tree having branches.
-manifest.git--head---------manifest.xml (use default checkout branch HEAD)
\-gingerbread--manifest.xml (uses /less or different repositories)In other words checking out the default head branch and performing a repo sync after that does not guaranty you will have all the repositories and branches log. Depending on what branch of the manifest you checkout the list of repositories and branches of those repositories will be different. Not only that but git behaviour is such that when cloning a repository remote branches are mapped to refs/remotes/origin/ (and cloning again from that will make also these disappear).
To properly clone the whole repository we need to use a special manifest that contains references to all existing branched (https://android.googlesource.com/mirror/manifest)
and checkout the git repositories in “bare” mode read git help clone and search for the mirror and bare options.
git help clone
...
--mirror
Set up a mirror of the source repository. This implies --bare. Compared to --bare,
--mirror not only maps local branches of the source to local branches of the
target, it maps all refs (including remote-tracking branches, notes etc.) and
sets up a refspec configuration such that all these refs are overwritten by a git
remote update in the target repository.
--bare
Make a bare GIT repository. That is, instead of creating <directory> and placing
the administrative files in <directory>/.git, make the <directory> itself the
$GIT_DIR. This obviously implies the -n because there is nowhere to check out
the working tree. Also the branch heads at the remote are copied directly to
corresponding local branch heads, without mapping them to refs/remotes/origin/.
When this option is used, neither remote-tracking branches nor the related
configuration variables are created. https://groups.google.com/d/msg/android-building/T4XZJCZnqF8/NULYcw7GOGsJ
repo init -u https://android.googlesource.com/mirror/manifest --mirror
Note that it's mirror/manifest instead of the usual platform/manifest.
Once you have a manifest, you can repo init new clients from it, e.g.:
repo init -u <mirror>/platform/manifest.git -b android-4.0.1_r1Once you have cloned a full repository it is possible to checkout different versions using the above explanation
or “simply” setup a git server.
git daemon --base-path=ics --export-all --enable=receive-packThis will work for simple development but is not good enough to host work for a company. The downloaded repository
needs to be hosted on a “real” server (like github or http://gitorious.org/) .
What can be done is the followin, install a gerrit server as this will give you
an easy setup and upload all the repositoy used by android.
Create a file called “gitup”
kejo@kejo-fakedistro:~/bin$ cat gitup
#!/bin/sh
ssh gerrit gerrit create-project --name android-main/$REPO_PATH --owner android-main
git push gerrit:android-main/$REPO_PATH +refs/heads/* +refs/tags/*
and execute the following to create gerrit projects and upload the code to gerrit.
repo forall -c ~/bin/gitup
Some more interesting pointers:
http://www.excentral.org/archives/2011/02/24/android-repo-mirroring
Here the guy use an option called —reference=/path/to/home/android/mirror/ this is probably something you need to do to properly track upstream work.
If you create a file call .gitconfig in your home directory with the following content (TODO find where I found this myself) you will get a set of handy command aliases that will allow you to use the gui a little less e.g. git lola will give you the same diagram as above).
[color]
ui = auto
[color "branch"]
current = yellow reverse
local = yellow
remote = green
[color "diff"]
meta = yellow bold
frag = magenta bold
old = red bold
new = green bold
[color "status"]
added = yellow
changed = green
untracked = cyan
[user]
name = First LastName
email = first.lastname@gmail.com
[alias]
st = status
ci = commit
br = branch
co = checkout
df = diff
lg = log -p
lol = log --graph --decorate --pretty=oneline --abbrev-commit
lola = log --graph --decorate --pretty=oneline --abbrev-commit --all
ls = ls-filesFrom https://groups.google.com/forum/?fromgroups#!topic/android-platform/QhrA3RayT-U
a list of directories and their usage
bionic - Standard C library for Android device / emulator
bootable - bootloader, installer and other device booting stuff
build - All the build utils and scripts... in particular
- core/combo - Defines the settings for each type of device (e.g. porting)
cts - the Android testing framework
dalvik - the Android VM... in particular
- vm - the libdvm library
- libdex - the DEX file format library
- dalvikvm - the executable 'dalvikvm' linked to libdvm
- libnativehelper - the Java JNI library
development - emulator, simulator, and stuff for the NDK and SDK
device - files specific to particular vendors' devices
external - all the external source code for various libraries and tools - includes 'Skia' the Android graphics core
frameworks - the Android framework library (both Java and native code)... in particular
- base/core/jni - Core JNI code (bridge between Java and C/C++)
- base/core/java - Core Java source code
- base/services/java - Core Android 'services'
- base/cmds/ - Essential commands (typically C++) - includes 'runtime' (for simulator?), 'system_server' for booting the core Android components from Java, and 'servicemanager' which 'binds' the services together through the Binder IPC mechanism - like an naming service
- base/media - all the media libraries
- base/opengl & base/graphics - graphics libraries
- libs/binder - the Binder IPC framework
- base/policy - policy components
- base/telephony - phone and telephony components
- base/native - additional native libraries (keyboard, graphics, etc)
hardware - libraries for basic hardware support - in particular
- libhardware/modules/gralloc - framebuffer driver
- libhardware_legacy - power, vibration, wifi drivers
libcore - the Harmony Java Virtual Machine - which Dalvik uses for its Java API... in particular
- luni/src/main/java - Java code for Java libraries
- luni/src/main/native - Native C/C++ code for Java libraries (through JNI bridge)
ndk - Native Development Kit (for developing native applications)
out - the directory where all 'host' and 'target' build files are kept... in particular
- host/<os>/bin - utilities for host building, including the 'simulator' (on Linux only)
- (debug?)/target/product/generic/system - the target system file system
packages - 'applications' and 'providers' to be packaged into .apk files
prebuilt - all the pre-built tools for cross-compiling
sdk - the Android Software Development Kit (for application developers)
system - core system libraries and utilities. In particular...
- core/liblog - logging
- core/libcutils - addtional C functions - also 'zygote' which takes care of some forking new Dalvik processes
- core/toolbox - typical UNIX utilities
- core/init - the 'init' process for native boot sequence
- core/libpixelflinger - low level pixel graphics rendering
- core/netd - the 'netd' network daemon
- core/vold - the 'vold' volume management daemon
- core/wlan - additional Wireless LAN drivers