Skip to main content

OS Release Process

Build​

We have a "nightly" build system in place to ensure code integrity.

Regression​

Once a new version is intended for release, a regression testing process is started by our QA team.

Internal Release​

After the build is greenlit, it is pushed to all Almer internal devices such that the update can face real world conditions.

Public Release​

Afterward, generally following a week of soak time from the internal release date, the build is promoted to public release and pushed to all users.

How the device updates​

Almer Arcs periodically check for updates on the Memfault platform. If a new OS is available:

  • The new OS is downloaded using the standard Android update component
  • The OS's signature is checked against the one currently installed in the OS. If this does not match, the OS is not installed.
    • Note that the signature is based on a private key securely stored in the Almer build infrastructure

Back-up​

In the extremely unlikely case of a failed update or of a faulty one, the device has a system to account for this. Each OS update is installed on a separate partition from the currently installed OS. This ensures the old OS remains untouched and serves as an automatic fallback.

Last updated on