Android Link Handling Preferences: User Control

Users have the final say in which app opens a link on Android. Even if your App Links are perfectly verified, a user can override the default behavior through Android's link handling settings. They can disable your app's link handling entirely, choose a different app, or reset their preferences.

Understanding how these preferences work is important for two reasons: first, to diagnose issues where "links don't open my app for this user," and second, to guide users who want to change their default link handler. This guide covers the settings UI across Android versions, how preferences interact with App Links verification, and what your app can do when the user has changed the defaults.

For the App Links verification process, see the Android App Links complete guide. For the Android 12+ changes, see Android 12+ App Links changes.

The "Open by Default" Settings

Android 12+ (API 31+)

Android 12 redesigned the link handling settings. Each app has an "Open by default" page in system settings:

Settings > Apps > [Your App] > Open by default

This page shows:

• Open supported links: A toggle (on/off). When on, verified App Links open in the app. When off, links open in the browser.
• Supported web addresses: A list of domains your app has declared in its intent filters, with verification status for each.

Users can:

1. Turn off "Open supported links" entirely (all links go to the browser).
2. Add or remove individual domains (selectively enable/disable link handling per domain).

Android 6-11 (API 23-30)

Older versions have a simpler interface:

Settings > Apps > [Your App] > Open by default

This page shows:

• Open supported links: Options are "Open in this app", "Ask every time", or "Don't open in this app".
• Supported links: A list of domains the app claims.

The user can also clear defaults by tapping "Clear defaults" on the app info page, which resets any previously selected "Open with" choices.

The "Always" and "Just Once" Legacy

Before Android 12, when a user tapped a link and saw the disambiguation dialog, they could choose "Always" or "Just Once." Choosing "Always" set a persistent preference that bypassed the dialog for future links. This preference can be cleared via "Clear defaults."

On Android 12+, this dialog is mostly gone for verified App Links (they open directly), but it still appears for unverified links.

How Preferences Interact with Verification

The relationship between verification and user preferences:

Verification	User Setting	Result
Verified	"Open supported links" ON	App opens directly
Verified	"Open supported links" OFF	Browser opens
Not verified	"Open supported links" ON	Disambiguation dialog (Android 11-) or browser (Android 12+)
Not verified	"Open supported links" OFF	Browser opens

Key insight: verification is necessary but not sufficient. Even with perfect verification, the user can override it. And without verification, user preferences can't elevate your app to default handler status (on Android 12+).

Common User Scenarios

Scenario 1: "Links used to open my app but now they don't"

The user (or a system update) changed the "Open supported links" setting. This happens when:

• The user accidentally toggles the setting while exploring app settings.
• A system update resets link handling preferences.
• The user installed a competing app that claims the same domain.

Diagnosis: Ask the user to check Settings > Apps > [Your App] > Open by default, and ensure "Open supported links" is enabled.

Scenario 2: "Links always ask me which app to use"

The app's App Links aren't verified. The system can't determine a default handler, so it shows the disambiguation dialog.

Diagnosis: Check verification status with adb shell pm get-app-links --user cur <package>. See the debugging guide for detailed steps.

Scenario 3: "Links open in the wrong app"

Another app has verified App Links for the same domain (unlikely but possible), or the user previously selected "Always" for a different app.

Diagnosis: Check which apps claim the domain:

adb shell pm query-activities -a android.intent.action.VIEW \
  -d "https://yourdomain.com/path" -c android.intent.category.BROWSABLE

Guiding Users to the Right Settings

Opening the Settings Directly

On Android 12+, you can open your app's "Open by default" settings page directly:

fun openLinkHandlingSettings(context: Context) {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
        val intent = Intent(
            Settings.ACTION_APP_OPEN_BY_DEFAULT_SETTINGS,
            Uri.parse("package:${context.packageName}")
        )
        context.startActivity(intent)
    } else {
        // Fallback for older versions: open app details
        val intent = Intent(
            Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
            Uri.parse("package:${context.packageName}")
        )
        context.startActivity(intent)
    }
}

When to Prompt

Don't aggressively prompt users to change their link settings. Good times to offer guidance:

• After a failed deep link: If the user opened your app manually after tapping a link that should have opened it directly, offer a one-time prompt: "Want links to open directly in [App]?" with a button to the settings page.
• During onboarding: For apps where deep linking is a core feature (messaging, social, content sharing), include a step in onboarding.
• In a help/FAQ section: Provide instructions for users who seek them out.

Checking Current Status

On Android 12+, you can check your app's link handling status programmatically:

fun checkLinkHandlingStatus(context: Context): Map<String, Int> {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
        val manager = context.getSystemService(DomainVerificationManager::class.java)
        val userState = manager.getDomainVerificationUserState(context.packageName)
        return userState?.hostToStateMap ?: emptyMap()
    }
    return emptyMap()
}

// Usage
val status = checkLinkHandlingStatus(this)
status.forEach { (domain, state) ->
    val stateName = when (state) {
        DomainVerificationUserState.DOMAIN_STATE_VERIFIED -> "verified"
        DomainVerificationUserState.DOMAIN_STATE_SELECTED -> "selected by user"
        DomainVerificationUserState.DOMAIN_STATE_NONE -> "not handled"
        else -> "unknown"
    }
    Log.d("LinkStatus", "$domain: $stateName")
}

The three states:

• VERIFIED (1): Automatically verified via Digital Asset Links. Best state.
• SELECTED (2): User manually selected your app in settings. Also good, but may be reset.
• NONE (0): Your app doesn't handle this domain (or the user disabled it).

Manufacturer Variations

Android link handling settings vary across manufacturers:

Samsung (One UI): Settings > Apps > [App] > Set as default > Open supported links. Samsung adds its own link handling for Samsung Internet browser, which can override Chrome's behavior.

Xiaomi (MIUI): Settings > Apps > Manage apps > [App] > Open by default. MIUI has additional "App link verification" settings that can affect App Links independently.

Huawei (EMUI): Settings > Apps > Apps > [App] > Open by default. Huawei devices may have additional link interception from Huawei Browser.

Stock Android / Pixel: Settings > Apps > [App] > Open by default. The standard experience described in this guide.

Always test on the devices your users actually use. The link handling UI and behavior can differ significantly across manufacturers.

Best Practices

1. Verify your App Links correctly. Verified links open automatically without any user action needed. This is the best experience.

   Don't nag users about settings. A single, contextual prompt is acceptable. Repeated prompts are not. Users who chose to disable your link handling did so intentionally.

   Handle the "links open in browser" case gracefully. Your web fallback should work well. If a user's link handling is disabled, the URL loads in the browser. Make sure your website provides a good experience and offers a path back to the app.

   Use Tolinku deep links for reliable routing. Tolinku handles the fallback chain (App Links > intent URL > web redirect) automatically, so even when user preferences prevent App Links from working, the link still resolves.

   Test with link handling disabled. Disable "Open supported links" on your test device and verify your link flow works through the fallback path.

   Respect user choice. If a user prefers links to open in the browser, that's their decision. Your web experience should be good enough to serve them.

   For setting up verified App Links, see the Android App Links guide. For understanding verification states, see verified vs. unverified App Links.