Skip to content

Troubleshooting / Android verification

Android App Link Opens the Browser Instead of Your App

Diagnose domain verification, signing fingerprints, intent filters, and the app handoff before changing routing rules.

For: Android, Flutter, React Native, and Unity teams whose HTTPS links stay in a browser on Android.

WilderLinks developer guide

The problem

An HTTPS link loads a web page or chooser even though the app is installed. That can happen before the WilderLinks SDK receives any URL.

Android verifies the relationship between an HTTPS host and an app. The host publishes a Digital Asset Links file; the installed app declares a matching intent filter. WilderLinks can serve the file for a configured domain, but Android decides whether the app is the verified handler.

Before you start

  • An installed build signed with the key you want to test, plus its exact package name.
  • A verified WilderLinks link hostname and an app profile configured for that package and signing fingerprint.
  • An Android device or emulator with adb and network access.

Diagnose in order

  1. 01WilderLinks

    Inspect the exact host and association response

    Request the file from the same hostname used by the link, not a similar root or www hostname. Compare the package name and SHA-256 fingerprint with the build actually installed. If you use Play App Signing, use the app-signing certificate for the relevant release.

    • The URL responds with JSON over HTTPS.
    • The package name matches the installed application ID.
    • The SHA-256 value matches the signing certificate of that build.
    Inspect assetlinks.jsonshell
    curl -i https://links.example.com/.well-known/assetlinks.json

  2. 02Your app

    Check the app intent filter

    Confirm the activity has a VIEW action, DEFAULT and BROWSABLE categories, HTTPS scheme, the exact host, and android:autoVerify="true". SDK initialization does not add this manifest configuration.

    • The filter belongs to the activity that receives the link.
    • The host and relevant path pattern match the clicked URL.
    • No debug/release application-ID mismatch is present.
  3. 03Operating system

    Ask Android for its verification state

    Install or reinstall the test build, wait for asynchronous verification, and inspect the domain state. On Android 12 or later you can explicitly request re-verification after changing the host file. A state other than verified needs investigation before SDK debugging.

    • The exact host appears in the package output.
    • The host state is verified on the device being tested.
    • Device network and default-app settings allow verification.
    Inspect Android verificationshell
    adb shell pm get-app-links com.example.app
    # Android 12+ after changing association:
    adb shell pm verify-app-links --re-verify com.example.app

  4. 04WilderLinks

    Separate OS opening from WilderLinks routing

    Only after Android delivers the URL should you inspect the SDK result and navigate to the screen. Use the public tester to inspect the saved route for Android; it is read-only and does not prove that the operating system opened your app.

    • The app receives the URL in its activity or framework listener.
    • The SDK domain list contains the exact link host.
    • The tester reports the expected saved destination type and route strategy.

Expected result

  • Android reports the link host as verified for the installed app.
  • Opening a matching HTTPS link can deliver the URL to the app.
  • Your app uses the resolved payload to navigate; the SDK does not navigate for you.

What this check cannot prove

  • A successful WilderLinks configuration test does not verify Android App Links on a device.
  • A verified domain does not force every browser or user preference to open the app.
  • Changing a dashboard route cannot repair a missing manifest filter or mismatched signing fingerprint.

Next action

Read-only configuration check. Device behavior still needs a device.

Inspect a Saved Link