HideMyAndroid Headless API

Requirements

The Headless API lets you control HideMyAndroid entirely from ADB or any automation tool — no app UI needed. It is a Premium feature.

• Premium account — the Headless API is Premium-only.
• App version 1.2.8 or newer. Everything added since is an extra field or method, so 1.2.8 still works — but the newer pieces need a newer build: hook_spoof_uptime needs 1.3.4+, geo and profile.duplicate need 1.4.5+, and the whole backup / restore group needs 1.5.3+. An older build ignores a field it does not know and still answers ok=true — but an unknown method is louder: calling the backup / restore group on a build before 1.5.3 returns BAD_REQUEST with error_message “Unknown method: …”. If a setting seems to do nothing, check the running version with status — a packaged release reports it faithfully, while a self-compiled build made before the version bump can carry a feature yet still report the older number.
• Root + LSPosed — the same setup HideMyAndroid already needs. See the installation guide.
• ADB connected to your device (adb devices lists it).
• Internet on the device — needed only when you enable a proxy (it is tested live).

⚠️ VPN permission is only needed for profiles that use a proxy. Headless cannot raise the system VPN consent dialog, so grant it once from the app's Headless API screen. Without it, activating a proxy profile still activates the profile — but the proxy will not connect and the call returns INTERNAL saying exactly that.

Authentication

Open Settings → Developer → Headless API in the app and turn on Enable. A key is generated automatically — tap Copy. Every request sends this key as the token parameter.

Keep it private — anyone with the key and ADB access can control your profiles. Regenerate issues a new key (the old one stops working); logging out erases it.

Throughout this reference, replace <your_access_token> with your key and <profile_id> with the id returned by profile.create.

Making requests

Two transports, chosen by whether a value contains a colon :

content call splits each --extra on the colon, so it cannot carry JSON — that is why JSON values go through the broadcast instead.

Only three methods have a broadcast form at all: HEADLESS_UPDATE (profile.update), HEADLESS_SET_ACTIVE and HEADLESS_DEACTIVATE. The other fifteen — status, every read, profile.create, profile.duplicate, profile.delete, the target-app calls and the whole backup / restore group — are content call only. There is no HEADLESS_CREATE — or HEADLESS_BACKUP — to go looking for.

The broadcast is not JSON-only. HEADLESS_UPDATE forwards exactly seven extras — name, hookFlags, proxy, geo, deviceMock, sim, gmails — so name and gmails travel over either transport. The table above is about which one is convenient, not which one is possible. Any extra whose name is not on that list of seven is dropped without an error.

Responses. Success is ok=true (content call) or result=0 (broadcast); failures add error_code and error_message. See Error codes. Every method also takes token. Click any operation below to expand its parameters, request, and response.

Status

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method status --extra token:s:<your_access_token>

Bundle[{data={"premium":true,"featureEnabled":true,"freshnessOk":true,"activeProfileId":"a1b2c3d4-...","version":"1.5.3"}, ok=true}]

💡 status is the only method that still answers when the licence is expired or stale — every other call returns LICENSE_EXPIRED or LICENSE_STALE and nothing else. That makes it the way to tell those two apart when a request is refused: read premium to see whether Premium genuinely ran out, and freshnessOk to see whether the app merely needs opening once. status is still gated by FEATURE_DISABLED and UNAUTHORIZED, so a silent API or a bad token look the same here as anywhere else.

Profiles

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.list --extra token:s:<your_access_token>

Bundle[{data=[{"id":"a1b2...","name":"Demo","isActive":true,"createdAt":1717000000000,"updatedAt":1717000500000}], ok=true}]

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.get --extra token:s:<your_access_token> --extra id:s:<profile_id>

Bundle[{data={"id":"a1b2...","name":"Demo","isActive":false,"hookFlags":{"hook_wifi":true,...},"proxy":{"enabled":false,...},"geo":{"source":"PROXY",...},"deviceMock":{"enabled":false,...},"sim":{"enabled":false,"simCards":[]},"gmails":[],"targetApps":["com.whatsapp"]}, ok=true}]

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.create --extra token:s:<your_access_token> --extra name:s:Demo

Bundle[{data={"id":"a1b2c3d4-..."}, ok=true}]

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.duplicate --extra token:s:<your_access_token> --extra id:s:<profile_id>

