fix(clipboard): coordinate copy verifiably reaches the system clipboard (#92)

[jfuginay]

Closes #92.

Repro evidence (first — house rule: end-to-end reproducer before any fix)

Verdict: could NOT reproduce the failure. The original write path (LocalClipboardManager.setText(AnnotatedString), Compose BOM 2024.12.01 / ui 1.7.6 — LocalClipboardManager is not deprecated until 1.8, and the 1.7.6 bytecode confirms setText → setPrimaryClip(ClipData.newPlainText(...))) lands a pasteable clip everywhere I could test, including the reporter's exact press-and-HOLD gesture.

Oracle 1 — instrumented tests (system-clipboard read-back via platform ClipboardManager)

Exercise the exact MapScreen path: composition-resolved manager, write from a clickable's onClick, including a 900 ms hold (past the long-press timeout) before release. Assert against the platform clipboard (text/plain MIME + exact item text + coerceToText), with a pre-seeded sentinel so a stale clipboard can't fake a pass.

Starting 2 tests on engie_emulator(AVD) - 16          # stock Android 16 / API 36
  composeManagerWrite_landsAsPlainTextInSystemClipboard  PASSED (2.38s)
  heldClickRelease_runsCopyBranch_andClipLands           PASSED (4.65s)

Starting 2 tests on SM-X210 - 16                      # Samsung One UI (Galaxy Tab A9+), real OEM clipboard manager
  composeManagerWrite_landsAsPlainTextInSystemClipboard  PASSED (2.21s)
  heldClickRelease_runsCopyBranch_andClipLands           PASSED (2.38s)

Oracle 2 — real app, real gesture, real third-party paste (adb drive on engie_emulator)

input swipe 540 900 540 900 700        # long-press map → radial opens
uiautomator: "Copy Coords" → [509,1105][572,1168]
input swipe 540 1136 540 1136 900      # press AND HOLD the Copy item 900 ms → release
→ snackbar: "Copied 39.24430, -123.15008"
→ Android system clipboard overlay appears with the same text (OS-level confirmation the clip landed)

am start -a android.intent.action.SENDTO -d smsto:5551234   # Google Messages = different uid
input keyevent 279                      # KEYCODE_PASTE into the compose field
uiautomator: EDITTEXT CONTENT: '39.24430, -123.15008'   ← exact match, cross-app

adb shell cmd clipboard get-primary-clip and dumpsys clipboard are both unavailable on API 36, so the platform read-back from a focused activity + the cross-app paste are the oracles.

Root cause

Not reproducible on stock API 36 or Samsung One UI 16 — the write path is correct on these targets. The one real defect that IS provable from the code: the success toast was unconditional over a void write API. ClipboardManager.setText returns nothing, so whatever happened on Gavin's device (OEM clipboard manager interference, a focus race, a ROM-side silent drop), the app claimed "Copied" without knowing.

The fix (hardening — pending device confirmation from the reporter)

• CoordClipboard (new): writes via the platform ClipboardManager with ClipData.newPlainText, then reads the clip back and compares before reporting success. Never throws; OEM rejections and focus-blocked read-backs fail closed (wrongly admitting failure beats wrongly claiming success).
• MapScreen radial copy branch: toast is now honest — map.toast.copied only when the read-back matches, new map.toast.copyFailed (en + zh-Hant) otherwise. If Gavin's device drops the write, he now gets a failure toast = a signal we can chase, instead of a lie.
• ClipboardWriteInstrumentedTest: pins the write+verify contract and the held-click gesture on device. Re-ran post-fix: green on both emulator and SM-X210; full UI drive re-verified on the fixed build (verified toast + OS clipboard overlay + share sheet + cross-app paste into Messages all agree: 9.26736, -0.05022).

Verification

• ./gradlew assembleDebug ✅ ./gradlew testDebugUnitTest ✅ (CI parity)
• connectedDebugAndroidTest (clipboard class): ✅ engie_emulator API 36, ✅ SM-X210 One UI 16
• No manifest/permission changes; scope limited to the copy path

Follow-up for the reporter

If the failure persists on Gavin's device with this build, the new failure toast tells us the write is genuinely being rejected there — next ask: device model/ROM + whether a clipboard-manager/keyboard app is installed. If he still sees a success toast with nothing pasteable, the clip verifiably reached his system clipboard and something on-device is clearing it afterwards.

🤖 Generated with Claude Code