Android Automation Script Hot Update: Update Your Code Without Repackaging the APK

Android cluster control is a technique for centrally managing and batch-operating multiple Android phones from one computer, with no root and no system modification.

This one is about update Your Code Without Repackaging the APK.

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

1. Keep versions consistent: the version in update.json must stay logically consistent with what the server returns, or updates may misbehave;
2. No update = no JSON: return an empty string when nothing needs updating; returning JSON makes the client treat it as update data;
3. Do not treat deviceId as a unique fingerprint: deviceId is generated by EC and can be lost — do not build device-binding logic on it alone;
4. Mind production rollouts: turn on appendDeviceInfo and 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.