OTA update model
Two update tracks (OS + apps), four ring sizes, soak periods, auto-rollback. How a VelaOS release reaches your fleet without 3 AM pages.
Two update tracks
VelaOS separates OS updates (the VelaOS ROM itself) from app updates (APKs deployed to devices). They use different mechanisms.
OS updates — A/B partition switching
VelaOS ROM ships with two system partitions (system_a and system_b). At any moment one is active and the other is idle. An OTA writes the new image to the idle partition, then on next boot the bootloader switches to it. If the new system fails to boot, the bootloader reverts to the previous partition automatically after three failed attempts.
Maturity: in development
ota_updatecommand but it logs-only. Current updates are delivered by re-flashing SD cards.App updates — ring deployment
App APKs deploy via MQTT app_install commands. Releases move through four rings:
- canary — 1-5% of fleet, 24h soak
- pilot — 10-20%, 48h soak
- broad — 50-80%, 72h soak
- global — everyone else
Each ring has a configurable failure threshold (default 5%). If the install error rate exceeds the threshold during the soak period, the rollout auto-pauses. You see the offending device(s) and decide to skip them, resume, or rollback.
Rollback prevention
Both tracks enforce no downgrades. The agent refuses any install where the incomingversionCode is less than or equal to the currently installed version. This prevents exploit attacks that try to revert security patches.
If you really need to roll back (emergency), use the Rollback button in the release page. It publishes the previous versionCode with an explicit override flag.
Delta updates
App updates transfer only the diff between the installed version and the new version using Android's built-in delta support. For a typical app, this means 5-15% of the full APK size over the wire.
OS updates will use bsdiff-based image diffs (v3.0+). Current plan: base image ~900 MB, typical monthly patch ~40 MB.
Scheduled updates
OS updates respect the device's maintenance window set in policy.system.update_window_start and update_window_end (minutes since midnight). Outside the window the agent downloads the image but does not apply it until the window opens.