Bundle[{data={"id":"e5f6a7b8-...","name":"Brave Falcon 42"}, ok=true}]

What a duplicate carries over

Clones a profile the way the Duplicate menu does in the app — needs app 1.4.5+. Settings carry over, but every identifying value is regenerated, so the copy has its own fingerprint instead of being a twin of the original. There is no broadcast form: a fire-and-forget broadcast could not hand you the new id, which is the whole point of the call.

To end up with a name of your own, duplicate first and then rename in a second call:

# 1. duplicate — the new id and its generated name come back together
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.duplicate --extra token:s:<your_access_token> --extra id:s:<source_profile_id>

# 2. rename the copy — profile.duplicate never takes a name of your own
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.update --extra token:s:<your_access_token> --extra id:s:<new_profile_id> --extra name:s:"My Profile"

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.update --extra token:s:<your_access_token> --extra id:s:<profile_id> --extra name:s:"My Profile"

adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e hookFlags '{"hook_wifi":false,"hook_nearby_bluetooth":false}'

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.delete --extra token:s:<your_access_token> --extra id:s:<profile_id>

Bundle[{data={}, ok=true}]

Activation

A profile only spoofs once active, and only one profile is ever active. profile.setActive switches the active profile over — whichever profile was active before is deactivated for you, so there is no need to call profile.deactivate first.

⚠️ Activating clears the target apps' data. profile.setActive does not just restart them: it force-stops each target app and wipes its data, so it comes back up clean and actually picks up the new identity. That is deliberate — but it means anything inside those apps is gone, logged-in sessions included, In the app the same action asks you to confirm first and points you at the Backup feature; a headless call raises no dialog and runs straight through, so this warning is the only one you get. Headlessly, the safety net is backup.start (1.5.3+) before you switch. And since 1.5.3, while a backup / restore job is still holding the slot, profile.setActive and profile.deactivate answer BUSY — even for a job already cancelled; retry until the BUSY stops.

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.setActive --extra token:s:<your_access_token> --extra id:s:<profile_id>

adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_SET_ACTIVE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id>

Bundle[{data={"id":"a1b2...","isActive":true}, ok=true}]

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.deactivate --extra token:s:<your_access_token>

adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_DEACTIVATE -p com.wowsoftware.hidemyandroid -e token <your_access_token>

Bundle[{data={}, ok=true}]

content call is the form to prefer: it is synchronous and prints the returned Bundle. The HEADLESS_SET_ACTIVE and HEADLESS_DEACTIVATE broadcasts do the same job from automation tools such as Tasker. They reply as an ordered broadcast, which always carries data back: on success am broadcast prints result=0 with the result JSON in data="…", and on failure result=1 with data="{"error_code":…,"error_message":…}". So they are not strictly fire-and-forget — parse data= and you get the same answer content call would have given. HEADLESS_SET_ACTIVE takes the profile id as either -e id or -e profile_id; HEADLESS_DEACTIVATE needs no id at all. As always, include -p com.wowsoftware.hidemyandroid.

Target apps

Target apps are the apps a profile spoofs.

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.getApps --extra token:s:<your_access_token> --extra id:s:<profile_id>

Bundle[{data=[{"packageName":"com.whatsapp"}], ok=true}]

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.addApp --extra token:s:<your_access_token> --extra id:s:<profile_id> --extra packageName:s:com.whatsapp

Bundle[{data=[{"packageName":"com.whatsapp"}], ok=true}]

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.removeApp --extra token:s:<your_access_token> --extra id:s:<profile_id> --extra packageName:s:com.whatsapp

Bundle[{data=[], ok=true}]

Backup & restore

New in 1.5.3, this group copies a profile's app data into archives on the device and pours it back later — the same job as Manage Backups in the app, minus the UI. All six methods are content call only (no broadcast form), and the two *.start calls are asynchronous: they hand you a jobId immediately and keep working in the background — poll backup.job to follow along. Backing up a single app can take minutes.

⚠️ One job at a time. A second *.start while one runs returns BUSY, with the running jobId in error_message. The two *.start calls also require the target profile to be active — otherwise REQUIRES_ACTIVE_PROFILE, and there is no override flag. The other four methods work on any profile. And as everywhere in the headless API, nothing asks for confirmation — every call runs straight through.

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method backup.start --extra token:s:<your_access_token> --extra id:s:<profile_id>

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method backup.start --extra token:s:<your_access_token> --extra id:s:<profile_id> --extra packages:s:com.twitter.android,com.facebook.katana

