HideMyAndroid Headless API

Prérequis

La Headless API vous permet de piloter HideMyAndroid entièrement depuis ADB ou n’importe quel outil d’automatisation — sans passer par l’interface de l’application. C’est une fonctionnalité Premium.

• Compte Premium — la Headless API est réservée aux comptes Premium.
• Version de l’application 1.2.8 ou ultérieure. Tout ce qui a été ajouté depuis est un champ ou une méthode supplémentaire, donc la 1.2.8 fonctionne toujours — mais les éléments plus récents exigent une version plus récente : hook_spoof_uptime requiert la 1.3.4+, geo et profile.duplicate requièrent la 1.4.5+, tout le groupe sauvegarde / restauration requiert la 1.5.3+, le générateur SIM & appareil (simCountries, deviceTemplate, sim.countries, device.templates) requiert la 1.5.9+, hook_sensor_gyroscope requiert la 1.6.3+, hook_sensor_light requiert la 1.6.4+, et les quatre flags de cohérence des capteurs (hook_sensor_magnetometer, hook_sensor_fused, hook_sensor_pressure, hook_sensor_roster) requièrent la 1.6.9+. Une version plus ancienne ignore un champ qu’elle ne connaît pas et répond quand même ok=true — mais une méthode inconnue se remarque davantage : appeler le groupe sauvegarde / restauration sur une version antérieure à 1.5.3, ou sim.countries / device.templates avant la 1.5.9, renvoie BAD_REQUEST avec l’error_message « Unknown method: … ». Si un réglage semble sans effet, vérifiez la version en cours d’exécution avec status — une version publiée l’indique fidèlement, tandis qu’une version compilée par vos soins avant l’incrément du numéro de version peut contenir une fonctionnalité tout en affichant encore l’ancien numéro.
• Root + LSPosed — la même configuration que celle dont HideMyAndroid a déjà besoin. Consultez le guide d’installation.
• ADB connecté à votre appareil (adb devices le liste).
• Internet sur l’appareil — nécessaire uniquement lorsque vous activez un proxy (il est testé en direct).

⚠️ L’autorisation VPN n’est nécessaire que pour les profils qui utilisent un proxy. Le mode headless ne peut pas afficher la boîte de dialogue système de consentement VPN ; accordez-la donc une fois depuis l’écran Headless API de l’application. Sans elle, activer un profil avec proxy active tout de même le profil — mais le proxy ne se connectera pas et l’appel renvoie INTERNAL en l’indiquant explicitement.

Authentification

Ouvrez Paramètres → Développeur → Headless API dans l’application et activez Activer. Une clé est générée automatiquement — appuyez sur Copier. Chaque requête envoie cette clé dans le paramètre token.

Gardez-la confidentielle — toute personne disposant de la clé et d’un accès ADB peut contrôler vos profils. Régénérer émet une nouvelle clé (l’ancienne cesse de fonctionner) ; la déconnexion l’efface.

Dans toute cette référence, remplacez <your_access_token> par votre clé et <profile_id> par l’id renvoyé par profile.create.

Envoyer des requêtes

Deux transports, choisis selon qu’une valeur contient ou non un deux-points :

content call découpe chaque --extra au niveau du deux-points, il ne peut donc pas transporter de JSON — c’est pourquoi les valeurs JSON passent plutôt par le broadcast.

Seules trois méthodes existent sous forme de broadcast : HEADLESS_UPDATE (profile.update), HEADLESS_SET_ACTIVE et HEADLESS_DEACTIVATE. Les dix-sept autres — status, toutes les lectures (y compris sim.countries et device.templates), profile.create, profile.duplicate, profile.delete, les appels sur les applications cibles et tout le groupe sauvegarde / restauration — sont uniquement en content call. Inutile de chercher un HEADLESS_CREATE — ou un HEADLESS_BACKUP — : il n’en existe pas.

Le broadcast n’est pas réservé au JSON. HEADLESS_UPDATE transmet exactement neuf extras — name, hookFlags, proxy, geo, deviceMock, sim, gmails, et depuis la 1.5.9 simCountries et deviceTemplate — donc name, gmails et simCountries passent par l’un ou l’autre transport. Le tableau ci-dessus indique lequel est le plus pratique, pas lequel est possible. Tout extra dont le nom ne figure pas dans cette liste de neuf est ignoré sans erreur.

