What the Android Deep Link Builder does
This builder writes the AndroidManifest.xml intent filter for Android deep links and verified App Links from your package name, schemes, hosts and path rules. It also generates matching test URLs, the adb command to open each one on a device, the assetlinks.json your website must host for verification, and warnings for the mistakes that stop links opening your app.
Deep links are easy to get almost right. A capital letter in a scheme, a path prefix without its leading slash, or a custom scheme sharing a filter with verified web links all fail silently: the link simply opens the browser. The checks here catch those before you build.
How to use it
- Enter your application ID and the activity that should receive the links.
- Tick https (and http if you still serve it), add any custom scheme such as myapp, and list the hosts, one per line. Use *.example.com to cover subdomains.
- Add path rules, one per line, as a type and a value - prefix /products, path /cart, or pattern /o/.*/track. Leave the box empty to match every path.
- Keep android:autoVerify ticked for App Links, and add your signing certificate's SHA-256 fingerprint to fill in assetlinks.json.
- Paste a URL into the tester to see whether the filter would catch it, then copy the XML and the adb commands.
Reading the results
Problems are things Android will not accept or match; warnings are choices that usually defeat the purpose, such as web links without autoVerify, which on Android 12 and later open in the browser by default.
Web and custom schemes are written as two separate intent filters. Inside one filter every scheme, host and path combine freely, and autoVerify would try to verify the custom scheme as well.
The adb commands start the link on a connected device or emulator exactly as a tap would. For App Links, pm get-app-links shows whether each host verified.
Worked example: a shop's product and tracking links
The shop example uses com.example.shop with https links on example.com and *.example.com, the path rules prefix /products and pattern /o/.*/track, and a custom scheme shopapp.
The builder writes an autoVerify filter for https with both hosts and both path rules, and a second, unverified filter for shopapp. Because one host is a wildcard, verification happens against the root domain, so there is one file to host: https://example.com/.well-known/assetlinks.json.
The tester URL https://www.example.com/o/88121/track opens the app: www.example.com matches *.example.com, and /o/88121/track matches the glob /o/.*/track, where .* means any run of characters.
How Android matches the path patterns
android:path must equal the whole path, android:pathPrefix must match its start, and android:pathSuffix its end. android:pathPattern is a simple glob, not a regular expression: a dot matches any one character, a star repeats the character before it zero or more times, so .* matches anything, and a backslash makes the next character literal. In the XML file, that backslash is itself written twice.
Android 12 added android:pathAdvancedPattern, which supports character classes such as [0-9]+ and counted repeats. Devices on older versions ignore it, so pair it with a simpler rule if you support them.
Limitations: what the result does not prove
- It writes and checks the filter; it cannot see your installed app. Verification also depends on the assetlinks.json on your server - check it with the assetlinks.json Validator.
- Path matching here follows the documented PatternMatcher rules. Android's own matching of query strings, fragments and ports is not modelled; intent filters ignore the query and fragment.
- Custom schemes cannot be verified or reserved: another app can register the same scheme.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- Android Developers - Create deep links to app content - checked 19 Sep 2026
- Android Developers - Verify Android App Links - checked 19 Sep 2026
- Android reference - <data> manifest element
- Android reference - PatternMatcher
Frequently asked questions
What is the difference between a deep link and an Android App Link?
A deep link is any URL an intent filter accepts, including custom schemes like myapp://. An App Link is an http or https deep link with android:autoVerify="true" whose domain proves, through assetlinks.json, that it belongs to your app. Verified links open the app directly without a chooser.
Why does my link open the browser instead of my app?
Common causes are an unverified web link on Android 12 or later, a scheme or host with capital letters, a path rule without a leading slash, or the app not being the verified handler. Run adb shell pm get-app-links with your package to see each domain's verification state.
How do I test a deep link with adb?
Use adb shell am start -W -a android.intent.action.VIEW -c android.intent.category.BROWSABLE -d followed by the URL in quotes and your package name. The builder writes one command per sample URL, with the quoting done for you.
Do I need a separate intent filter for a custom scheme?
It is safer. Android merges all data elements in one filter, so a custom scheme would combine with every host and path of your web links, and autoVerify on that filter would try to verify a scheme that cannot be verified.
Where does assetlinks.json go for a wildcard host?
For *.example.com, Android fetches the file from the root domain, https://example.com/.well-known/assetlinks.json. For plain hosts, each host needs its own file at its own /.well-known/ path.
Which SHA-256 fingerprint belongs in assetlinks.json?
The fingerprint of the certificate that signs the app users install. With Play App Signing that is the app signing key shown in Play Console under App integrity, not your upload key. Debug builds need the debug key's fingerprint as well if you test verification with them.
Last reviewed by the A2Z.Tools team against the sources listed above.
