ADFA-4128 (11/11): app + bench — wiring Quick Build into the IDE and the benchmark harness

[fryanpan]

Part 11/11 of the stacked split of #1669 (requested by Akash). Base: feature/ADFA-4128-qb-10-gradle-plugin. Stack overview + review mechanics: PR 1 (#1713). Terms are defined in quickbuild/README.md (lands in PR 1).

Puts Quick Build in front of the user: a button next to Run, and enough narration to tell what it is doing and when it has finished. It also adds a harness to make it easier to run standard Gradle build and Quick Build benchmarks, and to gather key metrics about the stages of the build process.

flowchart TB
    subgraph appc["<b>This PR: inside app/ — wiring and bench</b>"]
        act["QuickBuildAction<br/>registered only when<br/>FeatureFlags.isExperimentsEnabled<br/><i>QuickBuildAction.kt</i>"] --> mgr["QuickBuildManager<br/>session lifecycle, provisioning,<br/>stop-tap cancellation"]
        mgr --> narr["QuickBuildOutputNarrator<br/>attached to the session manager;<br/>queues while no pane is bound<br/><i>QuickBuildOutputNarrator.kt</i>"]
        mgr --> sb["status bar collector<br/>lifecycle-scoped: state, not history<br/><i>QuickBuildStatusBar.kt</i>"]
        koin["QuickBuildModule (Koin)<br/>binds every core port;<br/>assetsLiveReloadable read once<br/>at the Android edge<br/><i>QuickBuildModule.kt</i>"]
        tr["bench trampoline activity<br/>debug-source-set manifest only<br/><i>QuickBuildBenchActivity.kt</i>"] --> mgr
        mgr --> hooks["QuickBuildBenchHooks<br/>inert release twin<br/><i>debug/QuickBuildBenchHooks.kt</i>"]
        hooks --> rec["event + metrics recorders"]
        rec --> log["bench-events.jsonl<br/><i>BenchEventsFile.kt</i>"]
        hooks --> e2e["MODE_STANDARD_E2E<br/>measures the standard build<br/>through install + launch<br/><i>QuickBuildBenchAutostart.kt</i>"]
    end
    adb["adb shell am start<br/>gated on android.permission.DUMP"] --> tr
    mgr --> core[":quickbuild:core session manager (PRs 5-8)"]
    narr --> pane["Build Output pane (existing)"]
    sb --> bar["bottom status bar (existing)"]
    mgr -- "provisioning + rebuild builds" --> gbs["GradleBuildService (existing)"]
    classDef thisPrBox fill:#dbeafe,stroke:#93c5fd,color:#1e3a5f
    classDef inPr fill:#ffffff,stroke:#64748b,color:#000
    class appc thisPrBox
    class act,mgr,narr,sb,koin,tr,hooks,rec,log,e2e inPr

Loading

What to review

• QuickBuildAction.kt — owns the session tap: start, stop-tap cancel, grey-out. Line-by-line.

• Gradle tuning — Metaspace 192→384 MB + daemon idle timeouts (30 min balanced / 2 h high-perf); the only changes to non-QB behavior

• QuickBuildOutputNarrator.kt, QuickBuildStatusBar.kt — queued narration; lifecycle-scoped status showing state, not history.

• QuickBuildModule.kt — binds every core port; reads assetsLiveReloadable at the Android edge.

• GenerateSourcesDeferral.kt — defers resource-XML generateSources until Quick Build goes idle.

• John's items C15, C16, C17, C22, C23 folded in as fixes.

• Rollback: without the flag there is no UI entry point.

• Followup, not fixed: R8 emits kotlin.Metadata warning noise.

• QuickBuildBenchAutostart.kt — MODE_STANDARD_E2E measures the standard build through install and launch. Line-by-line.

• The e2e latch bypasses install confirmations only for the measured span.

• QuickBuildBenchActivity.kt, QuickBuildBenchHooks.kt — DUMP-gated trampoline; inert release twin.

• BenchEventsFile.kt — a failed relaunch omits relaunchOk rather than recording zero.

How this PR Was Tested

• Automated tests (see coverage details below)

• Manual QA — walked the manual-qa.md test plan on the A56 [measured on a56]

• Benchmark — measured on real devices, both arms: a warm code edit reaches the running app with about a 5x median speedup over a standard build + deploy. The weaker the phone, the bigger the win. MODE_STANDARD_E2E drove the standard arm through install and launch.

