Here is some context of my thoughts so that they are visible to others even without a meeting at the ccc congress.

My ultimate goal is, as one would expect from a Nix/NixOS lover, to turn my mobile device into a nice reproducible nix environment. I want to use NixOS primarily on the go, but because the day‑to‑day requirements and the still‑unrefined mobile optimizations are unlikely to be practical in the near future, I believe it makes sense to invest my time in robotnix instead.

My first attempts with robotnix are already satisfying thanks to your work, though a few essential components are still missing, which makes it less usable at present. Please excuse any incorrect assumptions I may be making because I haven’t fully understand robotnix yet—feel free to correct me.

I’ve also noticed that the current Flake structure, while providing a clearer separation between library functions, modules, and packages, suffers from one major issue: everything is built in a single large derivation. This makes it difficult to leverage binary caches, which in turn keeps build times high.

I read the documentation at https://github.com/nix-community/robotnix/blob/master/docs/src/building.md#binary-cache, but quickly realized that the components required for that, listed in https://github.com/nix-community/robotnix/blob/master/release.nix#L53, appear to be missing.

I tried to trace the implementation in the repository (https://github.com/nix-community/robotnix/blob/master/modules/base.nix) based on your talks and took a closer look at Android’s Soong build architecture at https://source.android.com/docs/setup/build. Unfortunately, I couldn’t find the solutions you suggested in your talk in the repo, which makes me think there are reasons why they haven’t been pursued further.

My first idea was to abstract the components listed in https://github.com/nix-community/robotnix/blob/master/components.json into individual packages via a lib function for mkAndroid and mkAndroidComponent, so they could be made available as a binary cache. If this hasn’t been implemented yet only due to time or support constraints, it would be great to discuss it before I invest unnecessary effort and test my ideas—so I don’t fall into the same problems again.

If anyone here already has thoughts on these topics, feel free to share them. I’ll try to document and transfer them to a new docs page. During a ccc congress meetup we can then dive into the details together.