Bundle[{data={"jobId":"f0e1d2c3-...","type":"backup","total":2,"packages":["com.twitter.android","com.facebook.katana"],"foregroundHeld":true}, ok=true}]

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method restore.start --extra token:s:<your_access_token> --extra id:s:<profile_id>

Bundle[{data={"jobId":"09a8b7c6-...","type":"restore","total":1,"packages":["com.twitter.android"],"foregroundHeld":true}, ok=true}]

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method backup.job --extra token:s:<your_access_token> --extra jobId:s:<job_id>

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method backup.job --extra token:s:<your_access_token>

# while it runs
Bundle[{data={"jobId":"f0e1d2c3-...","type":"backup","profileId":"a1b2...","state":"RUNNING","total":2,"done":0,"ok":0,"failed":0,"currentPackage":"com.twitter.android","currentComponent":"Internal Data","progress":0.31,"results":[],"error":null,"foregroundHeld":true,"startedAt":1712345678901,"finishedAt":null}, ok=true}]

# when it finishes — note: DONE even though one app failed
Bundle[{data={"jobId":"f0e1d2c3-...","type":"backup","profileId":"a1b2...","state":"DONE","total":2,"done":2,"ok":1,"failed":1,"currentPackage":null,"currentComponent":null,"progress":1.0,"results":[{"packageName":"com.twitter.android","ok":true,"error":null},{"packageName":"com.facebook.katana","ok":false,"error":"tar exited 2"}],"error":null,"foregroundHeld":true,"startedAt":1712345678901,"finishedAt":1712345699999}, ok=true}]

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method backup.cancel --extra token:s:<your_access_token> --extra jobId:s:<job_id>

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method backup.list --extra token:s:<your_access_token> --extra id:s:<profile_id>

Bundle[{data=[{"packageName":"com.twitter.android","appName":"X","timestamp":1712345678901,"totalSize":12345678,"components":["INTERNAL_DATA","EXTERNAL_DATA","OBB"]}], ok=true}]

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method backup.delete --extra token:s:<your_access_token> --extra id:s:<profile_id> --extra packageName:s:com.twitter.android

Bundle[{data={}, ok=true}]

How jobs behave

• DONE does not mean every app succeeded. It only means the job ran to the end. An app can fail while the job still finishes DONE — read failed and results[], always.
• Activation waits for jobs now. While a job holds the slot, profile.setActive, profile.deactivate and profile.delete answer BUSY — even for a job you already cancelled, because the root tar underneath cannot be stopped mid-file, and no snapshot field reports the slot. A job that ends naturally in DONE or FAILED frees the slot almost at once; after a cancel, do not treat CANCELLED as “slot free” — just retry the call until BUSY stops.
• foregroundHeld is an observation, not a promise. It reports whether a foreground service is shielding the job from being killed by the OS. It has been measured true on API 36, but even true only means the service start was accepted — the later promotion step can still fail silently on some devices. For long jobs, keep the device awake rather than lean on it.
• Where backups live. /sdcard/HideMyAndroid_Backups/<packageName>-<profileId>/ — one folder per app per profile, holding .tar.gz archives (data.tar.gz, data_ext.tar.gz, media.tar.gz, …) plus metadata.json, written with root tar. The {package}-{profileId} key is what makes restore same-profile only. Backups made headlessly show up in the app's Manage Backups screen too.

Configuration

These are the values you send with profile.update. Defaults when a profile is created:

⚠️ A config with enabled:false is stored but inert — values are saved so you can flip it on later, but nothing is spoofed until enabled:true. geo is the exception: it has no enabled switch. The hook_geo_* flags apply whenever geo resolves to a usable location — either from source: CUSTOM, or from a proxy that is enabled:true and passed its live test.

hookFlags

Default: ON for every flag except hook_spoof_uptime, which is OFF. A map of "flag": true|false. An update replaces the whole map, but only the map you actually send: an update that omits the hookFlags extra altogether leaves every flag exactly as it was. Within a map you do send, every flag you leave out returns to its own default, so the other 20 go back ON while hook_spoof_uptime goes back OFF even if you had turned it on. To change a few and keep the rest, run profile.get first, edit the full map, then send it all back.

