My revised/experimental Android build functions



I have created an experimental branch in the nix-androidenvtests repository ( that contains a revised implementation of the androidenv component in Nixpkgs.

I have the following objectives:

  • I generate all Nix expressions from the latest versions of the XML configuration files in the Android repository: repository2-1.xml, addon2-1.xml etc.
  • I try to generate as much as possible from the metadata in the Android repository. As a result, it should no longer be required to manually update URLs or hashes. In the old repository, some repos still have to be packaged and configured manually.
  • I also try to integrate as many plugins as possible. Thanks to the fact that more stuff can be automatically derived from the newer XML configuration files (e.g. such as the target paths in the SDK) I can more easily integrate plugins. A lot more optional stuff should be supported now.
  • The androidenv use cases (that I currently care about) are now properly documented in the file. You should no longer rely on my blog posts (that are not kept up to date) to know how to functionality in the androidenv should be used.
  • The patching of the executables is now mostly automated. You should not directly invoke patchelf anymore, but an auto patcher tool (, that is smart to figure out which libraries an executable requires and the libraries that need to be linked to them. Its functionality is comparable to autopatchelf in stdenv, but goes a few steps beyond that – it can also cope with repos that have mixed 32 and 64 binaries and so on.
  • I also use a number of interesting function abstractions to integrate all functionality more conveniently. This, for example, makes it possible for the androidenv.buildApp {} function to configure all possible Android plugins with relatively small effort. I will write about these abstractions soon.

At the moment, it should be relatively usable, but the repository should still be considered experimental. I have not tested all possible combinations of plugins, so certain features may be broken. So far, all use cases that matter to me seem to work.

I have also decided to develop this androidenv component separately as opposed to forking Nixpkgs, because that makes testing against a changing repository more convenient.

Eventually, the goal is to reintegrate this back into Nixpkgs and to get the remaining use cases supported, such as the Gradle builds and cross compiling.

Feel free to try it. At the moment, it is not my goal yet to get the other missing use cases implemented, but if the current functionality is mature enough, I will fork Nixpkgs and work on a reintegration strategy.


Does autoPatchelfHook not also support different architectures? At least the code reads as if it was supported:


It does prevent libraries from an incompatible architecture to get linked to a binary, but you can’t specify for each architecture the library search paths you want to consider.


how do I use it? this header looks strange to me {androidenv}:





let androidenv = import /path/where/you/checked/out/androidenv;
in …

I haven’t tested it, but the symbols match up.


As I tried the emulator example, nix-build yelled this error: value is a function while a set was expected


Ah, it should have been let androidenv = import /path/where/you/checked/out/androidenv {};


@myguidingstar Yes that’s correct. Typically you want to have another composition expression that invokes androidenv.


@sander have you tried it with React Native? There’s a guide here that copy sdk to a writable directory. What do you think?


Figured it out myself. We don’t have to creat a writable dir like the above link. Instead, set ANDROID_HOME to "${androidComposition.androidsdk}/libexec/android-sdk"


how do I set emulator to a specific device, eg a Nexus 5?


I have created my own fork of Nixpkgs that reintegrates the changes to the Android build environment and other mobile app build functionality. It can be found here:

The changes are fairly complete. We need to change a few subtle things (e.g. buildGradleApp).

The biggest challenge is to make stdenv.cross work again. Since I do not cross compile much and I haven’t touched this code very much, I could use some help in getting this functionality fixed.

Please let me know if there is anything else that may break and requires fixing.


I’m very excited about this.


I think we’re close now to reintegrating the changes back into Nixpkgs. The only showstopper is the fact that cross compilation to Android will be broken, for which I need help.

The other issue is that the androidenv.buildGradleApp function is still not ported. I don’t use this function myself, and I don’t have the means to validate it. I did not receive any comments about it yet (or any fixes), so I assume that it’s not extensively used. Furthermore, since there is no gradle2nix yet (or at least an implementation that works) I think this function is also quite limited, because it can’t use any external dependencies in a pure build environment.

Anyway, if somebody thinks that the buildGradleApp function is a showstopper then please let me know.


I now managed fix the cross compiling. I now removed the WIP status of the pull request. This means I now consider it ready to be integrated.

I’ll wait for a little while so that people can still provide feedback, but I intend to integrate these changes soon.


I just merged the mobile updates branch into master. It should now be possible to use all the new features: the latest Android SDK, more Android plugins, new function interfaces that support more options and easier maintenance. Furthermore, all binaries are patched with the autopatchelf hook.

Another bonus: proper documentation describing how to use the mobile functionality in the Nixpkgs manual.