On Android, the difference between a link any app can claim and a link that belongs to you comes down to verification. Android App Links are HTTPS deep links that you prove are yours by hosting a Digital Asset Links file on your domain, so the system opens them directly in your app and no other app can hijack them. Without that verification, a deep link is just a request any installed app can register to handle, which is a link-hijacking risk. Here is how App Links and the assetlinks.json verification work, and why they are the secure way to handle deep links.
Short answer
Android App Links are HTTPS links verified to belong to your app through a Digital Asset Links file, assetlinks.json, hosted at /.well-known/ on your domain. Per Android's App Links documentation, when you mark an intent filter with android:autoVerify="true" and host a valid assetlinks.json listing your app's package name and signing certificate fingerprint, the system verifies the link is yours and opens it directly in your app, with no chooser dialog and no way for another app to claim it. This is the secure alternative to custom schemes and unverified deep links, which any app can register to intercept. Set up verification correctly so your links cannot be hijacked.
What you should know
- App Links are verified HTTPS links: proven to belong to your domain.
- assetlinks.json is the proof: hosted at /.well-known/ on your domain.
- autoVerify triggers it: the intent filter requests verification.
- Verified links cannot be hijacked: other apps cannot claim them.
- Unverified deep links can be claimed: any app can register to handle them.
What are Android App Links?
They are deep links the system has confirmed belong to your app. An App Link is an HTTPS URL on your own domain that opens directly in your app because Android verified the association between the domain and the app. The verification uses Digital Asset Links: you host an assetlinks.json file at the well-known path on your domain that names your app's package and its signing certificate fingerprint, and you mark the matching intent filter with android:autoVerify="true". When those line up, Android trusts that the link is yours, opens it in your app without showing a chooser, and prevents another app from handling it. So App Links are the verified, hijack-resistant form of deep linking, the Android counterpart to iOS Universal Links, and they exist precisely because unverified links are not trustworthy.
App Links versus custom schemes and unverified deep links
The difference is whether the link is proven to be yours. The table compares them.
| Link type | Hijack risk |
|---|---|
| Verified App Link (autoVerify plus assetlinks.json) | Low; the system confirms it is yours |
| Unverified HTTPS deep link | Higher; another app can register to handle it |
| Custom scheme like myapp:// | High; any app can register the scheme |
The verified App Link is the safe choice, because the Digital Asset Links check ties the link to your domain and signing key, so another app cannot claim it. An unverified deep link, by contrast, can prompt a chooser or be handled by another app that registered the same pattern, and a custom scheme is the least safe of all, since any app can declare it. For any link that carries meaning, verification is what makes it dependable.
How do you set up verification?
Host the assetlinks.json file and mark your intent filter for auto-verification. First, create an assetlinks.json that lists your app's package name and the SHA-256 fingerprint of your signing certificate, and serve it over HTTPS at /.well-known/assetlinks.json on the domain your links use. Second, add an intent filter for your HTTPS links with android:autoVerify="true", so Android attempts verification on install. When the file and the manifest agree, the links become verified App Links that open directly in your app. The common failure is a verification mismatch, a missing or unreachable file, the wrong certificate fingerprint, or a domain mismatch, which causes verification to fail silently and your links to fall back to the chooser, where they can be claimed by other apps. So confirm the file is correct and reachable, and test that verification actually succeeds.
What to watch out for
The first trap is relying on a custom scheme or an unverified deep link for something that matters, when either can be intercepted; use a verified App Link. The second is a broken assetlinks.json, wrong fingerprint, wrong path, or not reachable, which makes verification fail quietly and drops you back to a hijackable chooser. The third is treating an incoming link as trusted; even with App Links, validate the input rather than acting on it blindly. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and surfaces your deep-link intent filters and how the app handles links, so you can confirm sensitive links use verified App Links rather than an unverified pattern. The hosting and manifest setup you complete on your side.
What to take away
- Android App Links are HTTPS links verified to belong to your app via a Digital Asset Links file, so the system opens them directly and no other app can hijack them.
- Verification needs
android:autoVerify="true"on the intent filter and a validassetlinks.jsonwith your package name and signing fingerprint at/.well-known/on your domain. - They are the secure alternative to custom schemes and unverified deep links, which any app can register to intercept.
- Confirm the assetlinks.json is correct and reachable so verification succeeds, and use a pre-submission scan such as PTKD.com to check your deep-link handling.
