design and implement a much better / simpler over-the-air update system for A/B devices

[thestinger]

The server will only serve static files, rather than having any dynamic content. The server can provide the necessary metadata to pass the updates directly to update_engine, rather than needing to handle downloads. Each per-device channel will have a separate release index file with metadata. It will use an extremely simple line-based format with space-separated fields. It could use JSON, but there's not much point in adding that as a dependency since it will end up requiring more complexity in Java.

The update client will perform frequent automatic checks for updates with automated downloads/installation as a single step via update_engine. The only necessary user interface is a persistent notification informing the user that they need to reboot once an update is complete. It can time out after a given interval like 24 hours and force the reboot itself as soon as the device becomes idle.

The client will support changing the update channel via a system property writable by the shell user. This will be initially be used to test the future upgrade path before doing releases, just as we do it for the current updater.

As with the current updater, it will use incremental updates if one is available from the current version to the target version, falling back to a full update. There will continue to be incrementals generated for the past three versions, which generally covers 2-4 weeks.

[jjardon]

Maybe this could be based on ostrer? https://ostree.readthedocs.io/en/latest/

[jjardon]

Maybe this could be based on ostrer? https://ostree.readthedocs.io/en/latest/

[thestinger]

Android already provides the best available update infrastructure via update_engine. The only part that needs to be implemented is some high-level code wiring it up to an update server. Anything not providing block-based updates including block-based delta (incremental) updates wouldn't be able to support verified boot and new devices also have the A/B partitions so it wouldn't make sense not to use them. The major advantages of the new mechanism on the Pixel phones are reliability (rolling back to the other set of partitions automatically if the new version fails to boot) and automation / user experience (fully automatic updates in the background, only requiring a normal reboot without an install step before or after boot to become active). It's the update system from ChromeOS which was adopted by Brillo (Android Things) and now Android itself.

https://source.android.com/devices/tech/ota/ab_updates.html

[thestinger]

Android already provides the best available update infrastructure via update_engine. The only part that needs to be implemented is some high-level code wiring it up to an update server. Anything not providing block-based updates including block-based delta (incremental) updates wouldn't be able to support verified boot and new devices also have the A/B partitions so it wouldn't make sense not to use them. The major advantages of the new mechanism on the Pixel phones are reliability (rolling back to the other set of partitions automatically if the new version fails to boot) and automation / user experience (fully automatic updates in the background, only requiring a normal reboot without an install step before or after boot to become active). It's the update system from ChromeOS which was adopted by Brillo (Android Things) and now Android itself.

https://source.android.com/devices/tech/ota/ab_updates.html

[thestinger]

The foundation is in place: https://github.com/CopperheadOS/platform_packages_apps_Updater.

[thestinger]

The foundation is in place: https://github.com/CopperheadOS/platform_packages_apps_Updater.