proxy

Default: OFF. With enabled:true, the app connects through it for real, reads its location, and fills countryCode/lat/lon/timezone. The live test takes up to ~8s; a proxy that fails returns PROXY_INVALID and is not saved. Those four are outputs — the app writes them, so anything you send in them is overwritten. To set a location by hand, use geo with source: CUSTOM instead; that needs no proxy at all. profile.get returns the proxy including those four fields, but never echoes username or password.

adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e proxy '{"enabled":true,"host":"10.0.0.1","port":1080,"protocol":"SOCKS5"}'

geo

Default: {"source":"PROXY"}. Needs app 1.4.5+. This is where a profile's location comes from, and there are two sources — pick one with source. PROXY uses the location read during the proxy's live test. CUSTOM lets you set the coordinates, timezone and region yourself, with no proxy required — so you can put a profile in Tokyo while routing traffic anywhere, or nowhere. The three hook_geo_* flags then switch each part on independently: GPS, region + language, and timezone.

⚠️ Mind the field names: geo spells them latitude/longitude, while proxy above uses the short lat/lon. They are two separate objects, not aliases — the short names in a geo payload are simply ignored.

⚠️ source: CUSTOM must arrive complete: a coordinate pair that is not 0/0 and in range, a 2-letter countryCode, and a timezone. Miss any one and the call returns BAD_REQUEST — it does not fall back to the proxy. The app never geocodes and never goes online to fill these in for you. If neither source ends up usable, no geo hook is loaded at all and the real location shows through.

🛑 timezone is the one field that is not really checked. It is only tested for being non-empty — never against the IANA database. A typo like Asia/Tokyoo is accepted, returns ok=true, is echoed back unchanged by profile.get, and then silently resolves to GMT on the device. Nothing anywhere reports an error, so copy the name exactly. Coordinates are the opposite — they are range-checked and a bad one fails loudly with BAD_REQUEST.

CUSTOM — set a location by hand, no proxy needed

adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e geo '{"source":"CUSTOM","latitude":35.6812,"longitude":139.7671,"countryCode":"JP","timezone":"Asia/Tokyo","language":"ja"}'

PROXY — take the location from the proxy (default)

adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e geo '{"source":"PROXY"}'

deviceMock

Default: OFF. Pretends the device is a different model. Set "enabled":true plus any of these fields — all optional strings (default empty), each mapping to an Android Build property:

adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e deviceMock '{"enabled":true,"manufacturer":"Samsung","brand":"samsung","model":"SM-S918B","device":"dm3q","product":"dm3qxxx","board":"kalama","hardware":"qcom","buildId":"UP1A.231005.007","buildIncremental":"S918BXXU3CWK9","buildType":"user","buildTags":"release-keys","buildFingerprint":"samsung/dm3qxxx/dm3q:14/UP1A.231005.007/S918BXXU3CWK9:user/release-keys","deviceName":"Galaxy S23 Ultra"}'

sim

Default: OFF. Spoofs the SIM/carrier. Set "enabled":true and provide up to two cards in simCards. The list is always normalised to exactly two: a third card is dropped silently — the call still returns ok=true — and a single card is padded with an empty second one, which is why profile.get always hands back two. Each card:

networkType is trimmed and matched case-insensitively, and each tier answers to more than one spelling:

⚠️ Anything outside this table silently disables the network-type spoof for that card — no error, no BAD_REQUEST, the value is simply stored and never used. Note that NR 5G carries a space: NR5G is not recognised and falls into exactly that silent hole.

adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e sim '{"enabled":true,"simCards":[{"slotIndex":0,"carrierName":"AT&T","countryIso":"us","mcc":"310","mnc":"410","operatorCode":"310410","networkType":"LTE"},{"slotIndex":1,"carrierName":"T-Mobile","countryIso":"us","mcc":"310","mnc":"260","operatorCode":"310260","networkType":"NR 5G"}]}'

gmails

Default: empty. A list of virtual Google accounts — only @gmail.com addresses are accepted. The list replaces the previous one; [] clears it. No : inside, so content call works:

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.update --extra token:s:<your_access_token> --extra id:s:<profile_id> --extra 'gmails:s:["alice@gmail.com","bob@gmail.com"]'

