Skip to main content

Update Management (OTA)

HexDroid offers full update management solution for your feet (Android/AOSP, Linux, IoT, or even a software application).

HexDroid's update management solution simplifies the process of deploying software with advanced tools for managing rollouts, release payload configurations, and validation, you can ensure safe and reliable updates at scale.

Setup​

  1. Create your first release via web app or CLI app, refer to create release for next steps.
  2. Integrate Update SDK into your device/software, refer to update SDK for next steps.

Features​

Rollouts​

HexDroid offers phased rollouts, allowing you to gradually release updates to a limited group of devices before expanding to the entire fleet. Rollouts are managed by cohorts - groups of devices that you can control and assign as needed. This lets you determine which devices belong to each cohort, ensuring a controlled deployment process.

HexDroid gives you full control over rollouts – you can activate them for a percentage of devices, gradually scaling up, or halt them at any time if needed.

HexDroid lets you define cohorts your way - whether it's production, development, validation, or something entirely different. While it's common to use these standard groups for safer rollouts, HexDroid doesn’t lock you into any specific structure. You have full control to organize and assign devices in a way that fits your workflow.

Release rollout history for multiple cohorts

Payloads​

Each release can have one or more payloads - files associated with that release. For example, an ota payload is the updater file required by the end device to perform an update.

HexDroid also supports internal payloads - files tied to the release but not intended for the end device or user. These internal payloads can be uploaded and marked accordingly, ensuring only project members can access them.

Multiple payloads of the same type are supported. For instance, a release might include one ota file and several apk files.

List of payloads

Incremental updates​

HexDroid supports incremental updates, also known as delta updates, which are smaller update packages containing only the changes between two specific versions. This significantly reduces download sizes.

When creating a release, you can upload an incremental payload and specify its source version. When a device running a matching source version requests an update, HexDroid will automatically provide the smaller incremental package. If a device is on a different version for which no incremental update is available, it will receive the full update package to ensure it can still update to the latest release.

For example, in an AOSP project, you can generate an incremental OTA package that updates from version A to version B. You would then upload this package to the release for version B and specify version A as the source. Only devices currently on version A will receive this incremental update.

List of incremental payloads

Target build list​

The Main Releases page displays a list of all created release targets.
Clicking on a target reveals its version history along with a quick summary of the rollout status for each version.

List of release/update targets List of version for a given release/update target

Combo build list​

Another way to view releases is through the Combo View, which groups all releases (across targets) by version code or version name.
This view is useful for managing multiple targets that share a similar versioning scheme.

List of versions for all targets

Test(Validate) update rollout​

HexDroid gives you full visibility into release rollouts, helping you troubleshoot devices not receiving updates or analyze update behavior.

Quickly test release conditions by entering the target, device ID, and current version. Get instant feedback with a step-by-step breakdown of the rollout decision – whether an update is available or not.

Learn more about this here.
Create release on HexDroid Web App Create release on HexDroid Web App

Software Bill of Materials (SBOM)​

A Software Bill of Materials (SBOM) serves as a comprehensive inventory of all components used to build a software artifact. This includes both open-source and proprietary software elements.

Commonly used and standardized formats for SBOMs include: CycloneDX, SPDX, SWID

HexDroid is designed to accommodate any text-based SBOM format, offering flexibility in how you manage your component information.

With HexDroid, you can associate one or more SBOMs with a specific release. Each SBOM attached to a release must be assigned a unique "type." Attempting to upload an SBOM with a type that already exists for that release will result in an error.

SBOM Use-cases:

Beyond meeting regulatory requirements, SBOMs offer advantages for software development and management:

SBOMs contribute to reproducible builds by documenting the exact versions of all components used. This is particularly useful in scenarios like AOSP projects, where you can "pin" the precise SHA of each project in the manifest file. This allows for easy resynchronization of the tree, ensuring all repositories match the pinned SHA.

In AOSP, you can pin the current manifest with:

repo manifest --revision-as-HEAD --output-file=aosp_build_manifest_pinned.xml

And upload the resulting file to HexDroid as SBOM.

For an Android project, you can run to generate a dependency tree and upload it to HexDroid.

./gradlew app:dependencies

SBOM can be uploaded to HexDroid via Web interface, or via CLI, or from CI/CD.

AOSP SBOM Example via AOSP Pinned Manifest