At this point, Robotnix is not ready for daily use. Treat it as in-development alpha software.

The status section contains more detailed information on which components are expected to work.

Robotnix enables a user to easily and reliably build Android (AOSP) images using the Nix package manager / build tool.

Here is a single command to build an img which can be flashed onto a Pixel 3 XL (crosshatch).

$ 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 publicly known 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 <img.zip>.

Android 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 included in the Android build, such as the Linux kernel, Chromium webview, MicroG, other external/prebuilt privileged apps, etc. Robotnix orchestrates the diverse build systems 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 12 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
• 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

More detailed robotnix documentation is available at https://docs.robotnix.org, and should be consulted before use.

Robotnix was presented at Nixcon 2020, and a recording of the talk is available here. Slides for the talk are also available here.

The AOSP project recommends 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 45GB free disk space to check out the android source, ~14GB for chromium, plus ~100GB of additional free space for intermediate build products. By default, Nix uses /tmp to store these intermediate build products, so 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.

Robotnix also requires support for user namespaces (CONFIG_USER_NS Linux kernel option). Currently, using the "signing inside Nix with a sandbox exception" feature also requires a Nix daemon with the sandbox support enabled. This feature is currently not supported inside Docker for this reason.

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.

The #robotnix:nixos.org channel on Matrix is available for a place to chat about the project, ask questions, and discuss robotnix development. You can easily join the channel using the Element web client via this link.

This table documents the current status of Robotnix' components.

Note that the "Maintained" column reflects whether there has been an effort to maintain the component in the past few years. "Maintained" components can be expected to work and not have fallen into disrepair but, until this project is under active maintenance again, no component can be expected to be reasonably up to date.

This table primarily exists to show the opposite: which components cannot be expected to work or might even be removed in the future; to set the right expectations.

This project is available as open source under the terms of MIT license. However, for accurate information, please check individual files.