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

[itsaky-adfa]

MINOR: still open at head (5f92da7) - dispatched = true is still set before the dialog is shown.

Downgrading this from medium, because the scenario named here does not reproduce: EditorActivityKt declares android:configChanges="orientation|screenSize|screenLayout|smallestScreenSize|fontScale", so neither a rotation nor a font-scale change recreates the activity, and the dialog survives both.

What remains is narrower: process death, "Don't keep activities", or a config change outside that list. On those paths the coroutine has already completed normally (showing the dialog does not suspend), so finally ran with dispatched = true and nothing re-arms AwaitingInstall. Moving dispatched = true into the two decision callbacks still closes it.

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

[itsaky-adfa]

IMPORTANT: still open at head, and it fires on the primary Quick Build loop rather than only on activity recreation - raising this from medium.

Traced end to end: previousStatus is declared inside the launch{} within repeatOnLifecycle(STARTED), so it resets to null on every onStart. quickBuildTransition(null, UpToDate) returns Settled (QuickBuildTransitions.kt:150), and upToDateUpdate tests buildDurationMillis != null before previous == null, emitting Show(..., onlyIfOwned = false).

The duration persists, which is what makes it reachable: SessionReducer has no transition out of Deployed except a new build, and QuickBuildStatus.from(Deployed) carries buildDurationMillis (QuickBuildStatus.kt:155). So the resting StateFlow value after an ordinary reload still holds it.

That makes the trigger the core loop - switch to the proxy app to watch the reload, switch back - and the bar rewrites "reloaded ... in 2.3s" for a build that landed minutes ago, clobbering whatever took the line meanwhile. No test covers update(null, UpToDate(gen, duration != null)); the nearest one passes duration = 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.

[itsaky-adfa]

MINOR: still open at head - onProceed still restarts on now != NotNeeded, and apkApplicationId still funnels every runCatching failure into NeededForUnknownAppId. Confirming the grade as written: a transient parse failure on a freshly built APK tears down a live, healthy session, and only is Needed actually evidences an occupant.

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

[itsaky-adfa]

MINOR: still open at head, with a second bypass worth naming: the null-activity path also skips ensureQuickBuildClobberConfirmed, which the normal path applies further down. So it can replace whatever holds the project's applicationId with no confirmation at all - not just build stale content.

Holding it at MINOR because no current caller reaches it. The only ActionData this action sees comes from EditorHandlerActivity.createToolbarActionData(), which is ActionData.create(this) with this the activity, so getActivity() is never null on the toolbar, dropdown or overflow paths. Still worth making that explicit (?: return false) rather than leaving a branch that silently does the unsafe thing if a future call site builds its data differently.

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

[itsaky-adfa]

IMPORTANT: still open at head, and it bites at font scale 1.0, not only 2x - raising this from low.

quick_build_status_app_not_running is 92 characters. At 14sp BodyMedium on a ~360dp-wide phone, less the 16dp + 16dp padding, roughly 50-58 characters fit on one line - so the sentence naming the remedy ("tap Quick Build to start it with your changes") is cut at the default font scale, before accessibility settings enter the picture. quick_build_status_deploy_failed (65 chars) and quick_build_status_needs_full_build (59) overflow too.

maxLines="1" is pre-existing; what this PR adds is ellipsize="end" plus the long actionable copy routed through it. Dropping maxLines/ellipsize here, or raising maxLines to 2-3, would let the remedy show.

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

[itsaky-adfa]

NITPICK: the imports are still present and still unused - Subscribe and MAIN each occur exactly once in the file, on their own import lines, and the @Subscribe EventBus member is on BaseEditorActivity (onInstallationResult), not here.

One correction: CI does not reject this. .github/workflows/debug.yml:216 runs spotlessCheck inside the "Build Universal APK" job, and all three checks are green at 5f92da7. So neither the ratchet nor the pre-push hook removes these - they need deleting by hand.

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

[itsaky-adfa]

NITPICK: still open at head - Position occurs exactly once in the file, on this import line.

Worth knowing why the tooling misses it: the file contains 47 occurrences of the substring Position (tabPosition, fromPosition, ensurePositionVisible, ...), and ktlint's unused-import detection is substring-based, so the identifier reads as used. spotlessApply will not remove this one for you.

[itsaky-adfa]

Round 2 - verified at 5f92da7

