also looking at this
fix(android): resolve share() with whether the person picked an app
#210
12 files
+399
-56
| @@ -49,10 +49,16 @@ bun run test:mobile-e2e:android | ||
| 49 | 49 | ``` |
| 50 | 50 | |
| 51 | 51 | ``` |
| 52 | ok android-shim — 4/4 cases, no zig | |
| 53 | ok android-runtime — 4/4 cases, zig served registered:103, declines:0 | |
| 52 | ok android-shim — 6/6 cases, no zig | |
| 53 | ok android-runtime — 6/6 cases, zig served registered:103, declines:0 | |
| 54 | 54 | ``` |
| 55 | 55 | |
| 56 | One Android case needs a person: `share.dismissed.resolvesFalse` opens the | |
| 57 | real share menu and expects `false` once it is dismissed. The harness plays | |
| 58 | that part. It waits until `dumpsys window` shows the chooser holding input | |
| 59 | focus, saves `share-menu.png`, presses Back, and fails the run if the page asked | |
| 60 | for a dismissal and no menu ever appeared. | |
| 61 | ||
| 56 | 62 | The runtime leg fails on any line where a Zig native gave up — "fell through |
| 57 | 63 | to the shim", "failed with no fallback" or "could not reach the page" — because |
| 58 | 64 | Kotlin answering in its place is invisible to the page, and a runtime that has |