[kkkhs]

Summary

Fixes #3327. Install/reinstall/uninstall allow 480s; source installs allow 600s. Native installs have a 120s bound. The ledger covers readiness, metadata, uninstall, install, bundletool, and download with 30s for the daemon result.

This 41-file change also fixes stale readiness bindings and stopped-AVD admission. Command declarations own stopped-AVD scope across request phases. Provider deployment contracts remain intact. Help and release notes document the bounds.

agent-device install ./app.apk --platform android --device Pixel_8
agent-device install-from-source https://example.com/app.aab --platform android

Validation

Rebased onto dc643f00ca; tested head 6bce433f24641a27fe51d19738e0b2b3462be5a4. pnpm check:affected --run --head 6bce433f24641a27fe51d19738e0b2b3462be5a4 passed with exactCommit=true; receipt run-ed4WxZ. Format, lint, types, layering, Fallow, build, related integration, unit, and documentation checks passed.

git range-diff retains all 18 patches. The sole conflict preserves main’s shared XML visitor and this PR’s plist timeout. Independent rebase review found no issues.

• Before rebase: d9d7539 passed check:affected (run-Hmcb5Q). After rebase: the same command passes at the head above.
• 23 ledger cases and focused plist/import tests pass.
• Live evidence before rebase: nine successful routes at d9d7539; these were not rerun after rebasing.
• Earlier APK/AAB/path/URL evidence retains its original source SHAs.
• Coverage/native/device checks remain GitHub-owned. Vercel requires fork authorization. Physical iOS remains unverified on hardware.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.

[thymikee]

The install timeout ledger does not yet prove the 330s and 420s envelopes at d0afa30. Android install, reinstall and install_source on a shutdown emulator can still be cut off by the client before the daemon returns its typed timeout, which is the failure #3327 asks the ledger to rule out. The Android scenarios in install-timeout-ledger.test.ts use booted: true, so the ledger never records ensureAndroidReady. The deployment runtime calls it when device.booted !== true. On a shutdown AVD that path runs ensureEmulatorReady with waitForBoot at 120s. The local provider has no installBundle, so an AAB takes the bundletool fallback. That puts the worst case near 120 + 15 + 120 + 120 = 375s, plus the 30s margin, so about 405s against the 330s envelope. With the URL download it is about 525s against 420s. The iOS simulator scenario does model the unbooted case, so the two platforms use different definitions of worst case. The rule: every route ledger starts from the least-ready state the deployment runtime accepts and includes every phase that runtime can run before and after the install subprocess. Please give the Android scenarios an unbooted emulator, run the URL-source case for every route, then raise the envelopes or lower the phase bounds until the largest ledger fits.

ANDROID_BUNDLETOOL_TIMEOUT_MS = 120_000 at line 61 is a copy of the non-exported ANDROID_APP_INSTALL_TIMEOUT_MS in native.ts. If someone raises the production value to 200_000, the real AAB route grows by about 160s, but the ledger still adds 2 x 120s and stays green. native.test.ts also hardcodes 120_000. The ledger must break when a subprocess bound goes up. Could the bundletool fake record the timeout it actually received, for example through the command-executor override that already handles bundletool and java? If that does not work, export the constant from the platform-android entry and import it in both tests.

This PR adds new bounds on device-facing routes: adb install 120s, bundletool 120s, adb uninstall 15s, simctl install 120s, and simctl and devicectl uninstall 20s. Before this change, adb install and simctl install had no subprocess bound and ran inside the 180s client envelope. An install that took 120 to 180s used to succeed and would now fail. Nothing in the PR shows that ordinary installs still succeed. Please run install, reinstall and install_source (path and URL) on an Android emulator (an APK, and an AAB through the bundletool fallback) and on an iOS simulator. Each command must succeed, and the request log must show the adb install, bundletool and simctl install calls with their timeoutMs. Please also add a CHANGELOG entry for the new 120s install bound and the new envelopes.