Re-reviewed after the force-push. All seven findings from the 2026-08-31 round are still open. Each is answered in its own thread rather than reopened here. Two moved: the status-bar re-announce goes up to IMPORTANT (it fires on the primary loop, not only on activity recreation), and the clobber-dialog re-arm goes down to MINOR (the rotation scenario does not reproduce - EditorActivityKt declares configChanges="orientation|screenSize|screenLayout|smallestScreenSize|fontScale").

New this round: 3 IMPORTANT, 2 MINOR, 2 NITPICK, all inline.

Findings without a diff anchor

MINOR: no font-scale verification is stated, and this diff changes text surfaces. REVIEW.md section 8 requires new or changed screens to be verified at font scale 1.0 and 2.0 with the result in the PR, and is explicit that "no visual change" is a valid one-line opt-out but silence is not. This PR adds a toolbar button, a long-press dropdown and six new status-bar strings; the description covers automated tests, a manual-QA walk and benchmarks, but says nothing about font scale, and quickbuild/docs/manual-qa.md has no font/scale/TalkBack step either. That is precisely the check that would have caught the truncation finding on layout_editor_build_status.xml.

Checked and found sound

Recording these so the coverage claim is checkable and not just the failures:

• Gradle tuner - metaspace 192 -> 384 on the Low/Balanced tiers, tiered idle timeouts, five new tests including the tier-inversion guard. -Dorg.gradle.daemon.idletimeout is correctly documented as taking effect only for daemons started after the change, since idletimeout is not part of Gradle's daemon compatibility spec.
• Flag-off safety - the new slot-busy guard in AbstractCancellableRunAction sits after the cancel branch, so with experiments off a stop tap still cancels. No regression on the standard Run path.
• Leaks - QuickBuildOutputNarrator's scope is Main.immediate, so the unlocked pending/sink really are confined to one thread; the bind/unbind identity check handles new-onCreate-before-old-onDestroy; the queue is bounded at 200; unbind runs on onDestroy, so the process-wide singleton holds no activity. internalBuildObserver is scoped to the activity as LifecycleOwner.
• Threading - isAndroidResource runs off the main thread; GenerateSourcesDeferral's lock discipline, bounded refusal budget and both Koin-up/Koin-down paths hold.
• Install path - InstallationResultHandler returning null on suppress only affects doLaunchApp, its single consumer.

Three things I nearly flagged and disproved: msg_build_slot_busy does exist (base branch, strings.xml:1190); the new debug manifest's 4-space indent matches the main manifest (383 space-indented lines, 0 tabs); and "Code on the Go" in the new crash string matches app_name and 43 other uses.

Verdict

Requesting changes on the two IMPORTANT findings that reach users - the status-bar re-announce and the truncated remedy - plus the ungated dropdown and the unswept third generateSources() call site. Per CLAUDE.md's Jira rule ("a review comes back with no outstanding critical, high, or medium findings -> QA"), ADFA-4128 should stay in Code review until those clear. The MINOR and NITPICK items are not blockers.

The description issue on QuickBuildBenchAutostart.kt is worth settling before QA reads it, since it describes the benchmark methodology behind the 5x claim.

[itsaky-adfa]

IMPORTANT: the long-press dropdown runs the Quick Build action ungated, so the item labelled "Quick Build" can cancel a running build or start one that is already refused.

DefaultActionsRegistry.executeAction performs no enabled check, and the toolbar supplies its own at line 564 (onClick = { if (action.enabled) ... }). This call site has neither, and menu_quick_build.xml hardcodes android:title="@string/quick_build_action_label", so the item never reflects what prepare() computed.

Two concrete failures. While a Quick Build is running: long-press, tap "Quick Build", and execAction's first branch (currentTone() == BUILDING) calls onCancelRequested() - the build the user is waiting on is cancelled by an item that says it starts one. While a standard Gradle build holds the slot: prepare() set enabled = false and the label to "Standard build in progress", but the item still runs, saving every open buffer before failing with "Another build is running" - which is exactly what the toolbar's gate exists to avoid.

QuickBuildAction.prepare()'s KDoc asserts the label "is what the long-press dropdown and the overflow menu read"; that is not true of this menu. Reading quickBuild.label into the item and gating on quickBuild.enabled fixes both.

[itsaky-adfa]

