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

[fryanpan]

ADFA-4128

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<br/>autostarts the standard Run and<br/>stops at the build result<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 to 384 MB and daemon idle timeouts, Experiments flag on only.

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

• android.proto, AndroidProjectExts.kt, AndroidModule.kt — the selected variant's res dirs (src/debug/res, src/<flavor>/res) count as resources: a new variantSourceProviders field on the variant model, filled by the tooling serializer. An upgraded install needs one project sync before the field is populated.

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

• Release APK: the Quick Build daemon zip (62.0 MB) and runtime AAR (0.1 MB) are staged into every variant's assets, stored uncompressed, so the release APK grows by 62.1 MB. Not gated to debug because FeatureFlags.isExperimentsEnabled is a runtime preference available in release; once the flag graduates the payload is the feature's cost, until the work to merge the Quick Build tools with the ones CoGo already ships is done.

• resources/src/main/res/values/styles.xml — MaterialDialog.Insets cuts the Material alert dialog's vertical insets to 24dp, so a tall dialog stops clipping its buttons against the navigation bar. 39 of 57 alert dialogs inherit this theme; it lands app-wide, checked on five inherited dialogs at font scale 1.0 and 2.0 (see How this PR Was Tested).

• Dialogs and the toolbar dropdown are Views, not composables, because they live in the existing View-based editor toolbar ADR 0009 keeps as-is, and the Help item routes into the 3-tier help that has no Compose entry point until ADFA-4381.

• QuickBuildBenchAutostart.kt — MODE_STANDARD autostarts the standard Run and stops at the build result, so it measures the build only. Line-by-line.

• The standard arm's install dialog is suppressed, because an unattended run cannot answer it. Quick Build's arm measures build, deploy and reload, so the two are not like for like from in-app numbers alone.

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

• BenchQuickBuildMetricsSink.kt — relaunchOk is recorded only when a relaunch was attempted, and toRunningMillis only on a relaunch that reconnected, so a skipped relaunch is absent rather than a measured failure or zero.

How this PR Was Tested

Head 7715c40548, which is also the stack tip. All six modules' JaCoCo reports were regenerated here on 2026-09-25 and each was checked against the run's start timestamp: 6 fresh, 0 stale, 0 absent. The three modules this PR touches are below.

