Build Android (AOSP) using Nix
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/hostsfile - 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).
Here is a single command to build an
imgwhich 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 imgThe 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.
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
/tmpis 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
--coresoption for
nix-buildto 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.
A configuration file should be created for anything more complicated, including creating signed builds. See my own configuration under
example.nixfor 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
keysdirectory 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 ./keysOne advantage of using a release script as above is that the build can take place on a different machine than the signing.
nix-copy-closurecould 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)/keysThis, 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-userin
nix.conf. Additionally, the nix builder will also need read access to these keys. This can be set using
chgrp -R nixbld ./keysand
chmod -R g+r ./keys.
See
docs/installation.mdfor details on flashing and updating for Pixel devices.
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.
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
releaseScriptoutput. If instead, you are signing builds inside nix with the sandbox exception, the desired output can be built using
nix-build ... -A otaDir.
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.nixfor 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
otafiles have all been verified to be bit-for-bit reproducible for
crosshatchand
marlinusing the
vanillaflavor. 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
imgand
otafiles. 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 may be enabled by setting
flavor = "lineageos";. The typical LineageOS flashing process involves first producing a
boot.imgand
ota, flashing
boot.imgwith fastboot, and then flashing the
otain recovery mode. The
boot.imgand
otatargets can be built using
nix-build ... -A bootImgor
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
vanillaand
grapheneosflavors. 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,
userdebugas 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!
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 $ ./resultThis currently only works well when using the generic
x86_64device.
Robotnix supports two alternative approaches for fetching source files:
pkgs.fetchgit. This is the default. An end user wanting to fetch sources not already included in
robotnixwould need to create a repo json file using
mk-repo-file.pyand set
source.dirs = lib.importJSON ./example.json;
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
drvs themselves depend on the source, and
nix-copy-closureof even just the
.drvfiles would require downloading the source as well.
Optional CCACHE stuff. As root: ```console
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.
3GEtqfkPkSSrRFpdcfy4T6YALgTwRyufip
.The #robotnix
IRC channel on Freenode is available for a place to chat about the project, ask questions, and discuss robotnix development.