assetlinks.json<\/code> file at https:\/\/{domain}\/.well-known\/assetlinks.json<\/code> contains an entry for your app's package name and signing certificate.<\/li>\n- Your app's intent filter declares
android:autoVerify="true"<\/code> for that domain.<\/li>\n<\/ol>\n\n\n\nWhen both conditions are true and the verification check succeeds, Android marks your app as the trusted default handler for that domain. The trust is domain-specific. An app can be verified for one domain and unverified for another.<\/p>\n\n\n\n
The Android documentation on verifying App Links<\/a> describes the technical details of the verification process. The short version: Android (or Google's servers on Android 12 and later) fetches the assetlinks.json<\/code> file during or shortly after app installation and checks whether the file authorizes your app.<\/p>\n\n\n\nThe User Experience: Verified<\/h2>\n\n\n\n
When your app is verified for a domain and a user taps a link on that domain, the experience is direct:<\/p>\n\n\n\n
\n- User taps
https:\/\/example.com\/products\/123<\/code> in a browser, email, or any other app.<\/li>\n- Android immediately launches your app and delivers the link.<\/li>\n
- Your app opens to the product page.<\/li>\n<\/ol>\n\n\n\n
No dialog. No delay. No choice presented to the user. The link behaves like a first-class feature of the platform.<\/p>\n\n\n\n
This matters most in high-intent moments. Someone taps a product link from an email promotion, or follows a referral link from a friend. The fewer steps between tapping the link and seeing the content, the better the conversion. Even a single extra tap on a disambiguation dialog causes measurable drop-off, because some users will choose the browser (or simply close the dialog).<\/p>\n\n\n\n
The User Experience: Unverified<\/h2>\n\n\n\n
When your app is not verified, the experience depends on several factors:<\/p>\n\n\n\n
![\"Android](\"https:\/\/tolinku.com\/blog\/wp-content\/uploads\/2026\/03\/doc-android-disambiguation-dialog.png\")
<\/p>\n\n\n\n
Source: Android Developer Documentation<\/a><\/em><\/p>\n\n\n\nIf only one app has an intent filter matching the URL:<\/strong> Android may still show a dialog asking the user to confirm which app should handle the link, even if there is only one candidate. This is the default disambiguation behavior for unverified links.<\/p>\n\n\n\nIf no app has a matching intent filter (or none pass verification):<\/strong> The URL opens in the browser. The user never sees your app.<\/p>\n\n\n\nIf the user previously chose an app:<\/strong> Android remembers the user's choice. If a user once selected your app from the disambiguation dialog, Android may route subsequent links from that domain to your app without showing the dialog again, but this preference is fragile. On Android 12 and later, this implicit preference behavior changed and became less reliable.<\/p>\n\n\n\nThe disambiguation dialog itself looks like a bottom sheet with app icons and names. For most users, it is an interruption. For technical users, it is information they can act on. For everyone, it adds friction.<\/p>\n\n\n\n
The autoVerify Attribute<\/h2>\n\n\n\n
The android:autoVerify<\/code> attribute is what tells Android to attempt verification for your intent filter. Without it, your intent filter works as an unverified deep link claim.<\/p>\n\n\n\nCorrect placement:<\/p>\n\n\n\n
<intent-filter android:autoVerify="true">\n <action android:name="android.intent.action.VIEW" \/>\n <category android:name="android.intent.category.DEFAULT" \/>\n <category android:name="android.intent.category.BROWSABLE" \/>\n <data\n android:scheme="https"\n android:host="example.com" \/>\n<\/intent-filter>\n<\/code><\/pre>\n\n\n\nThe attribute goes on the <intent-filter><\/code> element, not on the <data><\/code> element. A common mistake is placing it on <data><\/code>, where it is silently ignored.<\/p>\n\n\n\nIf you add autoVerify="true"<\/code> but do not host a valid assetlinks.json<\/code> file, verification fails and the intent filter behaves exactly like an unverified one. The attribute alone is not enough; the server-side file is required.<\/p>\n\n\n\nWhat Happens When Verification Fails<\/h2>\n\n\n\n
If Android attempts verification and the assetlinks.json<\/code> file is missing, unreachable, or contains incorrect data, your app is treated as unverified for that domain. The intent filter still exists and still matches URLs, but without verified status.<\/p>\n\n\n\nOn Android 11 and earlier, failure for one domain in an intent filter affected all domains in that filter. On Android 12 and later, each domain is evaluated independently. A failure for www.example.com<\/code> does not remove verified status for example.com<\/code> if that domain's file is correct.<\/p>\n\n\n\nVerification failure is silent by default. Users see the disambiguation dialog (or links go to the browser) and there is no visible error. To check verification status programmatically during development:<\/p>\n\n\n\n
adb shell pm get-app-links --package com.example.myapp\n<\/code><\/pre>\n\n\n\nThe output shows each domain and its status. verified<\/code> means the check passed. rejected<\/code> means the check ran but the assetlinks.json<\/code> file did not match your app. none<\/code> usually means verification has not run yet, the domain is unreachable, or there was a network error.<\/p>\n\n\n\nFor common failure reasons and how to diagnose them, see the Tolinku Android troubleshooting guide<\/a>.<\/p>\n\n\n\nFallback Behavior When the App Is Not Installed<\/h2>\n\n\n\n
Neither verified nor unverified App Links help when the app is not installed. If a user taps a link and the app is not on their device, the link opens in a browser regardless of verification status.<\/p>\n\n\n\n
This is where deferred deep linking becomes important. When the user installs the app after tapping a link, the app can retrieve the original link and route the user to the correct content. This requires a deep linking platform that stores the original URL and delivers it to the app on first launch.<\/p>\n\n\n\n
Tolinku handles this through its deep linking platform<\/a>. The Tolinku SDK captures the intent at the web layer and replays it after installation, so the user arrives at the right place even if they had to install the app first.<\/p>\n\n\n\nVerified App Links and Instant Apps<\/h2>\n\n\n\n
Android Instant Apps are a special case. Instant Apps can open URLs without being fully installed, and they use App Links for URL routing. Instant App verification works through the same assetlinks.json<\/code> mechanism, but the instant app variant of your app requires its own entry in the Digital Asset Links file.<\/p>\n\n\n\nIf you are building an Instant App alongside your main app, both package names (or both applications if they share a package name with different build types) need to be authorized in the file.<\/p>\n\n\n\n
Comparing the Two Outcomes<\/h2>\n\n\n\n