Setup and session state

Persistent files

/data/voice-agent/session.json stores account_id, env, is_test_account, secret, and session. This is the Marusya session used after provisioning. It is different from the one-time xToken used during setup.

/data/voice-agent/device_settings.json stores the cloud device ID and settings such as name, timezone, volume, call, and update-related fields. Wi-Fi and network state also lives under /data/overlay/upper/etc and /data/overlay/upper/var.

The credentials are sensitive. The repository records their existence and schema, not their values.

Setup engine

voice-agent contains a setup engine with manual setup entry, audio setup, success/failure handling, and auto-exit. Its strings include startSetupEngine, Audio setup failed, OnSetupSucceeded, OnSetupFailed, and checkSetupModeAutoExit.

A successful configuration writes persistent session data and makes account/info_xtoken return CONNECTED. A failed setup may write /data/do_factory_reset through hwResetDevice, causing the next boot to erase state and return to onboarding.

OnSetupFailed distinguishes these outcomes: code 2 is corrupted configuration, code 3 has its own prompt, code 5 is another non-reset setup error, code 6 is a separate failure prompt, and code 7 is the VK ID mismatch path. Attach failures 2–6 map to setup codes 5, 6, 3, 7, and 4 respectively. Only code 4 calls hwResetDevice; an expired token or bad network response must not automatically be treated as a reset unless its attach category is 6.

First-boot behavior

The live command line contains androidboot.firstboot=1. This flag remains present even after provisioning and is not, by itself, proof that setup was not completed. Use account/info_xtoken and device_online for the actual state.

Re-flashing implications

Restoring an old data image restores the old session verbatim; there is no local TTL check that converts it into a fresh provisioning flow. The server can still reject or revoke it, and VoiceEngineImpl has an UpgradeVkToken path for token upgrades. Conversely, rebuilding data without the session forces onboarding again. Hardware identity is not rewritten by a data restore, so a mismatched hardware key and restored account can only be resolved through cloud behavior, not local expiry logic. Any setup or jailbreak workflow must treat session preservation and xToken freshness as separate concerns.