This didn't end up being something that's being worked on. It probably
was entirely confusing for everyone as it wasn't documented, and didn't
actually do anything useful most of the time.
Rather than polluting the build with some one-off special cases like
this, we'll implement an "installer" as an example system, if we even
want an installer.
It's not planned yet *how* users should install, it may not even be an
installer type system.
This also rewords the "successful default build failure" message.
Instead of borrowing some of its system.build products, rely instead on
a full system.build for the recovery.img.
This allows us to better make use of the implicit declarativeness of the
system configuration. At some point the recovery "system" will be moved
out of that file and things will continue to work.
In addition, put the implementation of the build side-by-side with the
system type definition. It made no sense to keep those where they were,
as it was baggage from the earlier implementation of the project.
It didn't make sense to stuff that into systems anyway, it's baggage
from the first steps of making Mobile NixOS.
This is a *part* of depthcharge system type, so why stuff it into `system`
at the root??
It didn't make sense to stuff that into systems anyway, it's baggage
from the first steps of making Mobile NixOS.
This is a *part* of android system types, so why stuff it into `system`
at the root??
This script will flash the "critical" bits to the device.
Though note that this will flash both A/B slots unconditionally.
Similarly, this will flash both the boot and recovery partitions.