Full example

A complete setup from scratch:

# 1. create a profile — copy the returned id into <profile_id> below
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.create --extra token:s:<your_access_token> --extra name:s:Demo

# 2. add a target app
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.addApp --extra token:s:<your_access_token> --extra id:s:<profile_id> --extra packageName:s:com.whatsapp
# 3. add the virtual Gmail accounts
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.update --extra token:s:<your_access_token> --extra id:s:<profile_id> --extra 'gmails:s:["alice@gmail.com","bob@gmail.com"]'

# 4. enable + set the device mock
adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e deviceMock '{"enabled":true,"manufacturer":"Samsung","brand":"samsung","model":"SM-S918B","device":"dm3q","product":"dm3qxxx","board":"kalama","hardware":"qcom","buildId":"UP1A.231005.007","buildIncremental":"S918BXXU3CWK9","buildType":"user","buildTags":"release-keys","buildFingerprint":"samsung/dm3qxxx/dm3q:14/UP1A.231005.007/S918BXXU3CWK9:user/release-keys","deviceName":"Galaxy S23 Ultra"}'

# 5. enable + set the SIM mock (two cards, full fields)
adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e sim '{"enabled":true,"simCards":[{"slotIndex":0,"carrierName":"AT&T","countryIso":"us","mcc":"310","mnc":"410","operatorCode":"310410","networkType":"LTE","phoneNumber":"+12025550123","iccid":"8901410123456789012","imsi":"310410123456789"},{"slotIndex":1,"carrierName":"T-Mobile","countryIso":"us","mcc":"310","mnc":"260","operatorCode":"310260","networkType":"NR 5G","phoneNumber":"+12025550456","iccid":"8901260987654321098","imsi":"310260987654321"}]}'

# 6. enable + set the proxy (tested live, ~8s)
adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e proxy '{"enabled":true,"host":"10.0.0.1","port":1080,"protocol":"SOCKS5"}'

# 7. pick where the location comes from — geo has two sources, choose ONE
#    A) from the proxy you just set. This is the default, so the line is optional:
adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e geo '{"source":"PROXY"}'
#    B) or set it yourself — this needs no proxy at all. Use B *instead of* A, not after it:
# adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e geo '{"source":"CUSTOM","latitude":35.6812,"longitude":139.7671,"countryCode":"JP","timezone":"Asia/Tokyo","language":"ja"}'
#    geo and proxy are independent: setting one never rewrites the other, and only
#    geo.source decides which one feeds the hooks. So CUSTOM together with a proxy in
#    a different country means your IP says one place while your GPS says another.

# 8. activate (restarts the target app and clears its data)
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.setActive --extra token:s:<your_access_token> --extra id:s:<profile_id>

# 9. verify
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.get --extra token:s:<your_access_token> --extra id:s:<profile_id>

Error codes

On failure you get ok=false with one of these error_code values (broadcasts return result=1):

Tips & troubleshooting