Réponses. Un succès renvoie ok=true (content call) ou result=0 (broadcast) ; un échec ajoute error_code et error_message. Voir Codes d’erreur. Chaque méthode prend également token. Cliquez sur une opération ci-dessous pour afficher ses paramètres, sa requête et sa réponse.

Statut

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.9"}, ok=true}]

💡 status est la seule méthode qui répond encore lorsque la licence est expirée ou périmée — tout autre appel renvoie LICENSE_EXPIRED ou LICENSE_STALE et rien d’autre. C’est donc le moyen de distinguer les deux lorsqu’une requête est refusée : lisez premium pour savoir si le Premium a réellement expiré, et freshnessOk pour savoir s’il suffit d’ouvrir l’application une fois. status reste soumis à FEATURE_DISABLED et UNAUTHORIZED ; une API désactivée ou un token incorrect se présentent donc ici comme partout ailleurs.

Profils

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}]

Ce que conserve une copie

Clone un profil comme le fait le menu Dupliquer dans l’application — requiert l’application 1.4.5+. Les réglages sont conservés, mais chaque valeur d’identification est régénérée, si bien que la copie possède sa propre empreinte au lieu d’être la jumelle de l’original. Il n’existe pas de forme broadcast : un broadcast « fire-and-forget » ne pourrait pas vous transmettre le nouvel id, ce qui est tout l’intérêt de l’appel.

Pour obtenir un nom de votre choix, dupliquez d’abord, puis renommez dans un second appel :

# 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

Un profil n’usurpe qu’une fois actif, et un seul profil est actif à la fois. profile.setActive bascule le profil actif — le profil précédemment actif est désactivé pour vous ; inutile donc d’appeler profile.deactivate au préalable.

⚠️ L’activation efface les données des applications cibles. profile.setActive ne se contente pas de les redémarrer : il force l’arrêt de chaque application cible et efface ses données, afin qu’elle redémarre à neuf et prenne réellement en compte la nouvelle identité. C’est voulu — mais cela signifie que tout ce qui se trouve dans ces applications disparaît, sessions connectées comprises. Dans l’application, la même action vous demande d’abord une confirmation et vous oriente vers la fonction de sauvegarde ; un appel headless n’affiche aucune boîte de dialogue et s’exécute directement, cet avertissement est donc le seul que vous recevrez. En mode headless, le filet de sécurité est backup.start (1.5.3+) avant de basculer. Et depuis la 1.5.3, tant qu’une tâche de sauvegarde / restauration occupe encore le créneau, profile.setActive et profile.deactivate répondent BUSY — même pour une tâche déjà annulée ; réessayez jusqu’à ce que BUSY cesse.

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 est la forme à privilégier : il est synchrone et affiche le Bundle renvoyé. Les broadcasts HEADLESS_SET_ACTIVE et HEADLESS_DEACTIVATE font le même travail depuis des outils d’automatisation comme Tasker. Ils répondent sous forme de broadcast ordonné, qui renvoie toujours des données : en cas de succès, am broadcast affiche result=0 avec le JSON du résultat dans data="…", et en cas d’échec result=1 avec data="{"error_code":…,"error_message":…}". Ils ne sont donc pas strictement « fire-and-forget » — analysez data= et vous obtenez la même réponse que content call aurait donnée. HEADLESS_SET_ACTIVE prend l’id du profil sous la forme -e id ou -e profile_id ; HEADLESS_DEACTIVATE n’a besoin d’aucun id. Comme toujours, incluez -p com.wowsoftware.hidemyandroid.

Applications cibles

Les applications cibles sont les applications qu’un profil usurpe.

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}]

Sauvegarde et restauration

Nouveau dans la 1.5.3, ce groupe copie les données d’applications d’un profil dans des archives sur l’appareil et les réinjecte plus tard — le même travail que Manage Backups dans l’application, sans l’interface. Les six méthodes sont uniquement en content call (pas de forme broadcast), et les deux appels *.start sont asynchrones : ils vous remettent immédiatement un jobId et poursuivent le travail en arrière-plan — interrogez backup.job pour suivre l’avancement. La sauvegarde d’une seule application peut prendre plusieurs minutes.

⚠️ Une tâche à la fois. Un second *.start pendant qu’une tâche tourne renvoie BUSY, avec le jobId en cours dans error_message. Les deux appels *.start exigent également que le profil cible soit actif — sinon REQUIRES_ACTIVE_PROFILE, et il n’existe aucun flag pour passer outre. Les quatre autres méthodes fonctionnent sur n’importe quel profil. Et comme partout dans la Headless API, rien ne demande de confirmation — chaque appel s’exécute directement.

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}]

