# crDroid Android: building the 17.0 branch from source

> The crDroid android repository is not an operating system tree but a manifest that points the Google Repo tool at every project crDroid patches, so a build begins with repo init and repo sync rather than a git clone. The README covers the full path from dependencies to a per device image, including the overlays and build flags that carry crDroid specific features.

**crdroidandroid/android** — Build crDroid and some general information 

- Repository: https://github.com/crdroidandroid/android
- Stars: 714 · Forks: 282
- Language: Unknown
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/crdroidandroid-android

## A manifest, not an operating system tree

The crDroid android repository is the starting point for building crDroid, and its shape explains everything about the workflow. The top level holds only three things: README.mkdn, default.xml and a snippets directory. default.xml is the manifest, the file that tells the Repo tool which projects make up the tree and where each one comes from.

That is the whole point of the design. Building an Android distribution means assembling many separate git repositories, and the Google Repo tool, described in the README as a tool provided by Google that simplifies using Git in the context of the Android source, is what does the assembly. You do not clone this repository and edit it. You point Repo at it.

The default branch is 17.0, which names the Android version this manifest targets, and the README is explicit that you initialise that branch. Everything specific to crDroid, the extra features, the overlays, the translations and the forum template, lives in sibling repositories such as android_frameworks_base and crdroid_features, which is why this repository stays small enough to read in one sitting.

So the audience is a builder, not a developer of the distribution. If you want to run crDroid on a device, this is the tree that produces the image.

## The dependency list is long and specific

The first step before any source is fetched is a package list. The README gives an Ubuntu example, and it is a long one:

```bash
sudo apt install bc bison build-essential ccache curl flex g++-multilib gcc-multilib git git-lfs gnupg gperf imagemagick lib32ncurses-dev lib32readline-dev lib32z1-dev liblz4-tool libncurses6 libncurses-dev libsdl1.2-dev libssl-dev libwxgtk3.2-dev libxml2 libxml2-utils lzop pngcrush rsync schedtool squashfs-tools xsltproc zip zlib1g-dev
```

The README notes that some of those packages may need adjustment for your Linux distribution, which is the usual caveat, but the list is specific enough to be useful: the 32 bit libraries and compilers are there because a chunk of the Android build still expects them, ccache is there because the build is long, and squashfs-tools, lzop and liblz4-tool are image packing tools.

The Repo tool itself is installed by hand into a directory on your PATH:

```bash
# create ~/bin and add to PATH for this session (or add to your shell profile)
mkdir -p ~/bin
export PATH=~/bin:$PATH

# download Repo
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo

# make Repo executable
chmod a+x ~/bin/repo
```

The downloaded file is a script that is made executable with chmod a+x, and the README suggests adding the same export line to your shell profile so that Repo is still available in later sessions.

## repo init and repo sync, with flags for interrupted runs

Creating the workspace and pointing it at the crDroid manifest takes two commands:

```bash
mkdir -p ~/crDroid
cd ~/crDroid
repo init -u https://github.com/crdroidandroid/android.git -b 17.0 --git-lfs --no-clone-bundle
```

The flags are worth reading rather than copying blindly. The -b 17.0 selects the branch, --git-lfs enables Git LFS support, which the tree needs because some projects carry binary assets, and --no-clone-bundle skips the initial bundle download that Repo would otherwise use to speed up the first sync.

Then the tree is fetched, which the README warns may take a long time on the first run:

```bash
repo sync
```

Two flags are given for the awkward cases. When a sync is interrupted, or you simply want a fresh copy, the recovery command is `repo sync --force-sync --no-tags --no-clone-bundle -j8`, with the note to adjust the -j value to match your bandwidth and CPU count. And `repo sync -c` limits the sync to the current branch per project, which the README says saves time and space when that is appropriate.

One consequence of the Repo model is that the manifest is a moving target. Every sync pulls the current tip of every project it names, so two people syncing on different days get different trees unless they pin commits themselves, and the README does not describe a way to pin a known good build.

## envsetup.sh, brunch and a hundred gigabytes of disk

The build itself is short in the README and heavy in practice. You prepare the environment and then name a device:

```bash
. build/envsetup.sh
```

```bash
brunch <devicecodename>
```

The device codename is the argument, and the README suggests values such as `caiman` or `lemonadep`. The first command sources the environment script that puts the Android build tools on your PATH and sets up the environment variables the rest of the build expects, and the second is the actual image build for that device.

The resource requirement is the part that catches people out. The README warns that an Android tree can require 100 GB or more of free disk space, and mentions the out of disk space failure explicitly. The recommendation when a build fails after a sync is to force a fresh sync with `repo sync --force-sync` and then do a clean build with `mka clean` before rebuilding.

That two step recovery tells you something about the failure modes. A build that fails after a sync is often failing on a tree that is in an inconsistent state rather than on your own edits, so the fix is to re-fetch everything and start from a clean output directory instead of hunting for the broken commit.