Restacked onto stage c263653bcf on 2026-09-24; head now 7715c40548, which is also the stack tip. Re-verified at that tip on 2026-09-25, after the restack pulled roughly 6,970 lines of stage work under the stack: spotlessCheck green (34 of 34 tasks executed, --rerun-tasks) and :app:assembleV8Debug green (254.1 MB APK). The A56 walk ran on 2026-09-24/25 at f6ef914653, that tip plus ADFA-4931's 12 commits: 25 of 25 cases, 24 pass, 0 fail, 1 blocked (T19, Compose — no project on the device configures offline, so Quick Build is never reached). The base is origin/stage's current head, so there is no stage drift. All six unit suites were run here on 2026-09-25: :quickbuild:core 1,234, :quickbuild:daemon 234, :quickbuild:protocol 22, :quickbuild:runtime 307, :gradle-plugin 155 and :app 1,312 — 3,264 tests, 1 failure and 5 skips (see below; the other four skips are :gradle-plugin's documented @Disabled cases).

Module	Tests	Line	Branch
:app	1,312 (1 failed, 1 skipped)	78.0 %	75.6 %
:quickbuild:runtime	307 (0 failed)	93.5 %	95.0 %
:quickbuild:core	1,234 (0 failed)	96.7 %	91.6 %

:app's percentages are changed lines in non-UI files, the basis REVIEW.md section 5 names: 1338 of 1715 changed lines and 761 of 1007 changed branches, with Activities, Fragments and Composables excluded. That slice covers 56 of this PR's 61 source files; the exclusion removed 12 of the diff's 159 files, 7 of them source. :subprojects:projects and :subprojects:tooling-api-impl have no coverage task and were not run in this pass [unmeasured at this head].

The :app skip is MemoryUsageWatcherLivenessTest :: the default check really reads proc, which self-skips on a macOS host and runs on Linux CI.

The :app failure is QuickBuildActionSaveOrderTest :: the sample happens exactly once and strictly before the save, reported as UncaughtExceptionsBeforeTest — an exception escaped an earlier test in the same JVM fork and landed on whichever test started next. Suppressed cause: Dispatchers.Main was accessed when the platform dispatcher was absent and the test dispatcher was unset, so production code reached Dispatchers.Main asynchronously after the test that started it had finished. The victim rotates: across six runs it has been GitBottomSheetViewModelTest, TemplateManagerViewModelTest twice, and now this one, which is one of this stack's own tests. The same failure mode reproduces on origin/stage with none of the stack applied, so the leak is pre-existing rather than introduced here. Which production launch site leaks is unmeasured. It is not an unbalanced setMain/resetMain in the app tests: over all of app/src/test, 2 files call setMain and both call resetMain.

The failure aborts the build, so the coverage report came from a second Gradle invocation that skips the failing task and reuses the first run's exec data.

The 2026-09-24 restack pulled about 6,970 lines of stage work under the stack. The manual-QA walk below was re-run after it; the other device readings were not, and each names the head it was green at. The three commits they cite have been re-pointed to their equivalents on this branch.

• Manual QA — walked the manual-qa.md test plan on the A56, all 25 cases, at font scale 1.0 and 2.0: 24 pass, 0 fail, 1 blocked [measured on a56 2026-09-24/25 at f6ef914653, the stack tip plus ADFA-4931's 12 commits]. The block is T19 (Compose), denominator 3 of 3: every Compose project on the device fails to configure offline on ADFA-5727, so Quick Build is never reached and the case has no verdict on the product. Two defects were seen alongside criteria that passed, both written up in the walk: the status bolt renders the ERROR tone while the status bar reads Quick Build: built - tap to start app (T7), and T3's failure wording deviates from the plan's text. The earlier walk at f75df5a573 on 2026-09-17/18/19 read the same 24 pass and the same one block

• Dialog insets, device-verified on the A56 at font scale 1.0 and 2.0 [measured on a56 2026-09-22, before the 2026-09-24 restack - 8 dialogs at 1.0 and 2.0, 0 status-bar or navigation-bar intrusions]. At 2.0 the won't-stay-up dialog's two buttons both render 140px tall against 148px of navigation-bar clearance (ratio 1.00); before the fix the second button was 73px against the first's 140px (ratio 0.52). Screenshots read by eye at both scales; the build under test was proven byte-identical to the installed APK by md5.

• Font scale [measured on a56, pre-restack]: every Quick Build surface was walked at 1.0 and 2.0 on the A56 on a build whose layouts match e7fda817bd: the collapsed status header with all 15 status strings (the deploy-failed text re-measured at both scales after its 2026-09-14 rewording: one line at 1.0, two complete lines at 2.0), the toolbar button, the long-press dropdown, Build Output, the Help tooltip, and every Quick Build dialog and flash that could be provoked (not reached: the unknown-app confirm, three reinstall flashes, the live-reload-crashed flash). All read in full at both scales after 0058277ed7 relabelled the dropdown's disabled row "Building…"; its old label was cut at 2.0. Two 2x issues remain by decision: the floating feedback button can cover the first letter of a wrapped status line (ADFA-5736), and the header's swipe hint, pinned to one line by this PR (layout_editor_build_status.xml:44) so the collapsed header keeps a stable height, is cut. Screenshots at both scales are attached to ADFA-4128.

• Inherited dialogs [measured on a56 2026-09-22, before the 2026-09-24 restack, including Close project's cut labels]. The dialog inset change reaches every DialogUtils dialog. Checked on the A56 at 1.0 and 2.0 on Send feedback, Close project, Git user name, Terminal log level and the plugin external-link prompt: full text and buttons, clear of both system bars, except Close project's two long button labels, which Material's single-line dialog buttons cut at 2.0.

• StrictMode [measured on a56, both sessions before the 2026-09-24 restack]: a 97-minute session covering project open, Quick Build loops, a standard Run and both font scales logged 552 violations, 1 with a Quick Build frame: the first tooltip shown triggers TooltipManager's one-time main-thread read of the docs DB timestamp (ToolTipManager.kt:52, unchanged by this stack; filed as ADFA-5737). None from the graph warm-up. A shorter re-run on 2026-09-22 read 96 violations over 37,750 logcat lines at font scale 1.0 and 97 over 39,667 at 2.0 — the same single Quick Build frame, the same cause, no new source. The counts differ because the two sessions differ in length and coverage, not in what they found.

• LeakCanary [measured on a56 2026-09-22, before the 2026-09-24 restack, where the ApkInstallationViewModel leak did not recur and the NsdManager one did], 3 analyses over the same session: no leak through a Quick Build class. Two older leaks: shizuku's NsdManager holds a destroyed editor (existing ADFA-3418), and ApkInstallationViewModel kept its install callback registered after a finished install, fixed in this PR at 89a3a9a4f1.

• Benchmark [measured on real devices, 2026-09-05 to 09-07, pre-restack] — both arms: with Quick Build the edit loop is 4-6x faster than the same app's standard build-and-deploy loop on the same device. The Quick Build arm ran the initial experimental release.

  How the two arms were made comparable, since they are not like for like from in-app numbers: the in-app standard arm (MODE_STANDARD) suppresses the install dialog and stops at the build result, so it measures the build only. The benchmark harness adds install and launch from outside the process — it drives the install dialog and takes the span from the save to the app's Displayed on the device clock — and the published basis subtracts the harness's own time from that span. Quick Build's arm measures build, deploy and reload in-app. There is no MODE_STANDARD_E2E; earlier drafts of this description named one that was never in the tree.

• Still open — the API 28/29 resource-swap success path is not device-verified; no phone we have runs those API levels. The rebaseline relaunch path is device-verified on the A56 (see ADFA-4128 (8/11): quickbuild:core — session orchestration #1720).

Review fixes (2026-08-22)

A review-fixes commit addresses the code-review findings. One change here ships to all users with the Experiments flag off; the other runs only with the flag on:

• 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 while the Experiments flag is on (with it off, builds use the defaults, as before): (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. A manifest save still runs it.

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_01XkGof8cLt23LkxZ8MKzin2

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