Comportement des tâches

• DONE ne signifie pas que chaque application a réussi. Cela signifie seulement que la tâche est allée jusqu’au bout. Une application peut échouer alors que la tâche se termine quand même en DONE — lisez toujours failed et results[].
• L’activation attend désormais les tâches. Tant qu’une tâche occupe le créneau, profile.setActive, profile.deactivate et profile.delete répondent BUSY — même pour une tâche que vous avez déjà annulée, car le tar root sous-jacent ne peut pas être arrêté en cours de fichier, et aucun champ de l’instantané n’indique l’état du créneau. Une tâche qui se termine normalement en DONE ou FAILED libère le créneau presque aussitôt ; après une annulation, ne considérez pas CANCELLED comme « créneau libre » — réessayez simplement l’appel jusqu’à ce que BUSY cesse.
• foregroundHeld est une observation, pas une promesse. Il indique si un service de premier plan protège la tâche contre l’arrêt par le système. Il a été mesuré à true sur l’API 36, mais même true signifie seulement que le démarrage du service a été accepté — l’étape de promotion ultérieure peut encore échouer silencieusement sur certains appareils. Pour les tâches longues, gardez l’appareil éveillé plutôt que de vous y fier.
• Emplacement des sauvegardes. /sdcard/HideMyAndroid_Backups/<packageName>-<profileId>/ — un dossier par application et par profil, contenant des archives .tar.gz (data.tar.gz, data_ext.tar.gz, media.tar.gz, …) ainsi que metadata.json, écrites avec le tar root. C’est la clé {package}-{profileId} qui limite la restauration au même profil. Les sauvegardes réalisées en mode headless apparaissent aussi dans l’écran Manage Backups de l’application.

SIM & appareil depuis la base de données intégrée

Nouveau dans la 1.5.9. La section Configuration ci-dessous montre comment écrire à la main un bloc sim ou deviceMock, champ par champ. Ce groupe vous permet de vous en passer : deux clés supplémentaires de profile.update — simCountries et deviceTemplate — font générer le bloc entier par l’application à partir de la même base d’opérateurs et d’appareils que celle utilisée par sa propre interface, et deux méthodes de lecture listent ce qu’elle peut générer. Le résultat est enregistré dans le profil avec enabled:true déjà défini, il n’y a donc rien d’autre à envoyer — relisez-le avec profile.get.

⚠️ Une seule méthode par réglage, par appel. sim et simCountries dans la même requête donnent BAD_REQUEST, tout comme deviceMock avec deviceTemplate. Mélanger entre réglages ne pose aucun problème — simCountries à côté d’un deviceMock écrit à la main, ou les deux générateurs à la fois, comme dans le premier exemple ci-dessous. L’appel est atomique : tout est validé avant que quoi que ce soit ne soit enregistré, donc un id de modèle incorrect fait échouer toute la requête et le simCountries envoyé avec lui n’est pas appliqué non plus.

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

Bundle[{data=[{"code":"AF","country":"Afghanistan"},{"code":"AL","country":"Albania"},...,{"code":"GB","country":"United Kingdom"},...,{"code":"US","country":"United States"},...], ok=true}]

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

Bundle[{data=[{"id":"asus|ASUS_AI2401|AI2401_A","manufacturer":"asus","label":"ROG Phone 8","isCustom":false},...,{"id":"custom:samsung|e3qxeea|SM-S928B","manufacturer":"samsung","label":"Galaxy S24 Ultra","isCustom":true}], ok=true}]

adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e simCountries '["US","GB"]' -e deviceTemplate random

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 'simCountries:s:["US"]'

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 deviceTemplate:s:random

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 'deviceTemplate:s:asus|ASUS_AI2401|AI2401_A'

adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e deviceTemplate 'custom:samsung|e3qxeea|SM-S928B'

simCountries