## Overlays and device.mk flags are where crDroid lives

The customisation model is overlay based. The README describes setting overlays to the proper paths, and gives two concrete examples. For the base framework it is:

```text
overlay/frameworks/base/core/res/res/values/config.xml
```

And for SystemUI it is:

```text
overlay/frameworks/base/packages/SystemUI/res/values/config.xml
```

Each is paired with a reference to the matching cr_config.xml in the crDroid android_frameworks_base repository, so the pattern is: you write a config.xml into the overlay path, and the framework picks it up in preference to the stock one. That is the standard Android overlay mechanism, and crDroid uses it to change framework defaults without forking the framework itself.

The build flags follow the same philosophy, with two documented switches. A device that cannot render blur at all disables the support in its device.mk:

```text
TARGET_SUPPORTS_BLUR := false
```

And a device that does not ship the OEM face recognition feature can turn on the crDroid one:

```text
TARGET_FACE_UNLOCK_SUPPORTED := true
```

Both are per device decisions rather than global ones, which is the important structural point. A feature such as blur costs rendering performance on some hardware, so each device tree has to opt in or out, and the ROM you get depends on decisions made in a repository you may never open.

## Blur is a runtime property, not only a build flag

Beyond the build flags there is a runtime property, and the README explains it in terms of hardware cost rather than a boolean choice. If a device supports blur but rendering it is expensive, the default blur is disabled with this property:

```text
ro.surface_flinger.blur_disabled_by_default=true
```

So there are two separate decisions about blur. The compile time flag decides whether the device tree supports the feature at all, and the property decides whether it is on by default at run time. A device can ship with blur available but switched off until the user or another component turns it on.

The README also points at two example commits for the case where blur is visible but ugly. One disables high performance transitions and the other reduces the blur radius, and both are linked as concrete diffs in a device tree, which is a useful pattern to copy rather than a setting to type.

Translations are handled through Crowdin, with the pointer to the crdroid_features repository for the details, and the forum post template lives in that same repository under a ForumPostTemplate path, so a builder who wants their build announced has a ready made post format.

## Contributions go to the organisation, not to the manifest

The contribution guidance is brief but it points somewhere specific. To submit changes or patches you fork the repository on GitHub, make your changes and open a pull request against the appropriate branch, and the README says the project reviews pull requests and merges them when appropriate.

The maintainer path is separate and personal. The rules and guidelines live in a crdroidandroid rules-and-guidelines repository, and if everything is in order the README says to message Gabriel on Telegram at the address it links. There is no automated process described for that, which is a signal about how the project is run.

For the manifest repository itself, the practical rule is that it changes when the set of projects changes: a new device tree, a new platform fork, a change of branch. Day to day feature work belongs in the fork repositories that the manifest points at, which is why the README spends most of its length on the build path rather than on the manifest contents.

One structural detail is worth noting for anyone auditing the tree. The README does not list a licence for the manifest, and the licence of the projects it points at is set by those projects, since the manifest is only a list of URLs and revisions. If you need to know what you can ship in a product built from this, the answer lives in the individual upstream projects, not in this repository.

## Conclusion

Adopt this manifest if you intend to build crDroid yourself for a specific device, since the repository gives you the exact branch, the overlay paths and the build flags, and nothing else in the tree is a dependency of yours. Do not adopt it as a place to contribute device trees, since the pull request guidance points at the crDroid organisation rather than this manifest, and do not start a build without a device whose codename appears in the crDroid tree, because brunch has nothing to build otherwise. Verify first that your machine has the disk and the package set the README names, that the 17.0 branch is the one you want rather than another line, and which crDroid features you will turn on through overlays, since the blur and face recognition switches are per device and are not enabled by default.

## FAQ

### How do I build crDroid from source?

Install the listed packages, install the Repo tool into a directory on your PATH, then create a workspace and run repo init -u https://github.com/crdroidandroid/android.git -b 17.0 --git-lfs --no-clone-bundle, followed by repo sync. Then source build/envsetup.sh and run brunch with your device codename.

### What disk space does a crDroid build need?

The README warns that the Android tree can require 100 GB or more of free disk space, and lists running out of disk as a known build problem.

### How do I disable blur on a crDroid device?

If the device cannot render blur at all, set TARGET_SUPPORTS_BLUR := false in device.mk. If it supports blur but rendering it is expensive, set the property ro.surface_flinger.blur_disabled_by_default=true instead, which switches the default off at run time.

### How do I recover a crDroid build that fails after repo sync?

Force a fresh sync with repo sync --force-sync --no-tags --no-clone-bundle -j8, adjusting the -j value to your bandwidth and CPU count, then run mka clean and rebuild. The same command is what the README recommends for recovering from an interrupted sync.

## Sources

- [crdroidandroid/android on GitHub](https://github.com/crdroidandroid/android)
- [Issues](https://github.com/crdroidandroid/android/issues)
- [README](https://github.com/crdroidandroid/android/blob/17.0/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/crdroidandroid-android