Android APK is debug-key signed — OEM App Center blocks first launch, and release notes' "runtime ≥ v2.14.12" understates an EXACT version gate

[dfattal]

Two separate documentation/packaging defects, both hit by non-developer testers this week.

1. Debug-key signing blocks first launch on OEM ROMs

The Android APK is self-signed with Chromium's checked-in debug keystore (stated in the release notes: "A release keystore is not wired up yet"). On a ZTE/Nubia ROM this produces the vendor App Center refusing the app outright:

DisplayXR Browser has stopped — Can't launch "DisplayXR Browser" due to its own reason, please update the app in App Center or clear app data

A tester hit this on first launch (retrying got past it, but the dialog names neither the real cause nor a real remedy — "update in App Center" is impossible for a sideloaded preview). Ask: wire up a release keystore for the Android lane. Note the release notes already flag that a future release-signed build will not be upgrade-compatible with these debug-signed installs, so the sooner this lands the fewer testers need a manual uninstall.

2. "Requires runtime ≥ v2.14.12" is misleading — the gate is an exact match

preview-0.1.23's notes say:

⚠ Requires runtime ≥ v2.14.12

That reads as a compatibility floor — any newer runtime works. The actual check in the runtime (ipc_client_connection.c::ipc_client_check_git_tag) is strncmp on the git tag: an exact string match. A mismatched pair fails every xrCreateInstance and blacks out all inline-3D while the rest of the browser works normally:

DisplayXR client library version <A> does not match service version <B>

Two testers were sent runtime v2.14.10 with browser preview-0.1.22 and both reported black 3D; the "≥" phrasing is part of why that pairing looked acceptable.

Ask: state the exact runtime version each Android preview is built against, e.g. "Android: requires runtime v2.15.2 exactly — the runtime↔browser IPC check is an exact version match, not a minimum."

Tracking the install-instructions half in DisplayXR/displayxr-runtime#1302.

[dfattal]

Half done.

Part 2 (misleading version phrasing) — FIXED. PR #189 merged: the release-and-distribution doc now requires Android notes to name the exact paired runtime and explains why (the gate is a strncmp, so a newer runtime fails identically to an older one, and the failure hides because Android demos run in-process and never cross the IPC boundary). I also corrected the live preview-0.1.23 notes in place — they now read "Requires runtime v2.15.2 exactly" and point at install-android-bundle.sh --links, which generates a matched set from versions.json (DisplayXR/displayxr-runtime#1302, shipped).

Part 1 (release keystore) — still open, and this issue stays open for it. It needs a signing key + CI secret wired into the Android lane, which is infra work, not a code change I can land unilaterally. Two things to decide when someone picks it up:

• the release notes already warn that a future release-signed build is not upgrade-compatible with today's debug-signed installs, so every existing tester will need a manual uninstall — the longer this waits, the more people that is;
• worth confirming whether a release key actually clears the ZTE/Nubia App Center dialog, or whether that ROM objects to sideloading generally. If it's the latter, signing fixes the warning but not the block, and the install instructions need a "tap through the App Center prompt" step instead.

[dfattal]

Part 2's fix has shipped, but the reason it gives is wrong on Android — evidence below.

The release notes for preview-0.1.23 and preview-0.1.24 now both say "Requires runtime vX.Y.Z exactly — the runtime↔browser IPC check is an exact version match, not a minimum." That replaced the misleading ≥, which was the ask here.

The ≥ → exact correction was right to make. The attribution is not correct for Android.

What I measured