• Format. Un tableau JSON de codes ISO 3166-1 alpha-2 — ["US","GB"], insensible à la casse. La position correspond à l’emplacement : le premier code remplit l’emplacement 0, le second l’emplacement 1. Tout ce qui n’est pas un tableau JSON, un tableau vide, une entrée vide, plus de deux entrées, ou un code que sim.countries ne liste pas renvoie BAD_REQUEST — un troisième code est refusé, jamais ignoré en silence comme l’est une troisième carte sim.
• Ce que vous obtenez. Pour chaque emplacement, l’application choisit un opérateur de ce pays dans sa base et remplit chaque champ du bloc sim écrit à la main : carrierName, countryIso, mcc, mnc, operatorCode, un phoneNumber mobile E.164 valide avec l’indicatif du pays (+1… pour les US), un iccid et un imsi préfixés par le MCC+MNC de cet opérateur, et un networkType tiré au hasard parmi LTE, NR 5G, WCDMA et GSM. Elle définit ensuite sim.enabled à true et enregistre.
• Il remplace tout le bloc SIM. Comme avec sim, le résultat est normalisé à deux cartes : ["US"] remplit l’emplacement 0 et laisse l’emplacement 1 vide, quel que soit son contenu précédent.

deviceTemplate

• random (ou une chaîne vide) — l’application tire un modèle parmi tous ceux qu’elle connaît, intégrés comme importés. Notez la différence entre vide et absent : -e deviceTemplate "" signifie aléatoire, tandis qu’omettre complètement la clé laisse l’appareil inchangé.
• Un id de modèle issu de device.templates — cet appareil, à chaque fois. Les ids intégrés sont de la forme brand|product|model, par ex. asus|ASUS_AI2401|AI2401_A ; les modèles importés dans l’application ont la même forme précédée de custom:, par ex. custom:samsung|e3qxeea|SM-S928B. Un id absent de la liste renvoie BAD_REQUEST.
• Ce que vous obtenez. Chaque champ de deviceMock rempli à partir du modèle, deviceMock.enabled défini à true, et le profil enregistré.

Quel transport

La règle habituelle du deux-points s’applique. sim.countries, device.templates, simCountries et les ids de modèles intégrés ne contiennent pas de :, donc content call les transporte. Entourez la valeur de guillemets simples dès qu’elle contient |, [, ] ou " — c’est le cas de chaque tableau simCountries et de chaque id de modèle. Sans les guillemets, le shell de l’appareil interprète | comme un pipe et échoue avant même que content ne s’exécute (sh: e3qxeea: not found, code de sortie 127). Un id personnalisé commence par custom:, et ce deux-points supplémentaire casse la forme key:type:value de --extra : l’outil content lui-même le rejette avec [ERROR] Binding not well formed et la requête n’atteint jamais l’application — il n’y a aucun BAD_REQUEST à intercepter. Envoyez les ids personnalisés via le broadcast HEADLESS_UPDATE ; rien d’autre ne change dans l’appel.

Configuration

Voici les valeurs que vous envoyez avec profile.update. Valeurs par défaut à la création d’un profil :

⚠️ Une configuration avec enabled:false est enregistrée mais inactive — les valeurs sont conservées pour que vous puissiez l’activer plus tard, mais rien n’est usurpé tant que enabled:true n’est pas défini. geo fait exception : il n’a pas d’interrupteur enabled. Les flags hook_geo_* s’appliquent dès que geo aboutit à une localisation exploitable — soit via source: CUSTOM, soit via un proxy en enabled:true qui a réussi son test en direct.

hookFlags

Par défaut : ON pour chaque flag sauf hook_spoof_uptime, qui est OFF. Une table de "flag": true|false. Une mise à jour remplace toute la table, mais uniquement la table que vous envoyez effectivement : une mise à jour qui omet complètement l’extra hookFlags laisse chaque flag exactement tel qu’il était. Dans une table que vous envoyez, chaque flag omis revient à sa propre valeur par défaut : les 26 autres repassent donc à ON tandis que hook_spoof_uptime repasse à OFF, même si vous l’aviez activé. Pour en modifier quelques-uns et conserver les autres, exécutez d’abord profile.get, modifiez la table complète, puis renvoyez-la en entier.

proxy

Par défaut : OFF. Avec enabled:true, l’application s’y connecte réellement, lit sa localisation et remplit countryCode/lat/lon/timezone. Le test en direct prend jusqu’à ~8 s ; un proxy qui échoue renvoie PROXY_INVALID et n’est pas enregistré. Ces quatre champs sont des sorties — l’application les écrit, donc tout ce que vous y envoyez est écrasé. Pour définir une localisation à la main, utilisez plutôt geo avec source: CUSTOM ; cela ne nécessite aucun proxy. profile.get renvoie le proxy avec ces quatre champs, mais ne renvoie jamais username ni 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

