danielfullmer/ robotnix

Python

Shell

Need help with robotnix?

Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

danielfullmer

140 Stars

15 Forks

MIT License

946 Commits

24 Opened issues

Description

Build Android (AOSP) using Nix

Services available

Need anything else?

Contributors list

Readme

robotnix - Build Android (AOSP) using Nix

Name: robotnix
Brand: robotnix
SKU: //danielfullmer/robotnix
Rating: 2.1 (140 reviews)

Robotnix enables a user to easily and reliably build Android (AOSP) images using the Nix package manager. AOSP projects often contain long and complicated build instructions requiring a variety of tools for fetching source code and executing the build. This applies not only to Android itself, but also to projects which are to be included in the Android build, such as the Linux kernel, Chromium webview, MicroG, other external/prebuilt privileged apps, etc. Robotnix orchestrates the diverse build tools across these multiple projects using Nix, inheriting its reliability and reproducibility benefits, and consequently making the build and signing process very simple for an end-user.

Robotnix includes a NixOS-style module system which allows users to easily customize various aspects of the their builds. Some optional modules include: - Vanilla Android 10 AOSP support (for Pixel devices) - GrapheneOS support - Experimental LineageOS support - Signed builds for verified boot (dm-verity/AVB) and re-locking the bootloader with a user-specified key - Apps: F-Droid (including the privileged extension for automatic installation/updating), Auditor, Seedvault Backup - Browser / Webview: Chromium, Bromite, Vanadium - Seamless OTA updates - MicroG - Certain google apps (currently just stuff for Google Fi) - Easily setting various framework configuration settings such as those found here - Custom built kernels - Custom

/etc/hosts

file - Extracting vendor blobs from Google's images using android-prepare-vendor

Future goals include: - Support for additional flavors and devices - Better documentation, especially for module options - Continuous integration / testing for various devices - Automating CTS (Compatibility Test Suite) like nixos tests. - Automatic verification of build reproducibility - Replacing android prebuilt toolchains with nixpkgs equivalents.

This has currently only been tested on crosshatch (Pixel 3 XL, my daily driver), sunfish (Pixel 4a), and marlin (Pixel XL, which is now deprecated by google and no longer receiving updates).

Quick Start

Here is a single command to build an

img

