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:
generic/vsoc_x86_64/aosp_cf_x86_64_phone/userdebug/test-keys
This target string can be derived at runtime or build time as follows:
- Kotlin
- Makefiles
- Build Env
import android.os.Build
fun target(): String {
return "${Build.BRAND}/${Build.DEVICE}/${Build.PRODUCT}/${Build.TYPE}/${Build.TAGS}"
}
$(PRODUCT_BRAND)/$(TARGET_DEVICE)/$(TARGET_PRODUCT)/$(TARGET_BUILD_VARIANT)/$(BUILD_VERSION_TAGS)
In AOSP build environment (after source
and lunch
):
source build/envsetup.sh
lunch aosp_cf_x86_64_phone-trunk_staging-userdebug
echo "$(get_build_var PRODUCT_BRAND)/$(get_build_var TARGET_DEVICE)/$(get_build_var TARGET_PRODUCT)/$(get_build_var TARGET_BUILD_VARIANT)/$(get_build_var BUILD_VERSION_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.
Payload Strategy
Each payload can be either full or incremental:
- Full payload (default): Provides complete payload data, typically larger in size but works for any version
- Incremental payload: Smaller in size but can only update from a specific
version_code
to the target version, requiring exact version matching
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.