Par défaut : {"source":"PROXY"}. Requiert l’application 1.4.5+. C’est d’ici que provient la localisation d’un profil, et il existe deux sources — choisissez-en une avec source. PROXY utilise la localisation lue lors du test en direct du proxy. CUSTOM vous permet de définir vous-même les coordonnées, le fuseau horaire et la région, sans proxy — vous pouvez ainsi placer un profil à Tokyo tout en faisant transiter le trafic n’importe où, ou nulle part. Les trois flags hook_geo_* activent ensuite chaque partie indépendamment : GPS, région + langue, et fuseau horaire.

⚠️ Attention aux noms de champs : geo les écrit latitude/longitude, tandis que proxy ci-dessus utilise les formes courtes lat/lon. Ce sont deux objets distincts, pas des alias — les noms courts dans une charge utile geo sont tout simplement ignorés.

⚠️ source: CUSTOM doit arriver complet : une paire de coordonnées différente de 0/0 et dans les limites, un countryCode à 2 lettres et un timezone. S’il en manque un seul, l’appel renvoie BAD_REQUEST — il ne se rabat pas sur le proxy. L’application ne fait jamais de géocodage et ne se connecte jamais en ligne pour compléter ces valeurs à votre place. Si aucune source n’est finalement exploitable, aucun hook de géolocalisation n’est chargé et la localisation réelle transparaît.

🛑 timezone est le seul champ qui n’est pas vraiment vérifié. On vérifie seulement qu’il n’est pas vide — jamais par rapport à la base IANA. Une faute de frappe comme Asia/Tokyoo est acceptée, renvoie ok=true, est renvoyée telle quelle par profile.get, puis se résout silencieusement en GMT sur l’appareil. Aucune erreur n’est signalée nulle part, copiez donc le nom exactement. Les coordonnées sont l’inverse — elles sont contrôlées et une valeur hors limites échoue explicitement avec BAD_REQUEST.

CUSTOM — définir une localisation à la main, sans proxy

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 — prendre la localisation du proxy (par défaut)

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

Par défaut : OFF. Fait passer l’appareil pour un autre modèle. Définissez "enabled":true ainsi que n’importe lequel de ces champs — tous des chaînes facultatives (vides par défaut), chacune correspondant à une propriété Android Build. À partir de la 1.5.9+, vous pouvez vous passer entièrement de ce bloc et envoyer plutôt deviceTemplate — random tire un appareil de la base de l’application, un id issu de device.templates en choisit un précis — et l’application remplit chaque champ et l’active pour vous.

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"}'

Ou, à partir de la 1.5.9+, laissez l’application tirer un appareil aléatoire de sa base — sans aucun JSON (random puise indifféremment dans les modèles intégrés et importés ; mettez à sa place un id issu de device.templates pour choisir un appareil précis) :

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 deviceTemplate:s:random

sim

Par défaut : OFF. Usurpe la SIM/l’opérateur. Définissez "enabled":true et fournissez jusqu’à deux cartes dans simCards. La liste est toujours normalisée à exactement deux : une troisième carte est ignorée silencieusement — l’appel renvoie quand même ok=true — et une carte unique est complétée par une seconde carte vide, c’est pourquoi profile.get en renvoie toujours deux. À partir de la 1.5.9+, vous pouvez vous passer entièrement de ce bloc et envoyer plutôt simCountries — l’application génère de vraies données d’opérateur pour chaque emplacement et les active pour vous. Chaque carte :

networkType est débarrassé des espaces superflus et comparé sans tenir compte de la casse, et chaque génération accepte plusieurs graphies :

⚠️ Toute valeur hors de ce tableau désactive silencieusement l’usurpation du type de réseau pour cette carte — aucune erreur, aucun BAD_REQUEST, la valeur est simplement stockée et jamais utilisée. Notez que NR 5G contient une espace : NR5G n’est pas reconnu et tombe précisément dans ce piège silencieux.

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"}]}'

Ou, à partir de la 1.5.9+, laissez l’application générer les deux cartes à partir de codes pays — sans aucun JSON (l’emplacement 0 reçoit le premier code, l’emplacement 1 le second ; un seul code ne remplit que l’emplacement 0) :

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 'simCountries:s:["US","GB"]'

gmails