which can be flashed onto a Pixel 3 XL (

crosshatch

console
$ nix-build "https://github.com/danielfullmer/robotnix/archive/master.tar.gz" \
    --arg configuration '{ device="crosshatch"; flavor="vanilla"; }' \
    -A img

The command above will build an image signed with

test-keys

, so definitely don't use this for anything intended to be secure. To flash the result to your device, run

fastboot update -w

Requirements

The AOSP project requires at least 250GB free disk space as well as 16GB RAM. (Certain device kernels which use LTO+CFI may require even more memory) A typical build requires approximately 40GB free disk space to check out the android source, 14GB for chromium, plus some additional free space for intermediate build products. Ensure your

/tmp

is not mounted using

tmpfs

, since the intermediate builds products are very large and will easily use all of your RAM (even if you have 32GB)! A user can use the

--cores

option for

nix-build

to set the number of cores to use, which can also be useful to decrease parallelism in case memory usage of certain build steps is too large.

A full Android 10 build with chromium webview takes approximately 10 hours on my quad-core i7-3770 with 16GB of memory. AOSP takes approximately 4 hours of that, while webview takes approximately 6 hours. I have recently upgraded to a 3970x Threadripper with 32-cores. This can build chromium+android in about an hour.

Configuration and Build Options

A configuration file should be created for anything more complicated, including creating signed builds. See my own configuration under

example.nix

for inspiration. After creating a configuration file, generate keys for your device:

$ nix-build ./default.nix --arg configuration ./crosshatch.nix -A generateKeysScript -o generate-keys
$ ./generate-keys ./keys

This will create a

keys

directory containing the app and device keys needed for the build. Next, build and sign your release. There are two ways to do this. The first option involves creating a "release script" which does the final build steps of signing target files and creating ota/img files outside of nix:

console
$ nix-build ./default.nix --arg configuration ./crosshatch.nix -A releaseScript -o release
$ ./release ./keys

One advantage of using a release script as above is that the build can take place on a different machine than the signing.

nix-copy-closure

could be used to transfer this script and its dependencies to another computer to finish the release.

The other option is to build the final products entirely inside nix instead of using

releaseScript

console
$ nix-build ./default.nix --arg configuration ./crosshatch.nix -A img --option extra-sandbox-paths /keys=$(pwd)/keys

This, however, will require a nix sandbox exception so the secret keys are available to the build scripts. To use

extra-sandbox-paths

, the user must be a

trusted-user

nix.conf

. Additionally, the nix builder will also need read access to these keys. This can be set using

chgrp -R nixbld ./keys

and

chmod -R g+r ./keys

Installation

See

docs/installation.md

for details on flashing and updating for Pixel devices.

Binary Cache

Robotnix now has an optional binary cache provided by cachix. Currently, only the device kernels and browser builds are published through the binary cache. This is because these derivation outputs are most likely to be shared between users, and those outputs also can take a very long time to build. The build products previously discussed should be uploaded for at least every robotnix release tag. To use, install

cachix

, run

cachix use robotnix

, and then build robotnix like normal.

OTA Updater

The Over-the-Air (OTA) updater can be enabled using

apps.updater.enable = true;

. The URL that the updater will query for updates is set using

apps.updater.url = "...";

. This URL needs to point to a directory containing the OTA update file, as well as some metadata. Conveniently, these files are generated as part of the

releaseScript

output. If instead, you are signing builds inside nix with the sandbox exception, the desired output can be built using

nix-build ... -A otaDir

Testing / CI / Reproducibility

All devices (Pixel 1-4(a) (XL)) have very basic checks to ensure that the android build process will at least start properly. See

release.nix

for the set of configurations with this minimal build testing. This check is run using

nix-build ./release.nix -A check

. As each build takes approximately 4 hours--I only build marlin and crosshatch builds for myself. At some point, I would love to set up a build farm and publish build products on s3 or cachix. This would allow an end-user to simply sign releases using their own keys without building the entire AOSP themselves.

As of 2020-05-17,

target_files

signed_target_files

img

, and

ota

files have all been verified to be bit-for-bit reproducible for

crosshatch

and

marlin

using the

vanilla

flavor. Automated periodic testing of this is still desired.

One option being investigated is to have multiple independent remote builders produce unsigned target files for a number of device and flavor combinations. An end-user could then verify that the builders produced the same unsigned target files, and finish the process by signing the target files and producing their own

img

and

ota

files. This eliminates the requirement for an end-user to spend hours building android.

There are, however, a few places where user-specific public keys are included in the build for key pinning. This unfortunately decreases the possibility of sharing build products between users. The F-Droid privileged extension and Trichrome (disabled for now) are two components which have this issue. Fixes for this are still under investigation.

LineageOS Support

LineageOS support may be enabled by setting

flavor = "lineageos";

. The typical LineageOS flashing process involves first producing a

boot.img

and

ota

, flashing

boot.img

with fastboot, and then flashing the

ota

in recovery mode. The

boot.img

and

ota

targets can be built using

nix-build ... -A bootImg

nix-build ... -A ota

, respectively.

LineageOS support should be considered "experimental," as it does yet have the same level of support I intend to provide for

vanilla

and

grapheneos

flavors. LineageOS source metadata may be updated irregularly in robotnix, and certain modules (such as the updater) are not guaranteed to work. Moreover, LineageOS does not appear to provide the same level of security as even the vanilla flavor, with dm-verity/AVB often disabled,

userdebug

as the default variant, and vendor files with unclear origin. LineageOS support is still valuable to include as it extends preliminary support to a much wider variety of devices, and provides the base that many other Android ROMs use to customize. Contributions and fixes from LineageOS users are especially welcome!

Emulator

To build and run an emulator with an attached vanilla system image, use (for example):

console
$ nix-build ./default.nix --arg configuration '{device="x86_64"; flavor="vanilla";}' -A emulator
$ ./result

This currently only works well when using the generic

x86_64

device.

Fetching android source files

Robotnix supports two alternative approaches for fetching source files:

Build-time source fetching with
```
pkgs.fetchgit
```
. This is the default. An end user wanting to fetch sources not already included in
```
robotnix
```
would need to create a repo json file using
```
mk-repo-file.py
```
and set
```
source.dirs = lib.importJSON ./example.json;
```
Evaluation-time source fetching with
```
builtins.fetchGit
```
. This is more convenient for development when changing branches, as it allows use of a shared git cache. The end user will need to set
```
source.manifest.{url,rev,sha256}
```
and enable
```
source.evalTimeFetching
```
. However, with
```
builtins.fetchGit
```
, the
```
drv
```
s themselves depend on the source, and
```
nix-copy-closure
```
of even just the
```
.drv
```
files would require downloading the source as well.

Additional information

Optional CCACHE stuff. As root: ```console

mkdir -p -m0770 /var/cache/ccache

chown root:nixbld /var/cache/ccache

echo max_size = 100G > /var/cache/ccache/ccache.conf

Set `ccache.enable = true` in configuration, and be sure to pass `/var/cache/ccache` as a sandbox exception when building.

Notable mentions

See also: NixDroid, RattlesnakeOS, aosp-build, and CalyxOS

Donating to Robotnix

If you find Robotnix helpful, please consider donating to the project. Especially consider making a donation if you rely on regular Robotnix updates for your personal device. Donations will be used to support ongoing Android updates, developer hardware and build infrastructure, as well as future improvements. Your support is greatly appreciated.

My GitHub sponsors page is here.
Paypal donations may be made using this link.
Bitcoin donations may be directed toward 3GEtqfkPkSSrRFpdcfy4T6YALgTwRyufip.

Community

The #robotnix IRC channel on Freenode is available for a place to chat about the project, ask questions, and discuss robotnix development.