IMPORTANT: the generateSources narrowing missed its third call site - the defect is at EditorHandlerActivity.kt:1133, outside this diff.

saveFileResult (the plugin save path, reached from EditorProviderImpl.kt:281) still does if (result.xmlSaved) { ProjectManagerImpl.getInstance().generateSources() }. Two consequences: a plugin saving AndroidManifest.xml or any non-resource XML still triggers a full Gradle build, so the save-latency win this PR advertises does not apply on that path; and with a live Quick Build session that direct call bypasses GenerateSourcesDeferral entirely, taking the single Gradle slot mid-pipeline - the exact contention the deferral exists to prevent.

The comment above it ("The same follow-ups the UI save paths run (see [saveAll] and SaveFileAction.postExec)") is now false on both counts, which is what will mislead the next reader.

The fix is one line: saveEditorInternal is shared by both paths and already populates resourceXmlSaved via accumulateSaveFlags, so line 1133 becomes if (result.resourceXmlSaved) { GenerateSourcesDeferral.notifyResourceSaved() }.

[itsaky-adfa]

IMPORTANT: the PR description documents MODE_STANDARD_E2E, which does not exist at this tip - and the code does the opposite of what the description claims.

git grep STANDARD_E2E over the head tree returns nothing. This object declares only MODE_QUICK_BUILD and MODE_STANDARD, and QuickBuildBenchActivity rejects any other value. The description names it four times: in "What to review" as a line-by-line item, as a node in the mermaid diagram, and as "MODE_STANDARD_E2E drove the standard arm through install and launch".

Meanwhile ProjectHandlerActivity.onBuildStateChanged computes suppressInstall from QuickBuildBenchHooks.standardBuildEnded(...) and skips installApk(state) for an autostarted standard build, commented "the measurement ends at the build result". So in this PR the standard arm stops at the build result and its install is suppressed - not driven through install and launch.

This matters past documentation: the headline "about a 5x median speedup" depends on where the standard arm's measurement stops. Either the harness measures install and launch externally, in which case the description should say so rather than point at this file, or the two arms are not measured like for like. Worth settling before QA works from it.

[itsaky-adfa]

MINOR: requestDowngrade is never passed true by anything, so everything it gates is unreachable.

Every occurrence on the head branch is a declaration with a false default or a pass-through: installApk -> installUsingSession -> createSessionParams, plus ApkInstallationViewModel.installApk's own unused default. ProjectHandlerActivity.doInstallApk and the Koin launchInstall in QuickBuildModule both omit it.

So the reflective setRequestDowngrade call and the MIUI "cannot request a downgrade" warning can never execute, and the same-app-id Quick Build restore this KDoc names as the reason for the parameter will still be rejected by the OS with a version-downgrade failure. Either wire the restore path to pass it, or drop the parameter - as it stands the next reader will assume downgrades are handled.

[itsaky-adfa]

MINOR: a bench re-open of a different project arms the autostart against a stale project model. Debug plus bench-flag only, so no user or release build is affected.

With project A open and a bench intent for project B: this sets ProjectManagerImpl.projectPath = B and starts the editor SINGLE_TOP. ProjectHandlerActivity.onNewIntent neither calls setIntent nor re-initializes - it claims and fires. claimAutostart() canonicalises IProjectManager.projectDirPath, now B, so the latch matches and onQuickBuildTapped() runs immediately while workspace still holds A's module model.

I verified the control flow but not the runtime outcome, so treat the consequence as likely rather than measured: a proxy-app build resolving A's module path against B's directory would make that benchmark run silently meaningless rather than fail loudly. Comparing the intent's path against the initialized project, not just the mutated projectPath, would close it.

[itsaky-adfa]

NITPICK: the PR description names the wrong field here. It says "BenchEventsFile.kt - a failed relaunch omits relaunchOk rather than recording zero", but relaunchOk is written unconditionally on this line; it is toRunningMillis on the next line that is conditionally omitted. The code and its comment are both right - only the description is off. (BenchEventsFile.kt carries no relaunch field at all.)

[itsaky-adfa]

NITPICK: the GPL header was reflowed into one run-on line by the Eclipse WTP formatter, as ratchet collateral for a one-attribute change (android:ellipsize="end"). Still valid XML and legally intact, but the header is now unreadable and it accounts for most of this file's diff. Restoring the line breaks, or wrapping the header so the formatter leaves it alone, would keep the real change visible.