MTK-patch asg_client install failing in the field — units stranded on asg-client 37 with MTK 20260626

[aisraelov]

Problem

The MTK OTA patch (MentraLive_20260525 → 20260626, deployed via PR #3275) that force-installs asg-client 39 — our recovery path for users stuck on asg-client 37 — is itself failing for some users. The MTK firmware applies, but the bundled APK install silently doesn't happen.

Known instances (3 as of Jul 7)

1. Philippe, internal repro, Jul 1 — installed 05_25→06_26 on a v37 unit; asg stayed 37 (Slack). Clean-path retest (36→37→MTK→39) worked. His 37 was the release APK from GitHub, which weakens the signature-mismatch theory. Also observed: flashing the MTK uninstalled com.mentra.recovery.
2. Discord field report, Jul 3 (Slack thread) — that unit apparently on asg 38 from the ~30-min publication window.
3. Zac @ Skillmaker, Jul 7 — firmware.appVersion still 37.0 after the update; checkForOtaUpdate returns "up to date"; camera warmUp times out (Slack). Philippe confirmed: "The BES/MTK updated but the asg client did not."

"We have had 3 instances of people failing to update the asg client using the mtk patch." — Philippe, Jul 7

No glasses-side logs have been captured from any failing unit yet.

What we know about the installer

Only ApkInstall.java received from Liu (Slack). It runs inside SystemUI post-OTA and does a plain PackageInstaller MODE_FULL_INSTALL:

• One-shot: session.commit() result goes to InstallResultReceiver (not shared with us). No retry on failure.
• No visible pre-checks: the if (installed < new) install version gate Nicolo described lives elsewhere in the MTK code — never shared. No signature check visible.
• getApkName() returns null on a corrupt/unreadable APK and install() proceeds without a null check.
• If the commit fails (signature mismatch, insufficient space, reboot mid-commit), nothing retries — and the MTK version has already advanced → exactly the observed stranded state.

Hypotheses (none confirmed)

• Debug-vs-release signature mismatch (Nicolo) — weakened by Philippe's release-APK repro.
  • Highly unlikely- the team generally builds w/ release keys.
• com.mentra.recovery interference — Nicolo says no; but MTK flash does uninstall it.
• asg-38 cohort (users who caught the ~30-min ASG 38 publication) — only explains the Discord case, not the 37-based failures.

Work items

• Get the full MTK installer code from Liu — especially InstallResultReceiver and the version-gate logic (only ApkInstall.java received so far).
• Capture logcat from a failing unit (_liuxinyun_ tag + PackageInstaller output). Zac's unit is a live specimen.
• Root-cause the failed install.
• Ship an un-strand path: next-hop MTK patch from 20260626 that re-attempts the APK install, and/or manifest targeting for the stranded cohort (MTK 20260626 + asg 37).
• Harden the installer: retry on failure, log/report the commit result, never advance-and-forget.

Context timeline

• Jun 9 — v37 APK OTA path broken (corrupted-OTA-cache suspect); fleet parked on 37 (Slack).
• Jun 26 — MTK bypass shipped: mtk_ota_update_20260525_20260626.zip, v39 APK baked into the MTK image (Slack).
• Jun 29–30 — verified working internally; rollout plan agreed (Slack); deployed via PR Mtk patch ota release #3275.
• Jul 3 — Fix Mentra Live OTA Update path created by the latest MTK deployment #3322 delivered 5 direct patches from older MTK bases to 20260626 (PR Route all MTK firmware to 20260626 and bump BES to 17.26.07.03 in V1 manifest (OS-1644) #3339) — those patches presumably share this installer and this failure mode.
• Jul 7 — Philippe/Nicolo sync on the 3 failures; commitment to Skillmaker: "new update out this week."

Related: #3322, PR #3243, PR #3275, PR #3339.