Par défaut : vide. Une liste de comptes Google virtuels — seules les adresses @gmail.com sont acceptées. La liste remplace la précédente ; [] la vide. Aucun : à l’intérieur, donc content call fonctionne :

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:["[email protected]","[email protected]"]'

Exemple complet

Un profil de zéro jusqu’à l’activation, étape par étape. Les étapes 5, 6 et 7 proposent chacune plusieurs façons d’arriver au même résultat — choisissez-en une par étape ; les onglets permettent de passer de l’une à l’autre. Chaque commande est présentée sous sa forme adb shell. À la fin, les deux recettes condensent toute la séquence en un seul bloc à copier et exécuter, et la section Dépannage propose la même chose sous forme de script à exécuter sur l’appareil.

En un coup d’œil

1. 01 Vérifier que l’API est prête
2. 02 Créer le profil
3. 03 Ajouter les applications cibles
4. 04 Ajouter des comptes Gmail virtuels
5. 05 Choisir l’identité de l’appareil
6. 06 Choisir les cartes SIM
7. 07 Réseau et localisation
8. 08 Ajuster les hook flags
9. 09 Sauvegarder le profil sortant
10. 10 Activer
11. 11 Vérifier
12. 12 Ensuite : cloner, arrêter, supprimer

Espaces réservés utilisés ci-dessous

• <your_access_token> — la clé issue de Paramètres → Développeur → Headless API
• <profile_id> — l’id renvoyé par l’étape 2
• <active_profile_id> / <job_id> — étape 9 uniquement, issus de status et backup.start

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method status --extra token:s:<your_access_token>
# expect  "premium":true, "featureEnabled":true, "freshnessOk":true
# anything else: fix that first — see Status and Error codes above

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}]
# copy that id — it is <profile_id> in every command below

# one call per app — the package name, not the display name
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
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.instagram.android

# check the list (adding the same package twice returns BAD_REQUEST)
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.getApps --extra token:s:<your_access_token> --extra id:s:<profile_id>

# @gmail.com only; the list replaces the previous one, [] clears it
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:["[email protected]","[email protected]"]'

# 1.5.9+ — one call, no JSON: the app rolls a device from its database
# (built-in and imported templates alike) and switches deviceMock on for you
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 deviceTemplate:s:random

# 1.5.9+ — first see what is available; "id" is what you send back
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method device.templates --extra token:s:<your_access_token>
# → [{"id":"asus|ASUS_AI2401|AI2401_A","manufacturer":"asus","label":"ROG Phone 8","isCustom":false}, ...]

# built-in id → content call works — single quotes are REQUIRED, | is a shell pipe
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 'deviceTemplate:s:asus|ASUS_AI2401|AI2401_A'

# imported (custom:) id → broadcast ONLY; the extra colon breaks content call
adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e deviceTemplate 'custom:samsung|e3qxeea|SM-S928B'

# any version — write every Build field yourself; "enabled":true is the switch
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"}'

# 1.5.9+ — see which countries the generator knows ("code" is what you send)
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method sim.countries --extra token:s:<your_access_token>
# → [{"code":"AF","country":"Afghanistan"}, ..., {"code":"GB","country":"United Kingdom"}, ..., {"code":"US","country":"United States"}, ...]

# two cards: slot 0 = US, slot 1 = GB — carrier, number, ICCID, IMSI all generated
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 'simCountries:s:["US","GB"]'

# or a single card — slot 1 is left empty
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 'simCountries:s:["US"]'

# any version — two cards, every field yourself; a third card is dropped silently
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"}]}'

# 1.5.9+ — device (step 5) and SIM (step 6) in ONE broadcast: validated together, saved together
adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e simCountries '["US","GB"]' -e deviceTemplate random

# the proxy is tested live (device needs internet, up to ~8s);
# one that fails returns PROXY_INVALID and is not saved
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"}'
# with auth: add "username":"…","password":"…" — never echoed back by profile.get

# location follows the proxy by default; this line only matters if geo was CUSTOM before
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"}'

# no proxy at all — the location is yours; coordinates, countryCode and timezone are all required
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"}'
# timezone is NOT validated: a typo silently becomes GMT — copy the IANA name exactly

# traffic through the proxy, GPS / timezone / locale from your own values —
# a deliberate mismatch (IP in one country, GPS in another); geo.source decides what the hooks use
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"}'
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"}'