Unpacked both APKs from the tablet bundle and searched every lib/arm64-v8a/*.so:

	version-gate string (does not match service version)	runtime git tag
runtime APK — libopenxr_displayxr.so	present	v2.16.2
runtime APK — libdisplayxr-diag.so	present	v2.16.2
browser APK — all native libs, incl. libchrome.so (228 MB)	absent	absent

The browser APK embeds no DisplayXR client, no gate, and no runtime version string. It ships libopenxr_loader.so and loads libopenxr_displayxr.so from the installed runtime APK.

Why that matters

ipc_client_connection.c:951's strncmp gate is client ↔ service. On Android both halves ship inside the same runtime APK, so their tags always agree. A browser/runtime version pairing therefore cannot trip that gate on Android.

It still bites — but on a mismatched runtime install (a dev-build runtime, or a stale client left behind), which is a different failure with a different remedy. That matches the note in this issue that installing a dev-build runtime APK breaks the browser.

The browser's real coupling to the runtime is the OpenXR extension wire protocol (SPEC_VERSIONs) — a floor, not an exact match. Same axis as consumer_floors in downstream-pins.json.

Caveat, stated plainly: this is an Android-only finding. On Windows the browser bundles DisplayXRClient.dll, so the exact client↔service gate genuinely does apply there, and the notes' wording is correct for that platform.

Suggested wording

Keep the matched-pair instruction; fix the justification, and scope it:

Tested against runtime vX.Y.Z. Install that pair — other combinations are untested rather than known-broken. (Windows: the browser bundles its own DisplayXR client, so the runtime↔client version check is an exact git-tag match. On Android the client ships inside the runtime APK, so that check cannot mismatch; the coupling there is the extension SPEC_VERSIONs.)

I have applied this corrected wording to the tablet bundle's MANIFEST.md — including reverting a claim I had written into it an hour earlier asserting the exact-match mechanism, before I checked it.

I have not edited the published release notes: that is a call about what testers are told, and the requirement itself may still be right for reasons other than the mechanism cited.

[dfattal]

Follow-up: the mechanism is now traced positively, not just inferred from absent strings.

My previous comment argued from absence — the browser APK contains no client, no gate, no version. Absence is weak evidence on its own, so I traced the actual load path in both directions.

Browser side — lib/arm64-v8a/libopenxr_loader.so performs Android broker discovery:

org.khronos.openxr.runtime_broker
org.khronos.openxr.system_runtime_broker
getActiveRuntimeCursor: Querying URI: %s

Runtime side — the runtime APK's AndroidManifest.xml (AXML string pool) declares the broker and names the client library it hands out:

org.freedesktop.monado.openxr_runtime.OpenXRRuntimeBroker
libopenxr_displayxr.so
org.freedesktop.monado.ipc.SlotBrokerService

So the chain is: browser → OpenXR loader → broker query → libopenxr_displayxr.so supplied by the installed runtime APK. That is the same binary carrying the strncmp gate and the v2.16.2 tag, and the service is its sibling in the same APK.

Both operands of the version check therefore come from one APK on Android. The gate is real and does fire — on a mismatched runtime install (dev-build runtime, or a stale client) — but it cannot be tripped by pairing browser vX with runtime vY.

This also explains the known dev-build hazard correctly: it is not "the browser's client disagrees with the runtime", it is "you replaced one half of the runtime APK's pair".

Unchanged from before: Android-only. Windows bundles DisplayXRClient.dll with the browser, so the exact gate genuinely applies there.

[dfattal]

Part 1 (release keystore) is now wired. Infrastructure side is done; the next preview publishes release-signed.

What was done

• Generated a browser-specific release key — deliberately not the shared gauss-release.jks that signs the five demo repos. The browser is the highest-profile artifact, so the blast radius is kept separate. RSA 4096, PKCS12, alias browser, CN=DisplayXR Browser, O=DisplayXR, C=US, 10000-day validity.
• Backed up alongside the existing demo key in the same iCloud keystore folder (so it inherits the existing backup regime), with a README naming its consumers and the fact that losing it means no signed updates ever.
• Secrets set on displayxr-browser-pvt: ANDROID_KEYSTORE_B64, ANDROID_KEYSTORE_PASSWORD, ANDROID_KEY_ALIAS. These are the exact names publish-browser-releases.yml already consumed — the lane was written to skip signing with a warning while the key did not exist, so nothing else had to change.

Verified, not assumed

Ran the exact CI path (zipalign → apksigner sign → apksigner verify) against the shipped 0.1.24 APK on a copy:

	Signer #1 certificate DN
before	CN=Unknown, OU=Unknown, O=Unknown, … — Chromium's checked-in debug key, precisely as this issue reports
after	CN=DisplayXR Browser, O=DisplayXR, C=US

Release-key SHA-256 fingerprint (public identifier, safe to quote when confirming a build's provenance):

d5:21:53:79:3c:7a:40:3f:3c:d7:33:03:2e:d4:33:14:f2:6a:77:48:f6:d5:c0:a2:b5:e1:28:47:ff:0d:f5:b2

Follow-up shipped with it

The workflow warned when the APK was unsigned but said nothing for the signed case — the direction that actually breaks a tester. Android identifies an app by its signing key, so an install that changes the key is refused with a bare "App not installed" and no hint at the cause. Release notes for signed builds now say: uninstall any preview up to and including 0.1.24 first. Naming the cutover version keeps that true rather than stale once the transition is over. (pvt PR #9, merged.)

Still open on this issue

Nothing on the packaging side. What remains is a judgement call, not work: the first release-signed preview forces every existing tester to uninstall and reinstall once. Worth timing that deliberately rather than letting it land as a surprise mid-week.

[dfattal]

Part 1 is not closed: a tester hit the same dialog on release-signed 0.1.31

The keystore work landed and is good, but it did not fix this. A tester sideloaded
preview-0.1.31 (release-signed since 0.1.25) by tapping the APK in the Files app,
launched it from the home screen, and got the same dialog on first launch:

DisplayXR Browser has stopped — Can't launch "DisplayXR Browser" due to its own reason,
please update the app in App Center or clear app data

Tapping the icon again launched it. So whatever the ROM keys on, it is not the Chromium
debug key. This comment is the static half of the root-cause: what I could establish
without the tablet (it is in use), which hypotheses that kills, the read-only commands that
will settle the rest, and the one line any tester can send us with no repro at all.

---

Measured (static, from the APKs on disk)

aapt2 + apksigner from build-tools 34, with --min-sdk-version 21 forced so v1/v2 are
actually checked rather than skipped. Every APK in the current tablet bundle, plus three
third-party apps that install and run on these tablets normally, as a control.

	browser 0.1.31	our demos ×5	our runtime	control app A	control app B	control app C
package id	org.chromium.chrome	com.displayxr.*	org.freedesktop.monado.…	com.leiainc.leiachat	com.leialoft.leiaplayer	com.leia.holopix
min / target / compile SDK	29 / 36 / 37 (preview codename)	29 / 31 / 35	29 / 31 / 35	30 / 34 / 34	30 / 33 / 33	30 / 33 / 33
v1 (JAR) signature	yes	no	no	no	yes	no
v2 / v3	yes / yes	yes / no	yes / no	yes / no	yes / no	yes / no
signer	CN=DisplayXR Browser RSA 4096	shared release key, RSA 2048	same as demos	per-app	per-app	per-app
extractNativeLibs	false — 237 MB uncompressed libchrome.so, APK 343 MB	true	true	true	true	true
launcher entry	<activity-alias> com.google.android.apps.chrome.Main → ChromeTabbedActivity	plain <activity>	plain	plain	plain	plain
testOnly / debuggable / installLocation	absent	absent	absent	absent	absent	absent

The device is Android 13 = API 33.

What that kills

• The debug key. 0.1.28, 0.1.30 and 0.1.31 are all signed CN=DisplayXR Browser, O=DisplayXR, C=US, SHA-256 d5:21:53:79:3c:7a:…, RSA 4096, v1+v2+v3. No CN=Unknown anywhere. Part 1's
  premise no longer holds.
• "We ship no v1/JAR signature." Backwards. The failing APK has one; two of the three
  known-good control apps have none, and so do our runtime and all five demos, which install
  by tapping without trouble. If v1 presence were the discriminator, the failing set would be the
  opposite of what is observed.
• testOnly / debuggable / installLocation. Absent from every APK measured, ours and
  the controls alike. None of them is the lever.

The three things that make the browser unique among our artifacts

None is proven. They are simply the only measured properties that separate the one APK that
failed from everything that works on the same device.

1. Package id org.chromium.chrome. Every other DisplayXR APK uses an id no app store has
   ever heard of. org.chromium.chrome is a well-known id. A store-side record for a known
   package is the most natural way to arrive at exactly the remedy the dialog offers — "update
   the app in App Center" — which is meaningless for an unknown sideloaded id but is the
   standard text for "the store knows this app and your copy is not the one it expects".

2. targetSdk 36 / compileSdk 37 (an unreleased preview platform) on an API-33 device. The
   browser is the only APK here that targets more than one level above the platform. Stated with
   its counter-evidence: control app A targets 34, also above 33, and works — so a bare
   "targetSdk > platform" rule is already disproved; only a higher threshold survives.

3. It is the only APK on the device with a v3 signing block — and its v1 block is there by
   accident. Everything else measured, ours and the controls, is v2-only or v1+v2. The cause is
   in our lane: publish-browser-releases.yml calls apksigner sign with no --min-sdk-version
   and no --vN-signing-enabled flags, so apksigner picks its own defaults and emits v1+v2+v3;
   the runtime and demos sign through AGP at minSdk 29, which yields v2 only. A v1+v2+v3 APK is
   perfectly legal, but it is a shape nothing else on this device has, and an OEM store-integrity
   check that computes a certificate digest can read a v1 cert and a v3 cert as two different
   identities. This is the cheapest hypothesis to eliminate: one flag, no behaviour change.

Weaker, but worth keeping on the list: the browser is the only 343 MB APK, the only one with
extractNativeLibs=false (a 237 MB uncompressed .so mapped at first launch), and the only one
whose home-screen icon resolves through an <activity-alias>. All three make its cold first
launch materially heavier than anything else on the device.

---

The claim this issue currently rests on needs a check

INSTALL.md §3c and our bundle notes now say flatly that this is "the OEM App Center sideload
guard … not a crash". That has not been measured. The dialog's title —
"DisplayXR Browser has stopped" — is the platform's own crash/ANR phrasing family, and OEMs
routinely reword the body while keeping it. A heavy cold start that trips a launch watchdog
produces exactly this shape: fails once, succeeds on the warm second tap.

Three mechanisms are live, and they land on different desks:

	mechanism	owner of the fix
M1	an OEM policy guard at launch (package id / installer attribution / signer allow-list / target SDK)	us (packaging) or a new OEM platform ask
M2	an OEM launch watchdog tripped by our cold start	us (startup cost)
M3	a genuine first-launch crash, rendered in OEM wording	us (the bug)

Telling them apart — read-only, and M2/M3 need no repro at all

Android keeps the record for days. On any tablet that has seen the dialog:

adb shell dumpsys activity exit-info org.chromium.chrome   # reason=CRASH / ANR / … per recent death
adb shell dumpsys dropbox --print | head -300              # data_app_crash / data_app_anr, with stacks

• an entry at the dialog's timestamp → M2/M3, ours, and the stack names the bug
• no entry, the process never died → M1, a policy guard

Then, for M1, find who owns the string. All read-only — pulling a system APK is a read:

adb shell pm list packages -f | grep -iE 'appcenter|appstore|market|verifier|packageinstaller|securitycenter|optimiz'
adb shell cmd overlay list                    # an OEM string override often lives in an RRO
adb pull /system/framework/framework-res.apk /tmp/fw.apk
aapt2 dump strings /tmp/fw.apk | grep -inE 'has stopped|App Center|own reason|clear app data'
# repeat pull + dump strings for each candidate package
adb shell ls -l /system/etc/ | grep -iE 'app|launch|control'   # this ROM keeps world-readable policy XML here

If the string lives in framework-res (or an RRO over it), the dialog is the platform's crash
dialog reworded and M1 is dead. If it lives in an OEM application, that package is the guard.
And while the dialog is on screen, adb shell dumpsys window windows names its owning package
outright.

One line to ask every tester for, with no repro

adb shell pm list packages -i | grep chromium

It prints installer=…. Every package installed by adb on our pads reports an empty
installer; a tap-install through a file manager carries a real one. That settles the attribution
hypothesis without anybody reproducing anything.

---

A first-launch-only code path we have never exercised: the Chromium FRE

Nothing in the 130-patch series suppresses Chromium's First Run Experience on Android.
branding/initial_preferences does set skip_first_run_ui — but scripts/package.sh only
copies it next to chrome.exe, so it is Windows-only and an APK never consults it. No patch
sets --no-first-run / kNoFirstRun for Android either.

So on a tester's device the stock FRE runs on first launch and never again. On our pads the
browser is driven with a /data/local/tmp/chrome-command-line file that has historically carried
--disable-fre. If that file is still there, our proofs have literally never run the code path
that only a tester runs, which would be a complete explanation for "green on the pad, dialog for
the tester" independent of any OEM policy. One read-only command settles it:

adb shell cat /data/local/tmp/chrome-command-line

This is evidence for the question, not for the answer — the FRE showing is not itself a failure.
But it is the one first-launch-only path in our own code, and it should be ruled in or out before
we conclude the ROM is at fault.

Why our gates never see it, and how to make them

Our proofs install with adb install -r -d -g and launch with
monkey -p <pkg> -c android.intent.category.LAUNCHER 1. Two things differ from what a tester does:

1. attribution — fixable: adb install -r -d -g -i com.android.packageinstaller <apk>,
   or on-device pm install -i com.android.packageinstaller -r -d -g <path>;
2. who starts the activity — monkey and am start both build the correct MAIN/LAUNCHER
   intent, but send it from the shell uid. If the guard lives in the OEM launcher, no adb
   form can reproduce it. The faithful exercise is a real tap, and that is still scriptable:

adb shell am start -a android.intent.action.MAIN -c android.intent.category.LAUNCHER \
    -n org.chromium.chrome/com.google.android.apps.chrome.Main    # explicit component, still shell uid
#   (that alias IS the exported LAUNCHER entry; ChromeTabbedActivity is only its target and is
#    not exported, so `am start -n .../ChromeTabbedActivity` is not the tester's path)
# …and, for a launcher-initiated start:
adb shell input keyevent KEYCODE_HOME
adb shell screencap -p /sdcard/home.png && adb pull /sdcard/home.png   # locate the icon
adb shell input tap <X> <Y>

Whichever of these reproduces the dialog is the finding. If none of them does, that is also a
finding: it means the guard is launcher-side, no scripted gate can ever cover it, and the ask
changes from "fix the harness" to "a human taps the icon once before a bundle ships".

A cheap way to isolate the discriminator without a 45-minute Chromium build

Four ~10 KB canary APKs, each installed by tapping in the file manager and launched from the
home screen:

canary	package id	targetSdk	signer	size
A	com.displayxr.canary	33	browser release key	tiny
B	com.displayxr.canary	36	browser release key	tiny
C	org.chromium.canarytest	33	browser release key	tiny
D	com.displayxr.canary	33	browser release key	padded to ~340 MB

A↔B isolates target SDK, A↔C the package-id/store-record theory, A↔D cold-start weight. Minutes
each, no Chromium tree, and it answers the question a Chromium rebuild would only confirm.

---

Our-side fixes, ranked by evidence × cost

• Normalise the signing shape — do this regardless. Add --min-sdk-version 29 (and, if we
  want it explicit, --v1-signing-enabled false) to the apksigner sign call in
  publish-browser-releases.yml. It makes the browser's signature shape identical to the runtime
  and demos, which install and launch by tap without trouble, and it removes an accidental
  difference nobody chose. One line, no behaviour change, and it either fixes this or eliminates
  a hypothesis — both are worth having.

• If M1 keys on the package id → move the Android app id off org.chromium.chrome (e.g.
  com.displayxr.browser). A real build change, and it forces every existing tester to uninstall
  once — the second forced uninstall after the 0.1.25 key change, so it wants deliberate timing,
  not a mid-week surprise. Independent benefit: our build stops colliding with any other
  org.chromium.chrome install on a device.

• If M1 keys on target SDK → set default_target_sdk_version in scripts/args.android.gn
  (which today sets no SDK at all and inherits Chromium's default). One line, cheap to test — but
  it changes real Chromium behaviour (edge-to-edge enforcement, foreground-service types,
  predictive back), so it needs its own soak rather than a drive-by.

• If M1 keys on installer attribution or a signer allow-list → nothing we ship can fix it, and
  it becomes a new platform ask in the runtime's
  docs/specs/vendor/oem-android-platform-requirements.md,
  proposed as S10 (STRONGLY RECOMMENDED, PLATFORM):

  A correctly-signed application installed from local storage must launch without a
  store-mediated gate. If the platform does refuse a launch, the dialog must name the actual
  reason and offer a remedy the user can perform — "update it in the app store" is not
  actionable for an application the store does not carry.

  It is the same shape as the existing S9 ask (a remotely-updatable OEM allow-list we are not
  on, with "please don't add us" as the practical remedy), and it should sit beside it.

• If M2/M3 → an ordinary bug in our cold-start path, and exit-info names it.

Blast radius

INSTALL.md §3c says the demos can show the same dialog. That is precautionary wording, not an
observation — nobody has seen it on a demo. If the mechanism turns out to be the package id or
the target SDK, the demos and the runtime are not exposed (com.displayxr.* /
org.freedesktop.monado.*, targetSdk 31). If it is installer attribution or a signer allow-list,
every APK in the bundle is exposed equally, and the tap-to-install route is the one that needs the
warning — which means it belongs not only in the bundle's INSTALL.md but in the runtime's
install-android-bundle.sh --links output, since that is the generated list a non-developer
tester actually taps.

Workaround wording (it does work; keep it)

First launch may show "DisplayXR Browser has stopped — Can't launch … please update the app in
App Center or clear app data." Tap the icon again — it launches. If it repeats: Settings →
Apps → DisplayXR Browser → Storage → Clear data, then launch. If it still refuses, uninstall
and reinstall from the zip: a browser from before 2026-09-06 was signed with a different key, and
a current build cannot install over it.

Unverified, stated plainly

• Which package emits the dialog. Not determined — nothing public documents this string.
• Whether it is a policy guard at all, versus a reworded crash/ANR dialog. exit-info settles it.
• Whether the demos are genuinely affected.
• Whether the tester had a pre-0.1.25 debug-signed browser installed at the time. If he did, the
  install should have been refused outright — worth asking what he saw at install time, because
  it changes the story.

[dfattal]

Follow-up: the no-regret half of the above is now a PR — displayxr-browser-pvt #88.

It pins the release-signing scheme to v2-only (--min-sdk-version 29 plus all three --vN-signing-enabled flags stated explicitly) so the browser stops being the only v1+v2+v3-signed APK on the device, and asserts the resulting shape from apksigner verify --verbose so it cannot drift back. Verified end-to-end with build-tools 34 against a real APK: v1 false, v2 true, v3 false, zero META-INF/*.SF|.RSA. Same key, same certificate — no forced uninstall; it upgrades in place over 0.1.25+ as before.

On the next preview this either fixes the dialog or eliminates hypothesis 3. It is deliberately not the package-id rename or the target-SDK change — those are behavioural and need a decision, not a drive-by.

The PR also corrects three build-lane comments (scripts/args.android.gn, scripts/build.sh, scripts/aws/do_build.sh) that still said release signing was "deferred" — one of them printed NOTE: debug-key self-signed (no release keystore yet) into every Android build log, months after it stopped being true.

[dfattal]

Measured on our reference pad (NP02J, 2026-09-09 01:30Z, read-only): /data/local/tmp/chrome-command-line = chrome --disable-fre. So every browser check we have ever run on our pads suppressed Chromium's first-run experience; testers have no such file, so the FRE path has never been exercised by our harness — the gap is now measured, not assumed. Also on our pad: pm list packages -i → org.chromium.chrome installer=null (adb attribution); dumpsys activity exit-info org.chromium.chrome shows only routine reason=13 subreason=17 (ISOLATED NOT NEEDED) sandboxed-child exits, no main-process death — consistent with the dialog never having appeared here.

Next repro attempts (bundle harness, once the pad is free): install 0.1.31 with pm install -i com.android.packageinstaller, launch via org.chromium.chrome/com.google.android.apps.chrome.Main, and if neither reproduces, input tap on the home icon — each with chrome-command-line removed so the FRE path is live. The FRE variable is now the leading candidate over installer attribution. Signing hypothesis (v1+v2+v3) is being eliminated by browser-pvt#88 on the next preview. Tester-side discriminators unchanged: dumpsys activity exit-info org.chromium.chrome, dumpsys dropbox --print, pm list packages -i | grep chromium.

[dfattal]

Negative reproduction on our reference pad (NP02J, 2026-09-09 ~02:30Z, browser 0.1.31 bundle build, sha-verified), all three suspects varied at once: installer attribution set like a tap-install (adb install -i com.android.packageinstaller → pm list packages -i reads installer=com.android.packageinstaller), /data/local/tmp/chrome-command-line REMOVED so the first-run flow was live, and a TRUE first launch by input tap on the home-screen icon (never started from a shell first; also tried am start -n org.chromium.chrome/com.google.android.apps.chrome.Main on a fresh install). Result both times: normal launch, no dialog (uiautomator: zero matches for "has stopped" / "App Center"), pid alive, dumpsys activity exit-info org.chromium.chrome = zero main-process entries, no FATAL/ANR in logcat. Dropbox over the whole buffer: zero entries for org.chromium.chrome ever on this pad (the crash/ANR entries present belong to modelviewer/mediaplayer/gauss from earlier test sessions).

So on identical hardware and the same APK, neither installer attribution, the FRE path, nor a launcher-uid launch reproduces the dialog. Remaining weight is on what differs on the tester's device: the upgrade path (a pre-2026-09-06 debug-signed browser that 0.1.31 could not install over, leaving the old build in place), whatever the install actually did, and device state. The tester's exit-info / dropbox / pm list packages -i output is the decisive evidence and has been requested. browser-pvt#88 (v2-only signing) lands on the next preview regardless.