Test escape-surface page — for authorized device research only. Each card below is an independent probe; use one at a time and record what fires outside the sandbox.
1. Terms of Service — upload signed copy
Tests whether <input type=file> opens the native storage-access-framework file picker.
2. Download network policy (PDF)
Tests whether a download invokes the system Download Manager notification/UI.
Tests whether a live <audio> stream triggers the system media-session notification/controls (lock screen, notification shade) and whether that surface exposes anything beyond play/pause.
Local audio:
13. Legacy protocol support check
Tests how the WebView resolves rare/legacy URI schemes it doesn't natively render — confirms whether scheme handling is deny-by-default or permissive-by-default, and surfaces any unexpected OEM/carrier app registrations.
14. Cast to device
Tests whether the Remote Playback API / Presentation API can summon the native system Cast device picker directly from page JS, without any browser-chrome menu interaction.
15. Add shortcut to home screen
Tests whether beforeinstallprompt fires and can be triggered from page JS (Android's analogue to desktop "Create shortcut"). Requires HTTPS + manifest to qualify — likely a negative result on a plain HTTP captive portal page, which is itself informative.
16. Storage & persistence check
Tests whether cookies, localStorage, sessionStorage, and IndexedDB are available, and whether values survive a page reload / re-navigation — indicates whether the captive portal WebView is properly isolated from the main browser profile. Quota estimate and empirical fill-test below reveal whether this origin shares a storage pool with the main browser profile (large/matching quota) or has its own small, ephemeral allocation (small quota).
17. Local service check
Tests both IPv4 (127.0.0.1) and IPv6 ([::1]) loopback per port to infer open vs closed/filtered (fast refusal vs hang/timeout). Coarse signal only — confirms presence of a listener, not what it is. Cleartext-blocked WebViews or unrouted IPv6 loopback will show uniform results across all ports on that stack; treat that as inconclusive, not "all closed," unless a known-open port also reads uniform.
Results will populate below as each port is tested (timeout 800ms).
18. Date / time / color picker check
These input types hand off to native OS picker components rather than being drawn by the WebView itself — same "different system surface" category as the print dialog and file picker. Check each picker for any navigation chrome, settings shortcuts, or long-press context actions that shouldn't be reachable pre-auth.
Only one native picker is normally modal/foreground at a time — this button fires all four back-to-back with no delay to see how the second/third/fourth request is actually handled (queued silently, ignored, throws, or stacks/glitches) rather than assuming.
19. Memory pressure check
Allocates memory aggressively to force an OOM condition in the WebView/host process. The interesting result isn't the crash itself — it's what screen the device lands on afterward. Does the setup wizard / captive portal correctly re-lock, or does recovery fall back to an unexpected activity or the home launcher? Run on a disposable test unit only — recovery may require a re-flash.
Not running.
20. Fullscreen & orientation check
Fullscreen transitions have historically been a spot where system UI (status bar, notification shade pull-down) briefly re-exposes itself mid-transition. Rapid toggling stresses the transition state machine specifically, rather than the steady-state fullscreen view. Orientation lock mimics the YouTube-style expand-to-landscape behavior. The combined test at the bottom stacks orientation+fullscreen+memory pressure to see if the crash-recovery screen differs from the plain OOM test.
Idle.
21. Long-press context menu — MANUAL TEST
Not scriptable — the long-press "Share/Copy/Save" menu is native chrome UI with no JS trigger, unlike navigator.share() in card 8. Long-press each element below by hand and note whether Share appears, and what apps the resulting chooser lists.
Long-press to select this text block: this is a paragraph of selectable text intended purely as a target for the text-selection toolbar, which on Android often shows a Share option alongside Copy and Search when a selection is active.
No automatic result — record findings manually in your session notes.
22. Intent extra injection probe
Fires intent:// URIs carrying crafted extras — embedded CRLF (log injection), oversized strings (layout/overflow spoofing), and null-byte-adjacent payloads (parser truncation) — against a target package/component you specify. Watch logcat and the receiving UI for anomalies, not just whether the intent resolves.
23. Bulk intent/link list tester
Loads a list of URIs/intents (one per line, e.g. from href_links.txt) and fires them sequentially with a delay between each — useful for sweeping exported activities/components you've enumerated via adb/jadx rather than testing one at a time. Optional: cross every line against the card 22 injection payloads (CRLF/oversized/null-byte) instead of firing it as-is. Caveat: if any entry causes real navigation (rather than an intent handoff), the loop stops since the page unloads — check the log to see how far it got.
Auto-loads href_links.txt from the same folder as this page on load. If that fails (e.g. opened as file:// with fetch blocked), use the file picker fallback below.
Idle. Loaded 0 lines.
24. All href_links.txt entries — clickable
Renders every line from the loaded list (card 23) as an individual clickable link, so you can tap through one at a time by hand and watch what happens to each, instead of the automated timed sweep. Useful when a bulk run dies partway through and you want to resume manually from a known index, or when you specifically want to observe each navigation rather than just log it.
Not yet rendered — click "Refresh from loaded list" once card 23 has entries loaded.
25. Camera / mic / location / USB / screen-share / notifications check
Tests whether permission-gated hardware and system APIs are reachable from page JS pre-auth, and — more importantly than whether they're merely available — whether the resulting native permission dialog is itself a system-level surface reachable outside the WebView sandbox. Each probe logs API presence, prompt outcome, and any error distinctly, since "not available" and "available but denied" are different findings.
