Vanilla AOSP

[danielfullmer]

First, I wanted to thank you for your work on this. It's gotten me started with building android roms in nix a lot faster than otherwise.

I made a fork at https://github.com/danielfullmer/NixDroid with a vanilla branch that includes some recent work I've done for building vanilla-ish AOSP roms.

Specifically, my goals included:

• Staying as close to upstream AOSP as reasonable. I want it to be easy to use the latest security fixes from the frequent upstream google releases.

• Work with Pixel 1-3 (XL) devices. I have a Pixel XL and a Pixel 3 XL to test on.

• Use secure boot with a locked bootloader using user-generated keys.

Some related projects that I took inspiration from were GrapheneOS, RattlesnakeOS, and HashbangOS.

The code in my branch is a work in progress--but it at least builds working ROMs for me.

A few notable changes:

• I don't want my keys to end up in the nix store. So I generate a "release script" that one can use outside of nix to finish signing target files and generating ota/img files.

• Uses android-prepare-vendor to extract firmware blobs, etc. from a google image instead of using TheMuppets repo.

• Uses a different updater

• Uses a user-provided MonochromePublic.apk to provide chromium and webview.

Some remaining things I still need to do:

• Build chromium for android from source in nix. (This is definitely nontrivial--even just to fetch the sources)

• Use hydra (or at least some way to automate updating and rebuilding)

Since building lineage-based roms and vanilla AOSP roms is somewhat different, I'm not sure how much of these changes could or should be incorporated into your version of NixDroid. I have quite a lot of custom logic in default.nix specific to my use case. Some of this could be separated out, but it's not clear to me what a good end-user API should look like for this. One interesting possibility would be to use the module system like in NixOS for configuring a build.

[ajs124]

No need to thank me. I published this thinking it might be handy for someone, but I honestly didn't think it would. So thank you for disproving me on that.

The changes you made look quite interesting and I'll definitely try to merge at least some of them, when I can find the time.

I do however have some comments on what you outlined, just so we're on the same page:

* I don't want my keys to end up in the nix store. So I generate a "release script" that one can use outside of nix to finish signing target files and generating ota/img files.

They already shouldn't, the way NixDroid was built. My solution was to use a sandbox exception, which isn't particularly clean, but it should work.

* Use hydra (or at least some way to automate updating and rebuilding)

That's what this folder is for. It declarativly configures a hydra instance to build a ROM with NixDroid.

[danielfullmer]

Ah, I didn't realize you had a sandbox exception for the keystore. Yes, I did notice the hydra stuff you currently have. I just haven't tried it out yet--which I intend to do soon.