android: Add flashable zip output

[samueldr]

Whew, this is a bit of a fun PR!

The gist of it is that this adds an output for Android flashable zips, confirmed to work with TWRP.

 $ nix-build --argstr device $DEVICE -A build.android-flashable-bootimg

Obviously, limited to Android-based devices.

I don't think this is going the main way to flash Android-based devices, but it is a way. For amonet-using devices, (e.g. amazon hardware), it will be easier as amonet does some required shenanigans to add an exploit when flashing through TWRP.

Though, in a future where this is building usable "appliance" systems, this may very well be the main installation method that community using Mobile NixOS as a build framework uses to install things!

TODO

• Implement A/B devices install (known how)
• Try some shenanigans for "fill as it flashes" progress bar
• Write documentation for using flashable zip as an installation method for Android-based devices
• Add android-flashable-zip-binaries to tested; it exercises pkgsStatic which sometimes has hiccups. Though armv7l cross to testedPlus.

---

Android Flashable Zip Binaries

What is this? It's the interpreter and framework for the script that does the flashing.

Basically, my good friend mruby, again. With some helper functions to make a unique binary build per platform.

This, in turn, executes a Ruby DSL that describes a plan. This plan is validated before being executed. Once all parts are found to be okay, it then executes the flash.

Useful as it would e.g. bail on trying to flash a system.img that is too big, before even flashing the boot.img assumed to fit.

I see some shenanigans

That's not a section title.

But indeed, there are shenanigans!

I do not trust all recoveries to ship with a usable unzip binary. It is not part of the API. Normally you should use Edify to unpack things.

The recovery will unzip only one file from the zip file. How can you unzip a file, e.g. a static unzip binary, if you don't have unzip?

Well, maybe you already unzipped it!

Here unzip is part of a customized busybox build. It is (mostly) simply appended to the main script binary. Mostly?

Here's the rub: how fun is it to scan a binary to figure out where another is? Not much. It could have been added as a symbol in C, but is that fun to write? Not really. What if, instead, we appended a third element, a simple uint32_t with the offset to dump from? Now we're talking!

+-0x00000-----------+
| ELF script-loader |
|       [...]       |
|                   |
+-0xABCDE-----------+
| ELF busybox       |
|       [...]       |
|                   |
+-0xZZZZZ-----------+
| 0xABCDE           | <- uint32_t with the offset for busybox.
+-------------------+

So the script, first looks at the last four bytes of itself, reads it as an offset, reads from that offset up to the last four bytes. And here it is, a busybox we handily got extracted by the recovery for us!

---

CC-ing android device maintainers, if possible, could you boot TWRP or another recovery and validate adb shell getprop ro.product.device gives the expected value? (The one I set for mobile.system.android.device_name) I used two sources that I believe are trustable for the values.

cc @lheckemann (xiaomi-tissot)
cc @danielfullmer (google-marlin)

[samueldr]

It looks like flashing through TWRP is not enough to reset the boot count for A/B devices.

This is out of scope of this PR, but will be handled soon with generic A/B support.

If the boot count was already 0, the flashed boot image will fail. In TWRP, switch back and forth between current/non-current slots to reset the boot count, and it should work.

There are multiple things to consider doing:

• Reset count numbers but not mark as valid when flashing
• Create a cheaty "mark current as valid" flashable zip
• Support marking boot image as valid during boot (when, how?)

[samueldr]

And with this last update, the progress bar updates for each block flashed!

Totally not needed, but a real nice to have, since it was mostly free.

[samueldr]

Suggested change

# TODO: select only desired applets.

[samueldr]

This was tested against NixOS/nixpkgs@56bb1b0. Tested to build and work for aarch64 and armv7.

Recent master checkouts seems to cause new issues in pkgsStatic and armv7. Though it looks like for aarch64 it is fine. Odd.