also looking at this
fix(android): hand the launch link to the page that subscribes for it
#232
17 files
+776
-136
| @@ -76,6 +76,14 @@ that part. It waits until `dumpsys window` shows the chooser holding input | ||
| 76 | 76 | focus, saves `share-menu.png`, presses Back, and fails the run if the page asked |
| 77 | 77 | for a dismissal and no menu ever appeared. |
| 78 | 78 | |
| 79 | After the suite, each leg also cold-starts the app through a link twice, the | |
| 80 | same two ways as iOS, with `adb shell am start -W -a android.intent.action.VIEW | |
| 81 | -d '<link>' <package>`. Naming the package rather than the activity means the | |
| 82 | link is resolved through the generated manifest's intent filter, and `-W` must | |
| 83 | report `LaunchState: COLD`, so a link delivered to an app that was still | |
| 84 | running cannot pass for one that launched it. The page writes its report to | |
| 85 | logcat, and each launch keeps its own `deeplink-<mode>-logcat.txt`. | |
| 86 | ||
| 79 | 87 | The runtime leg fails on any line where a Zig native gave up — "fell through |
| 80 | 88 | to the shim", "failed with no fallback" or "could not reach the page" — because |
| 81 | 89 | Kotlin answering in its place is invisible to the page, and a runtime that has |