• Still open — the rebaseline relaunch path is not yet device-verified, and neither is the API 28/29 resource-swap success path.

Coverage (JaCoCo at the stack tip, single run):

A lot of this was UI code and wasn't covered very well by automated tests.

Package	Line	Branch	Note
actions/build	0.5%	0.0%	UI — device-tested
actions/file	0.0%	0.0%	UI — device-tested
activities/editor	0.9%	1.8%	UI — device-tested
analytics/quickbuild	49.6%	30.4%
app	0.7%	0.5%	Application classes, Android-bound
di	0.0%	0.0%	Koin wiring
fragments/sidebar	0.0%	0.0%	UI — device-tested
handlers	7.6%	0.0%	Android-bound
quickbuild	27.3%	24.3%	mixed UI/logic; see caveat
services/builder	6.8%	0.0%	bound Service, Android-bound
utils	0.0%	0.0%	mixed UI/logic
viewmodel	0.9%	0.0%	UI — device-tested
TOTAL (all app files in this PR)	16.9%	15.3%	2,989 lines, 1,582 branches

Review fixes (2026-08-22)

A review-fixes commit addresses the code-review findings. Two changes here deliberately ship to all users, with the Experiments flag off (approved):

• GradleBuildTuner. Benefit: builds stop dying with out-of-memory errors on ordinary phones, and a rebuild shortly after a build is much faster. Two settings on every Gradle build: (a) the Metaspace cap (JVM memory for loaded class definitions) goes 192 MB -> 384 MB -- real Android-plugin builds exceed 192 and were being killed mid-build; it's a cap, not a reservation, so no extra memory is used unless the build needs it. (b) The Gradle daemon (the background process that keeps builds warm) stays alive for a time matched to the phone's tier -- 15 min low-memory, 30 min balanced, 2 h high-performance -- so a quick rebuild skips the cold start while weak phones don't host a resident daemon for hours.
• generateSources narrowing. Benefit: fewer surprise build stalls while editing, less battery and CPU burned. The IDE used to launch a Gradle generate-sources step after every save-all and any XML save, even when nothing that step produces could have changed. Now it runs only when the saved file can actually affect generated sources. Same results, far fewer builds.

One candidate followup from review (orchestrator forcing a full-changed compile after a failed dex/deploy) was re-checked and refuted at this tip: the forced flag re-arms and a forced no-op already performs the full rebuild. The daemon-side recovery lever stays in as defense in depth.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Kj9YeCDHGp9DU8LPtfWJ7W

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.