# every flag is already ON (except hook_spoof_uptime), so most profiles skip this step.
# an update REPLACES the whole map — read it first, then send it back complete:
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.get --extra token:s:<your_access_token> --extra id:s:<profile_id>

# example: Wi-Fi + Bluetooth spoofing off, uptime spoofing on, everything else at its 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 hookFlags '{"hook_hide_dev_opts":true,"hook_hide_vpn":true,"hook_hide_airplane_mode":true,"hook_hide_proxy":true,"hook_hide_root":true,"hook_hide_lsposed":true,"hook_spoof_installer":true,"hook_package_info":true,"hook_lan_scan_block":true,"hook_identifiers_partly":true,"hook_identifiers_fully":true,"hook_wifi":false,"hook_nearby_wifi":true,"hook_nearby_bluetooth":false,"hook_realistic_sensor":true,"hook_sensor_accelerometer":true,"hook_sensor_gyroscope":true,"hook_sensor_light":true,"hook_sensor_magnetometer":true,"hook_sensor_fused":true,"hook_sensor_pressure":true,"hook_sensor_roster":true,"hook_spoof_uptime":true,"hook_virtual_accounts":true,"hook_geo_gps":true,"hook_geo_locale":true,"hook_geo_timezone":true}'

# activating wipes the target apps' data — if the CURRENTLY active profile has anything worth keeping, save it first
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method status --extra token:s:<your_access_token>
# → "activeProfileId" is the profile to back up

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method backup.start --extra token:s:<your_access_token> --extra id:s:<active_profile_id>
# → {"jobId":"f0e1d2c3-...", "type":"backup", ...} — poll until "state" is DONE (or FAILED):
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method backup.job --extra token:s:<your_access_token> --extra jobId:s:<job_id>

# later, once that profile is active again, pour it back:
# adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method restore.start --extra token:s:<your_access_token> --extra id:s:<active_profile_id>

# force-stops every target app, CLEARS ITS DATA, and brings it back with the new identity.
# no confirmation dialog — this comment is the only warning you get
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.setActive --extra token:s:<your_access_token> --extra id:s:<profile_id>
# → Bundle[{data={"id":"a1b2...","isActive":true}, ok=true}]
# BUSY? a backup / restore job still holds the slot — retry until it stops

adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.get --extra token:s:<your_access_token> --extra id:s:<profile_id>
# → "isActive":true, "deviceMock":{"enabled":true,...}, "sim":{"enabled":true,"simCards":[...]}, "proxy":{...}, "geo":{...}

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

# a second identity with the same settings — device re-rolled, SIM numbers regenerated, name generated
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.duplicate --extra token:s:<your_access_token> --extra id:s:<profile_id>

# stop spoofing (no id needed — it deactivates whichever profile is active)
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.deactivate --extra token:s:<your_access_token>

# delete the profile — its backups under /sdcard/HideMyAndroid_Backups/ go with it
adb shell content call --uri content://com.wowsoftware.hidemyandroid.headless --method profile.delete --extra token:s:<your_access_token> --extra id:s:<profile_id>

Deux recettes complètes

Les étapes ci-dessus, chacune condensée en un bloc à copier et exécuter. A est le chemin le plus court sur 1.5.9+ ; B se passe complètement du générateur et du proxy et fonctionne sur 1.4.5+. Dans les deux cas, remplacez <profile_id> après la première commande.

# Recipe A — everything generated (app 1.5.9+). The shortest path to a working profile.

# 1. create — 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. 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. virtual Gmail account
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:["[email protected]"]'

# 4. device + SIM in one call — a random device, slot 0 US, slot 1 GB (both enabled and saved)
adb shell am broadcast -a com.wowsoftware.hidemyandroid.HEADLESS_UPDATE -p com.wowsoftware.hidemyandroid -e token <your_access_token> -e id <profile_id> -e simCountries '["US","GB"]' -e deviceTemplate random

# 5. proxy — tested live (~8s); the location follows 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 proxy '{"enabled":true,"host":"10.0.0.1","port":1080,"protocol":"SOCKS5"}'

# 6. activate — clears the target app's 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>

# 7. 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>

# Recipe B — everything by hand (app 1.4.5+). No generator, no proxy: you control every value.

# 1. create — 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. 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. 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:["[email protected]","[email protected]"]'

# 4. device — every Build field yourself
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. SIM — two cards, every field yourself
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. location — custom, no proxy (all four fields required; timezone is not validated)
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"}'