All 16 checks pass at d0afa30, but the CI device lanes do not run an unbooted-emulator AAB install, so green CI does not cover the first point. There are no conflicts. I did not run the ledger test; the numbers above come from adding up the constants at this commit. Two gaps remain outside this diff: cloud providers that implement install or installBundle may ignore the new timeoutMs, and in-process archive extraction for install_source is limited by size only, not by time. Before merge, the ledger needs the unbooted Android phase and the URL route for every route, the envelopes need recomputing, the bundletool timeout needs to come from the real call, and the live Android and iOS simulator runs need to be shown.

[kkkhs]

Thanks, agreed. I don’t have the Android emulator and iOS simulator validation environment available in my current setup, so I’ll pause this PR rather than push a partial ledger-only update.

I’ll resume once I can run the live install, reinstall, and install_source matrix for Android and iOS and include the request log evidence with the timeout values.

[vercel]

@thymikee is attempting to deploy a commit to the Callstack Team on Vercel.

A member of the Team first needs to authorize it.

[thymikee]

Thanks for the update. The timeout and ledger work now looks right, and the new head (07e4342) fixes the install-family bounds from the earlier review (#3814 (comment)). Two things remain before merge.

Android push lost its timeout. Commit a19acaf changed the default in runAdb from timeoutMs = 15_000 to timeoutMs?: number, and pushAndroidNotification passes no value. Neither the tool host (src/platform-runtime-android-tool-host.ts:30-35) nor runAndroidAdb (adb.ts:17) adds one, so adb shell am broadcast now runs unbounded. On main, a hung adb fails after 15s with the daemon's typed timeout. Here, the client's 90s envelope aborts first and the user gets no daemon result. The changeset says only install-family bounds changed, and the assertion at native.test.ts:139 now locks in timeoutMs: undefined. The rule: every adb call in the deployment owner keeps a finite bound, and no call loses the bound main gave it. Please pass ANDROID_APP_DEPLOYMENT_ADB_TIMEOUT_MS at line 80 (or make it the required runAdb default again), and change the test to assert timeoutMs: 15_000.

The new shutdown-AVD route has no live evidence. The daemon now calls ensureReady on a shut-down local Android AVD, then admits and rebinds the discovered emulator-5554 serial before deployApp (session-app-deployment.ts, and the same for install_source at session-app-source-deployment.ts:92). The binding key also changed for every command (request-runtime-binding.ts:129). The live matrix ran at 9eea80f on an already-booted emulator and simulator, and 6799e6b, 709c4f2 and a19acaf landed after it. So the fix for #3327 that matters on Android is covered only by fakes. Please run install <apk>, reinstall <pkg> <apk> and install-from-source <url> with the AVD shut down, using --platform android --device <AVD name> with the plain CLI, at 07e4342 or later with AGENT_DEVICE_EXEC_TRACE=true. Each command should succeed, and the request log should show one emulator launch, sys.boot_completed polling, then adb or bundletool install calls addressed to the discovered serial with timeoutMs 120000, and no second boot. Please also rerun one booted-emulator install and one iOS simulator install at head, since the binding key changed after the earlier evidence.

Could the readiness rule live in one place? For example, bindReadyDevice(device, use) in request-runtime-binding.ts could call ensureReady when the use declares it, compare deviceIdentityKey before and after, and admit and rebind on change. Install, reinstall, install_source, uninstall and push would all call it. Then the platform and owner-kind check in session-app-deployment.ts, the id check in session-app-source-deployment.ts and the readiness branches in deployAndroidApp could go. What would need deciding first is whether provider-owned runtimes must expose a conditional ensureReady or keep readiness inside deployApp.

Not blocking, and you can take or leave these: uninstall (platform-android/src/deployment/runtime.ts:71-91 boots inside the runtime and changes the serial) and push (session-app-deployment.ts:169 readies, then dispatches on the old binding) have the same identity change but get no rebind, and I read this from the code without reproducing it. If you keep them out of scope, a follow-up issue is better than a fourth local guard. Also, deployAndroidApp still calls ensureAndroidReady at runtime.ts:107 and :129 and ignores the returned device. After the daemon readies local-family devices, these can only fire for a non-local-family owner, which I did not check, so please delete them or use the returned device.

The Smoke Tests failure looks unrelated: the iOS phase failed in smoke:form-input when keyboard dismiss returned UNSUPPORTED_OPERATION, and that smoke uses simctl install directly. The Vercel failure is a fork authorization error. I did not run the ledger suite or the mutations, so those counts are yours. Once the push timeout is restored and the live shutdown-AVD run is attached, this is ready for another look.

[cubic-dev-ai]

All reported issues were addressed across 27 files

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Re-trigger cubic</sub>

[thymikee]

Thanks for the update. The ledger and mutation evidence are in good shape, but two things still need work at c5a626e. This follows the earlier 07e4342 review.

Android push still has no adb bound. runAdb now takes timeoutMs?: number (native.ts:213), and native.ts:80 passes none, so adb shell am broadcast runs unbounded. On main a hung adb fails after 15 s with the daemon's typed timeout. Here the 90 s client envelope aborts first and the user gets no daemon result. This breaks the #3327 rule that every adb call keeps a finite bound. The rule is that every runAdb call in the deployment owner has a finite bound. Could you make timeoutMs a required parameter (or restore the 15_000 default) so the type covers every call site, pass ANDROID_APP_DEPLOYMENT_ADB_TIMEOUT_MS at line 80, and change native.test.ts:139 to assert timeoutMs: 15_000? It currently asserts undefined, which locks in the gap.

The new shut-down AVD route has only fake coverage. The PR now readies a stopped local AVD and rebinds the new serial before deployApp and install_source (session-app-deployment.ts:96-108, session-app-source-deployment.ts:88-99). It also changes the binding key for every command (request-runtime-binding.ts:129). The only live run is at 9eea80f on already booted targets, and the ledger says the shut-down AVD attempt stopped at selector validation because the device-panel CLI pins a serial. The plain CLI can select a stopped AVD (device-selection-resolver.ts:111), so the route is reachable. Please run the plain agent-device CLI outside the device-panel binding, with no pinned serial, the AVD shut down, --platform android --device <AVD name> and AGENT_DEVICE_EXEC_TRACE=true, at c5a626e or later. Run install <apk>, reinstall <pkg> <apk> and install-from-source <url>. Each must succeed, and each request log must show one emulator launch, sys.boot_completed polling, then adb or bundletool install calls addressed to the discovered emulator-NNNN serial with timeoutMs 120000, and no second boot. Please also rerun one booted-emulator install and one iOS simulator install at head, because the binding key changed after 9eea80f.

I did not run the ledger suite or the mutations at c5a626e. The tests now use vi.spyOn(hostCommands, 'runCmd') instead of withCommandExecutorOverride, and I could not confirm that this spy intercepts the daemon's runCmd calls. I also did not reproduce the same-id rebind gap below on a device.

Open review threads: the same-id rebind P1 and the ledger 330s/420s wording P2 still apply, as does the unbounded push broadcast P2 covered above. The aapt timeout thread does not apply, because aapt was unbounded on main and a 15 s typed COMMAND_FAILED is the bound #3327 asks for. The iOS uninstall timeout thread does not apply either, because a hung uninstall never produces the missing-app output the tolerance matches, and the live reinstall shows the 20 s bound succeeding. Please resolve those two.

The only check that is not passing is Vercel, which shows a team authorization link for a fork PR. It looks unrelated to the code, but it means the docs change in website/docs/docs/commands.md was not built. Before merge, restore the finite adb bound on push and attach the live plain-CLI shut-down AVD run at head.

[thymikee]

Addressed the review at 84e5cce37cce1c592fe154b1b4ded9534ebf444b.

• Push broadcast now has an explicit 15s bound; runAdb requires a timeout.
• Source installs always bind the readiness result through the existing cache, covering same-ID boot changes without another local identity guard.
• The live plain-CLI run exposed an additional DEVICE_NOT_FOUND: install selection omitted stopped AVDs. The command declarations now own this policy across locks, provider context, claim admission, and handlers; the inventory fake honors it. All 23 ledger cases pass; removing this fix fails 11.
• Three stopped-AVD commands (install, reinstall, URL source) succeeded at 49ba34bdb2: one emulator launch each, boot polling, then install to emulator-5554 with timeoutMs: 120000, with no second boot. Warm Android and iOS simulator installs passed too. Commands and request evidence. Fixtures were uninstalled and temporary services stopped.
• The hostCommands spy runs through the real daemon/local adapters; the recorded install-bound mutations fail when the production cap changes. Corrected the 330s/420s mutation wording. Replied to and resolved the aapt/uninstall findings with the reasons from your review.

Passed with exactCommit=true; receipt run-OLvTHD: format, lint, types, layering, Fallow, build, related integration, all 16,474 unit tests (1 skipped), and command documentation/links/prose checks.. The earlier Apple smoke failure is no longer current: every GitHub check at c5a626e passed except skipped jobs and Vercel's fork authorization. The local docs-links gate also builds the website. CI must rerun on this head; no physical iOS device was available.

[thymikee]

I found no code defects at 84e5cce, and the earlier findings from c5a626e (#3814 (comment)) are fixed. The change still lacks live evidence at this exact commit, so I consider it evidence-pending. The stopped-AVD live run and the iOS simulator install were done at 49ba34b. The diff from there to 84e5cce only touches ledger text, one import order and one test expectation, so I judge that run still covers head, but I did not rerun it. No physical iOS device run exists. I did not run the ledger suite, the unit tests or the mutation experiments at head, so the 23-pass / 11-fail counts and the run-OLvTHD receipt are the author's.

Simplicity question: the descriptor field now owns the stopped-AVD scope, but boot and shutdown (https://github.com/callstack/agent-device/blob/84e5cce/src/daemon/session-device-resolution.ts#L88 and #L103) and capabilities and apps (https://github.com/callstack/agent-device/blob/84e5cce/src/daemon/sessions/session-lifecycle/internal/inventory.ts#L278 and #L352) still hard-code the same policy. Because of that split, the advisory device lock for boot and shutdown (https://github.com/callstack/agent-device/blob/84e5cce/src/daemon/request-binding.ts#L151) still resolves running-only while their handlers include stopped AVDs. Could boot, shutdown, capabilities and apps declare androidAvdSelection: 'include-stopped' on their descriptors, so the override in resolvePowerCommandDevice and the inventory literals go away and one table owns the scope? This can land here or as a follow-up. Minor: session-app-source-deployment.ts:171 passes the literal 'install_source' instead of the request's command.

The five inline threads no longer apply and are already resolved: the same-id rebind (#3814 (comment)) and the 330s/420s ledger label (#3814 (comment)) are fixed at head, and so is the required adb timeout in native.ts (#3814 (comment)). The 15 s aapt bound (#3814 (comment)) and the 20 s uninstall bound (#3814 (comment)) are intended: the first replaces an unbounded call with the finite typed failure #3327 asks for, and the second cannot hide the missing-app output, and the live reinstall succeeded within it.

The only check not passing is Vercel, and it fails on a team authorization link for this fork PR, so no deploy build ran. The two-line change in website/docs/docs/commands.md is checked only by the author's local docs-links gate. No code job fails at head. There are no conflicts.

[thymikee]

Addressed the remaining policy consolidation from #3814 (comment) at d9d753903c90335862b2777af2ebe7daa970ecfd.

• Boot, shutdown, capabilities, and apps now declare androidAvdSelection: 'include-stopped' in the command registry. Advisory locks, provider context, claim admission, and handlers read that declaration.
• Removed resolvePowerCommandDevice, the shutdown-only branch in bounded admission, and inventory policy literals. Boot retains its --pick selection logic. Source selection now uses req.command.
• Focused validation: 48 unit cases, 29 provider/ledger cases, and 879 import guards pass. The strengthened router suite passes 5 cases at head; restoring the prior production sources produces 3 failures and 2 passes. The disposable checkout was removed. Independent review found no issues.

All live requests below ran against a fresh daemon built from this exact commit, exited 0, and returned success. Android commands used --platform android --device ReactNative_API_35B without a pinned serial. The AVD was shut down before each cold request; URL source installation began with the fixture uninstalled. The iOS target was simulator BC54AC11-CD86-4C10-8C4E-5101C773FFEB.

Operation	Request	Emulator launches	Readiness probes	Install bound
capabilities	937a25e1f64e1380	0	0	—
shutdown	de07ba218d7a6884	0	0	—
boot	7d9f3d993b957ba9	1	1	—
apps	6727db30d73a580d	1	1	—
cold-install	a98db525b8c18b6d	1	1	120000 ms
cold-reinstall	bdd3ce77d5fc8107	1	1	120000 ms
cold-source	ba5a1abc28391c9a	1	1	120000 ms
warm-install	5b974655d3053a66	0	0	120000 ms
ios-install	4d0fd59eba8f6e6b	0	0	120000 ms

AGENT_DEVICE_EXEC_TRACE=true recorded the native bounds. The temporary spawn observer recorded actual argv and PIDs; PID joins identify adb -s emulator-5554 install -r <artifact> and xcrun simctl install <udid> <artifact>. Each cold install had one launch, then sys.boot_completed, then install, with no second boot. Capabilities reported the AVD stopped; boot returned the discovered serial; apps returned inventory after one boot. No providers or subprocess results were faked.

Both fixtures were uninstalled. The isolated daemon, fixture server, and tunnel are stopped. No physical iOS device was available.

pnpm check:affected --run --head d9d753903c90335862b2777af2ebe7daa970ecfd passed with exactCommit=true; receipt run-Hmcb5Q. Format, lint, types, layering, Fallow, build, related integration, unit, and documentation checks passed. Coverage/native/device lanes remain GitHub-owned.

[cubic-dev-ai]

1 issue found across 9 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/daemon/src/server/__tests__/request-router-selection.test.ts">

<violation number="1" location="packages/daemon/src/server/__tests__/request-router-selection.test.ts:89">
P3: This fixture aliases the Android serial to the display name, so the new cases no longer exercise name selection with distinct device identity fields. Keep the original serial to preserve coverage for accidental `--device`/serial confusion.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

View guided diff | Re-trigger cubic</sub>

[cubic-dev-ai]

P3: This fixture aliases the Android serial to the display name, so the new cases no longer exercise name selection with distinct device identity fields. Keep the original serial to preserve coverage for accidental --device/serial confusion.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At packages/daemon/src/server/__tests__/request-router-selection.test.ts, line 89:

<comment>This fixture aliases the Android serial to the display name, so the new cases no longer exercise name selection with distinct device identity fields. Keep the original serial to preserve coverage for accidental `--device`/serial confusion.</comment>

<file context>
@@ -80,33 +82,37 @@ test('fresh no-app foreground open selects iOS from mixed Android and iOS invent
+  '%s keeps stopped-AVD selection consistent through request admission',
+  async (command) => {
+    const inventoryRequests: Array<{ platform?: string; androidAvdSelection?: string }> = [];
+    const stopped = { ...android, id: android.name, booted: false };
+    const { handler, inspectFacts } = selectionHandler([stopped], inventoryRequests);
+    const selected = await handler({
</file context>

Suggested change

	const stopped = { ...android, id: android.name, booted: false };
	const stopped = { ...android, booted: false };

[thymikee]

I found no code problems at d9d7539, and the issues from the earlier review (84e5cce) are fixed.

I did not run the router, unit, ledger or integration suites, or check:affected, at this head. The pass counts, the 3-fail/2-pass mutation result and receipt run-Hmcb5Q are author-reported. I also had no logs to cross-check the live matrix at d9d7539 (request ids in comment 6527356260). No physical iOS device run exists, so the iOS install evidence is simulator-only.

Only Vercel fails. It fails on the team authorization link for this fork PR, so no deploy build ran. This update touches only command-registry and daemon sources and tests, not website/, so I read the failure as unrelated to the code. There are no conflicts.

The Cubic P3 thread on the stopped-AVD fixture does not apply. Stopped AVDs have id equal to the AVD name (listStoppedAvds sets id: name), so { ...android, id: android.name, booted: false } is the shape the router sees. A distinct serial cannot exist before boot. It can be resolved: #3814 (comment)

[thymikee]

Main moved after my review at d9d7539, and this branch now has merge conflicts, so I removed ready-for-human for now. The code verdict is unchanged. Please rebase on main; I will look at the conflict resolution and put the label back if nothing else changed.