• A broadcast does nothing? Make sure you included -p com.wowsoftware.hidemyandroid — Android blocks broadcasts without it.
• A value got cut off after a :? That value has a colon, so content call truncated it. Send it via the HEADLESS_UPDATE broadcast instead.
• JSON broadcast not applying (often on Windows)? Across a desktop shell and the device shell, the quotes in am broadcast JSON (hookFlags, proxy, deviceMock, sim) are easily stripped, so am misreads the value (you may see it land as a dat=… data URI) and nothing changes. The reliable fix is to keep the JSON off the command line — put the whole workflow in a .sh file (single quotes keep every JSON intact), then push and run it on the device. The script runs on the device, so it can even capture the new profile id and reuse it:
  bash Copy

  # setup.sh — the full example as one runnable script (runs on the device)
  URI=content://com.wowsoftware.hidemyandroid.headless
  PKG=com.wowsoftware.hidemyandroid
  K=<your_access_token>
  
  # 1. create a profile and capture its id
  ID=$(content call --uri $URI --method profile.create --extra token:s:$K --extra name:s:Demo | grep -o '"id":"[^"]*"' | head -n1 | sed 's/.*"id":"//;s/"//')
  echo "profile id: $ID"
  
  # 2. add a target app
  content call --uri $URI --method profile.addApp --extra token:s:$K --extra id:s:$ID --extra packageName:s:com.facebook.katana
  
  # 3. add the virtual Gmail accounts
  content call --uri $URI --method profile.update --extra token:s:$K --extra id:s:$ID --extra 'gmails:s:["alice@gmail.com","bob@gmail.com"]'
  
  # 4. enable + set the device mock
  am broadcast -a $PKG.HEADLESS_UPDATE -p $PKG -e token $K -e id $ID -e deviceMock '{"enabled":true,"manufacturer":"Samsung","brand":"samsung","model":"SM-S918B","device":"dm3q","product":"dm3qxxx","board":"kalama","hardware":"qcom","buildId":"UP1A.231005.007","buildIncremental":"S918BXXU3CWK9","buildType":"user","buildTags":"release-keys","buildFingerprint":"samsung/dm3qxxx/dm3q:14/UP1A.231005.007/S918BXXU3CWK9:user/release-keys","deviceName":"Galaxy S23 Ultra"}'
  
  # 5. enable + set the SIM mock (two cards)
  am broadcast -a $PKG.HEADLESS_UPDATE -p $PKG -e token $K -e id $ID -e sim '{"enabled":true,"simCards":[{"slotIndex":0,"carrierName":"AT&T","countryIso":"us","mcc":"310","mnc":"410","operatorCode":"310410","networkType":"LTE","phoneNumber":"+12025550123","iccid":"8901410123456789012","imsi":"310410123456789"},{"slotIndex":1,"carrierName":"T-Mobile","countryIso":"us","mcc":"310","mnc":"260","operatorCode":"310260","networkType":"NR 5G","phoneNumber":"+12025550456","iccid":"8901260987654321098","imsi":"310260987654321"}]}'
  
  # 6. enable + set the proxy (tested live, ~8s)
  am broadcast -a $PKG.HEADLESS_UPDATE -p $PKG -e token $K -e id $ID -e proxy '{"enabled":true,"host":"10.0.0.1","port":1080,"protocol":"SOCKS5"}'
  
  # 7. pick where the location comes from — geo has two sources, choose ONE
  #    A) from the proxy you just set. This is the default, so the line is optional:
  am broadcast -a $PKG.HEADLESS_UPDATE -p $PKG -e token $K -e id $ID -e geo '{"source":"PROXY"}'
  #    B) or set it yourself — this needs no proxy at all. Use B *instead of* A, not after it:
  # am broadcast -a $PKG.HEADLESS_UPDATE -p $PKG -e token $K -e id $ID -e geo '{"source":"CUSTOM","latitude":35.6812,"longitude":139.7671,"countryCode":"JP","timezone":"Asia/Tokyo","language":"ja"}'
  #    geo and proxy are independent: setting one never rewrites the other, and only
  #    geo.source decides which one feeds the hooks. So CUSTOM together with a proxy in
  #    a different country means your IP says one place while your GPS says another.
  
  # 8. activate (restarts the target app and clears its data)
  content call --uri $URI --method profile.setActive --extra token:s:$K --extra id:s:$ID
  
  # 9. verify
  content call --uri $URI --method profile.get --extra token:s:$K --extra id:s:$ID

  then push it to the device and run it:
  bash Copy

  adb push setup.sh /data/local/tmp/setup.sh
  adb shell sh /data/local/tmp/setup.sh

  Plain content call commands (no JSON) can be typed directly without a script. In Git Bash, prefix the adb lines with MSYS_NO_PATHCONV=1 so the on-device path isn't rewritten.
• Changes didn't appear? The target app must restart — activating a profile does this for you, and clears that app's data in the same step, so it comes up with the new identity and nothing carried over from before.
• PROXY_INVALID for a proxy you trust? The device needs internet for the test, capped at ~8s, so a slow proxy can time out.
• BUSY from a job you already cancelled? backup.cancel flips the job to CANCELLED (and sets finishedAt) at once, but the tar it launched cannot be interrupted and keeps running, so the slot stays held. backup.job shows CANCELLED while the slot is still busy, and no field reports the slot — do not treat CANCELLED as “slot free”; just retry profile.setActive / deactivate / delete until they stop returning BUSY. (A job that ends naturally in DONE or FAILED frees the slot almost at once.)