If Android App Links are inconsistent, start with assetlinks validation. This guide gives engineering and growth teams a release-safe sequence to verify deep linking in Android: file hosting, signing parity, intent-filter scope, and route behavior before traffic scales.
| Check | Passing signal | Failure signal |
|---|---|---|
| Public file reachability | `/.well-known/assetlinks.json` returns 200 with valid JSON and no redirect chain. | Redirects, auth gates, or HTML responses prevent Android verification. |
| Package + fingerprint parity | Package name and SHA-256 fingerprints match the exact release signing cert. | Debug fingerprint or outdated certificate breaks verification on production builds. |
| Relation correctness | Includes `delegate_permission/common.handle_all_urls` for intended hosts/routes. | Missing or partial relation blocks expected in-app route opening. |
| Real-device behavior | Installed app opens expected screen; non-installed state follows planned fallback. | Chooser prompts, browser opens, or mismatched routes in campaign links. |
Android deep linking has three separate layers: the web domain must publish assetlinks.json, the app must declare matching App Links intent filters, and the installed build must be signed with a certificate listed in the file. A validator can catch the domain layer quickly, but release QA should still confirm the app opens the intended screen on a real device.
This matters for acquisition links, QR campaigns, email links, and social profile links where a browser open or chooser prompt can break conversion before the user reaches the app.