# 7. activate — clears the target app's 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>

# 8. 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>

Codes d’erreur

En cas d’échec, vous obtenez ok=false avec l’une de ces valeurs d’error_code (les broadcasts renvoient result=1) :

Conseils & dépannage

• Un broadcast ne fait rien ? Vérifiez que vous avez inclus -p com.wowsoftware.hidemyandroid — Android bloque les broadcasts sans ce paramètre.
• Une valeur a été tronquée après un : ? Cette valeur contient un deux-points, donc content call l’a tronquée. Envoyez-la plutôt via le broadcast HEADLESS_UPDATE.
• Un broadcast JSON ne s’applique pas (souvent sous Windows) ? Entre un shell de bureau et le shell de l’appareil, les guillemets du JSON de am broadcast (hookFlags, proxy, deviceMock, sim) sont facilement supprimés, si bien que am interprète mal la valeur (vous pouvez la voir arriver comme une URI de données dat=…) et rien ne change. La solution fiable consiste à garder le JSON hors de la ligne de commande — placez tout le workflow dans un fichier .sh (les guillemets simples préservent chaque JSON), puis poussez-le et exécutez-le sur l’appareil. Le script s’exécute sur l’appareil, il peut donc même récupérer l’id du nouveau profil et le réutiliser :
  bash Copy

  # setup.sh — Recipe A from 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:["[email protected]","[email protected]"]'
  
  # 4. device + SIM generated from the database (1.5.9+): random device, slot 0 US, slot 1 GB
  am broadcast -a $PKG.HEADLESS_UPDATE -p $PKG -e token $K -e id $ID -e simCountries '["US","GB"]' -e deviceTemplate random
  #    Recipe B alternative (any version) — write both blocks yourself instead:
  # 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"}'
  # 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"}]}'
  
  # 5. enable + set the proxy (tested live, ~8s) — the location follows it
  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"}'
  #    Or skip the proxy and set the location yourself (use INSTEAD of the proxy line, 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"}'
  
  # 6. activate (restarts the target app and clears its data)
  content call --uri $URI --method profile.setActive --extra token:s:$K --extra id:s:$ID
  
  # 7. verify
  content call --uri $URI --method profile.get --extra token:s:$K --extra id:s:$ID

  puis poussez-le sur l’appareil et exécutez-le :
  bash Copy

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

  Les commandes content call simples (sans JSON) peuvent être saisies directement sans script. Dans Git Bash, préfixez les lignes adb par MSYS_NO_PATHCONV=1 pour que le chemin sur l’appareil ne soit pas réécrit.
• Les modifications n’apparaissent pas ? L’application cible doit redémarrer — activer un profil s’en charge pour vous, et efface les données de cette application dans la même étape, afin qu’elle redémarre avec la nouvelle identité et sans rien conserver de l’état précédent.
• PROXY_INVALID pour un proxy fiable ? L’appareil a besoin d’internet pour le test, limité à ~8 s ; un proxy lent peut donc dépasser le délai.
• BUSY pour une tâche déjà annulée ? backup.cancel fait passer la tâche à CANCELLED (et renseigne finishedAt) immédiatement, mais le tar qu’elle a lancé ne peut pas être interrompu et continue de tourner, donc le créneau reste occupé. backup.job affiche CANCELLED alors que le créneau est encore occupé, et aucun champ n’indique l’état du créneau — ne considérez pas CANCELLED comme « créneau libre » ; réessayez simplement profile.setActive / deactivate / delete jusqu’à ce qu’ils cessent de renvoyer BUSY. (Une tâche qui se termine normalement en DONE ou FAILED libère le créneau presque aussitôt.)
• Binding not well formed pour un id de modèle copié directement depuis device.templates ? Les modèles importés ont des ids qui commencent par custom:, et ce deux-points casse la forme key:type:value de --extra — l’outil content affiche [ERROR] Binding not well formed suivi de son texte d’aide, et la requête n’atteint jamais l’application. Envoyez-le plutôt avec le broadcast HEADLESS_UPDATE (-e deviceTemplate 'custom:…'). Les ids intégrés (brand|product|model) ne contiennent pas de deux-points et fonctionnent avec l’un ou l’autre transport — mais entourez-les de guillemets simples, sinon le shell interprète | comme un pipe (sh: e3qxeea: not found) et rien n’est envoyé.