Anyone who builds Android automation scripts knows this pain: the script is deployed on dozens of phones, then you find a logic bug or want to add a feature — so you have to repackage the APK, push it to every device, and make users reinstall. Fine for one or two phones. A disaster for dozens or hundreds.
Hot update solves exactly this — push the compiled code file directly to the phone without repackaging the APK. This article walks through the entire chain: configuration, the server side, automatic updates, and manual in-script triggering.
1. First, Be Clear: What Exactly Gets Hot-Updated
Many people misunderstand “hot update” as updating the APK. It is not. What gets hot-updated is the compiled .iec file, not the packaged APK.
The APK is just a shell — install it once and never touch it again. All the business logic is compiled into the .iec file and delivered through the hot-update mechanism. The benefits are direct:
- No more releases: fix code without repackaging, signing, or distributing;
- Near-instant delivery: users pull the latest code the next time they launch the script;
- Damage control: when something breaks in production, ship a fix and cover all devices immediately — no waiting for manual upgrades.
2. The Config File: update.json Is the Entry Point
In the project directory, find (or create) update.json. All the basic hot-update configuration lives here:
{
"update_url": "http://baidu.com/update",
"version": "1.0.0",
"appendDeviceInfo": true,
"timeout": 30000
}
Field meanings:
| Field | Description |
|---|---|
update_url |
The server update endpoint. Write your own, or use the official hot-update service |
version |
The current script version |
timeout |
Request timeout in milliseconds, minimum 1000 |
appendDeviceInfo |
Whether to append basic device info to the request |
With appendDeviceInfo set to true, the request automatically carries device parameters so the server can deliver per-device updates. The request URL looks like:
http://baidu.com/update?version=1&deviceId=7521e5d9eeec4f58b71dea8b78c414d5&apkVersion=9.22.0&osVersion=12&pkgName=com.gibb.easyclick&model=LNA-AL00&ecVersion=9.22.0&brand=HUAWEI&androidId=82a3b055470ebe1a
Parameter meanings:
| Parameter | Description |
|---|---|
version |
The currently running .iec version |
deviceId |
Device ID generated by EC (may be lost; do not rely on it as a unique device identifier) |
apkVersion |
APK package version |
osVersion |
OS version |
ecVersion |
The actual EC version in use |
pkgName |
The packaged package name |
model / brand |
Device model and brand |
androidId |
Android ID |
3. The Server Side: Two Response Formats
Once configured, the packaged app automatically requests update_url via GET with the version parameter, e.g. http://baidu.com/update?version=1.0.0. Version comparison logic lives on your server.
The server responds in one of two ways:
1. No update needed — return an empty string. Do not return JSON.
2. Update available — return an update JSON object:
{
"download_url": "http://baidu.com/aaa.iec",
"version": "1.1.0",
"dialog": true,
"msg": "Bug fixes and improvements",
"force": false
}
Field meanings:
| Field | Description |
|---|---|
download_url |
The download URL of the new package |
version |
The new package version |
dialog |
Whether to show the update prompt as a dialog (true popup / false silent) |
msg |
The message shown in the dialog |
force |
Whether the update is forced in dialog mode (true cannot be cancelled) |
On receiving this JSON, the client downloads the latest .iec package and loads it.
Worried about failed downloads? Use strict mode with MD5 verification:
{
"download_url": "http://baidu.com/aaa.iec",
"version": "1.1.0",
"dialog": true,
"msg": "Bug fixes and improvements",
"force": false,
"md5": "the md5 value of the iec file computed by your server",
"download_timeout": 60
}
md5: the MD5 of the .iec file. When present, file integrity is enforced — the downloaded file is guaranteed complete;download_timeout: download timeout in seconds, default 60.
4. Two Trigger Points: Auto-Update on Launch + In-Script Update
4.1 Auto-update on UI launch
As long as update.json is configured correctly, the script automatically requests an update when the user opens the script UI — no extra code needed. This is the most common approach: the user opens the script, and the latest code is already on its way.
4.2 In-script hot update
Hot updates can also run while the script is executing, triggered by code. The core flow: request update → download new package → restart script.
function main() {
// Read the version from update.json in the project
let version = JSON.parse(readIECFileAsString("update.json")).version
toast("Hello World - " + version);
// Request the server for a new version (custom URL mode)
let updateResult = hotupdater.updateReq("http://baidu.com", version, true, 9000);
logd("Update available: " + updateResult);
if (!updateResult) {
logw("Request failed, error: " + hotupdater.getErrorMsg());
} else {
// An update is available — download the new version
let path = hotupdater.updateDownload();
logd("Download path: " + path);
if (!path) {
logw("Download IEC error: " + hotupdater.getErrorMsg());
} else {
// Restart the script to load the new version
restartScript(path, true, 3)
return;
}
}
}
main();
Methods used for in-script hot updates:
| Method | Purpose |
|---|---|
hotupdater.updateReq(updateUrl, version, appendDeviceInfo, timeout) |
Requests the update endpoint; returns true when an update is needed, false when no update or the request failed (check getErrorMsg for details) |
hotupdater.updateDownload() |
Downloads the .iec file from the hot-update response; returns the downloaded file path |
hotupdater.getUpdateResp() |
Gets the hot-update request result |
hotupdater.getErrorMsg() |
Gets request or download error info |
When the first argument of updateReq is omitted, the data from update.json is used; version is best passed as an integer. After downloading, call restartScript(path, true, 3) to restart the script and apply the new code immediately.
5. Common Pitfalls
- Keep versions consistent: the version in
update.jsonmust stay logically consistent with what the server returns, or updates may misbehave; - No update = no JSON: return an empty string when nothing needs updating; returning JSON makes the client treat it as update data;
- Do not treat deviceId as a unique fingerprint:
deviceIdis generated by EC and can be lost — do not build device-binding logic on it alone; - Mind production rollouts: turn on
appendDeviceInfoand roll out per-device, so a bad release does not hit everyone at once.
6. Summary
Hot update is the capability that moves an Android script from “personal toy” to “commercial product”:
- Configure once, benefit forever: after update.json is set up, every iteration goes through hot update — say goodbye to repackaging and re-pushing;
- Two update paths: auto-update on UI launch covers most scenarios; in-script manual update suits timing-sensitive business logic;
- Strict mode is more reliable: add MD5 verification in production to prevent incomplete downloads from breaking scripts;
- Do not want to write a server? Use the official hot-update service (backed by Alibaba Cloud OSS) — upload the .iec file and get the download URL and MD5 automatically.
For teams selling scripts deployed to dozens or hundreds of devices, hot update is not a nice-to-have — it is an operational necessity. The era of reinstalling the APK for every single-line change is over.
Ready to build it for real?
Every approach in this article can be built on the EasyClick phone automation platform — full documentation, developer tools and cluster/cloud-control products, free to try.