_{Tip: disable this comment in your organization's Code Review settings.}

[fryanpan]

@coderabbitai review

[coderabbitai]

⚠️ Action not completed

Review skipped: 106 files exceed the limit of 100.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[jatezzz]

@fryanpan — review of the Quick Build app wiring. Seven findings; two are worth fixing before merge and are left as inline comments:

• ProjectHandlerActivity.kt:549 — the reArmInstall safety net does not cover the clobber dialog, so a rotation while it is up loses the install silently.
• QuickBuildStatusBar.kt:151 — a landed build is re-announced on every re-subscribe and, with onlyIfOwned = false, stomps project-init / plugin-install status.

The remaining five are low: the session teardown on a transient APK parse failure, the null-activity path that builds stale content, the ellipsized actionable status copy, and three unused imports that should fail spotlessCheck.

---

One more (low), which could not be left inline because the file is not in this diff:

app/src/main/java/com/itsaky/androidide/actions/BaseBuildAction.kt:43 — a missed sibling of this PR's raw-vs-user-visible split.

This PR moved every UI decider over to isUserVisibleBuildInProgress — AbstractCancellableRunAction, ProjectHandlerActivity.onResume, the progress bar, BuildVariantsFragment — but BaseBuildAction.prepare still reads the raw flag:

enabled = buildService?.let { !it.isBuildInProgress } == true

With the experiments flag on, Quick Build's eager prebuild now runs on every project open, so RunTasksAction (and any other direct BaseBuildAction) is silently greyed out for its whole duration with no explanation — unlike QuickBuildAction, which relabels, or QuickRunAction, which flashes msg_build_slot_busy. Note that AbstractCancellableRunAction.prepare unconditionally re-sets enabled = true, which is why its new slot-busy flash is reachable and these are not.

---

Checked and cleared: all new string/drawable/menu resources resolve on the head branch; ProjectManagerImpl.generateSources() returns Boolean, so GenerateSourcesDeferral's refusal-retry contract holds and a throw is treated as a refusal rather than cancelling the scope; InternalBuildBracket releases strictly after isBuildInProgress clears, so there is no window where isUserVisibleBuildInProgress reads true for an internal build; QuickBuildOutputNarrator confines its mutable state to one Dispatchers.Main.immediate scope and compares sink identity correctly; QuickBuildReloadTimingMetric.asBundle() is 25 params worst case, within the Firebase cap; ThermalSafeStrategy copies GradleDaemonConfig, so the new non-defaulted daemonIdleTimeoutMs is safe and 2h fits in Int; and InstallationResultHandler.onResult returning null is handled as "do nothing" by its only caller.

[jatezzz]

@fryanpan medium — the re-arm safety net does not cover the clobber dialog.

dispatched = true is set before the dialog is shown, so finally { if (!dispatched) buildViewModel.reArmInstall(state) } treats "dialog opened" as "install dispatched".

Scenario: a Standard Run build finishes, the "Replace the app installed for this project?" dialog appears, the user rotates the device. The dialog is dismissed along with the activity, onConfirm never fires, doInstallApk never runs, and nothing re-arms AwaitingInstall. A successful build ends with no install and no message — the exact failure mode the re-arm was added to prevent.

Suggest keeping dispatched = false until a decision is actually reached, so the net also covers "dialog shown but dismissed without a decision".

[jatezzz]

@fryanpan medium — a landed build is re-announced on every re-subscribe, and it stomps other status.

This current.buildDurationMillis != null branch is tested before the previous == null branch and emits Show(..., onlyIfOwned = false).

The status collector runs in repeatOnLifecycle(STARTED) with a local previousStatus reset to null on every re-subscribe, and QuickBuildStatus is a StateFlow, so it replays. Every time the user returns to the editor after a Quick Build has landed, the bar re-writes "Quick Build: reloaded to generation N in 2.3s" for a build that finished long ago — and because onlyIfOwned = false, it clobbers whatever took the bar in the meantime (project-init / plugin-install status).

That directly contradicts the KDoc above, which says "a 'Project initialized' message is not stomped by a session that has nothing to say."

Fix either way: require previous != null for the landed-build branch, or pass onlyIfOwned = true when previous == null.

[jatezzz]

@fryanpan low — a transient APK parse failure tears down a healthy session.

onProceed calls restartSession() whenever now != NotNeeded, but NeededForUnknownAppId is produced by any runCatching failure in apkApplicationId — including a transient packageManager.getPackageArchiveInfo failure on the freshly built APK.

Only is Needed actually asserts that the proxy app occupies the slot. As written, a parse hiccup kills a live, healthy Quick Build session for no established reason. Consider restarting only on is Needed.

[jatezzz]

@fryanpan low — the null-activity path skips the save-all flush and builds stale content.

When data.getActivity() returns null this calls sessionManager.onQuickBuildTapped() directly, bypassing the save-all flush and passing the default wroteSomething.

That is exactly the "build silently uses stale on-disk content while the editor shows the user's edit" case the surrounding ~20 lines of comment exist to prevent, and it also feeds the session's armed-switch heuristic the wrong signal. Returning false (or flashing, as the other paths do) would be safer than building stale.

[jatezzz]

@fryanpan low — actionable copy gets truncated; fails the 2x font-scale bar.

statusText is maxLines="1", and this diff adds ellipsize="end" to it — then multi-sentence actionable copy is routed through it, e.g. quick_build_status_app_not_running ("Quick Build: built. Your app is not running - tap Quick Build to start it with your changes.") and quick_build_status_needs_full_build.

At 2x font scale on a phone this truncates well before the instruction, so the one surface QuickBuildStatusBar's KDoc says exists to name the remedy cannot show the remedy. CLAUDE.md reserves maxLines/ellipsize for text that is genuinely disposable; these strings are not.

[jatezzz]

@fryanpan low — unused imports; spotlessCheck should fail on this.

Neither Subscribe nor ThreadMode.MAIN is used — there is no @Subscribe member anywhere in this file. ktlint's standard:no-unused-imports is on by default and this file is in the Spotless ratchet, so CI should reject it. Worth re-running spotlessApply against the final state of the branch (see also the unused Position import in EditorHandlerActivity.kt).

[jatezzz]

@fryanpan low — unused import.

Position appears only on this import line; the identifier is never used in the file. Same standard:no-unused-imports / Spotless-ratchet issue as the two EventBus imports added to ProjectHandlerActivity.kt.