Skip to main content

Terminology

Target​

The target is a unique string that identifies a specific software distribution. It is essential to encode any build-time differences within this string to ensure the server delivers the correct update.

For example, in Android/AOSP a suggested target would be: google/shamu/shamu/user/release-keys

In AOSP(makefiles) it can be derived as follows: $(PRODUCT_BRAND)/$(TARGET_PRODUCT)/$(TARGET_DEVICE)/$(TARGET_BUILD_VARIANT)/$(BUILD_VERSION_TAGS)

Or at runtime via:

import android.os.Build

fun target(): String {
  return "${Build.BRAND}/${Build.PRODUCT}/${Build.DEVICE}/${Build.TYPE}/${Build.TAGS}"
}

Version code​

The version code is a positive integer that serves as the internal version number for a software build. This number helps determine whether one version is more recent than another, with higher numbers indicating more recent versions.

Version Name​

The version name is a human-readable string that represents either an absolute or relative version of a software build.

Payload Type​

Each update/release can deliver one or more payloads the end user-device,

The type of each payload provides a hint on how it should be applied.
Multiple files with the same type can exist within a single update.

For example, one update can deliver ota and apk payloads - so the updater daemon then can apply ota with " update_engine" and apk with "package_manager".

This separation allows different components of the system to process and apply the appropriate payloads as needed.

Distributed​

The distributed flag determines whether a payload is intended for direct delivery to end-user devices or restricted to project members.

  • true - The payload is meant for distribution to end-user devices (e.g., OTA files, configuration files).
  • false - The payload is only available for download through the HexDroid Web App or CLI, accessible by project members (e.g., factory flasher files).
    • Non-distributed files are typically used to share update or release-related files internally with project members without exposing them to end users.

Activate release​

Activating a release makes it available for users within a selected cohort to update to. You can activate a release multiple times, adjusting the rollout percentage with each activation to gradually expand the update.

During rollout, you control the percentage of users (by cohort) who receive the update. This allows for staged distribution and minimizes risk.

Halt release​

When you halt a rollout, no additional users will receive the version in your existing rollout.
Users who already received halted version in your rollout version will remain on that version.

If an issue is detected, you can halt the rollout to limit the number of users affected by the release.

  • Halting prevents additional users from receiving the update.
  • Users who have already received the halted version will remain on that version until a new update is deployed.