A Practical Guide to Android App Links for Casino Brands

What makes a link an App Link

Android handles three kinds of incoming links. A deep link with a custom scheme, such as example://, opens any app that registered the scheme. A web link is an http or https address that an app says it can handle. An App Link is a web link whose host Android has verified for that app.

The difference shows up on the device. For plain deep links and web links, Android's documentation warns that "even though your intent filters match a given URI, there is no guarantee that the system will route the deep link intent to your app." (A URI, or uniform resource identifier, is the link address.) For web links on Android 12 and higher, "they will almost always trigger the disambiguation dialog, meaning that they are likely to be handled by the user's web browser by default." Verification changes that: "Once verified, the system automatically routes links for that domain directly to your app, skipping the disambiguation dialog entirely."

For a casino or sportsbook brand this is the line between a link that reliably opens the account or event screen and one that drops people into the browser. If you are not sure which situation you are in, the note on links that open the browser lists the cases.

Declare the intent filter

Each route the app should own needs an intent filter on the activity that will show it. The pattern below follows Android's example, with verification turned on and an https host:

<activity android:name=".EventActivity" android:exported="true">
  <intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="https"
          android:host="www.example.com"
          android:pathPrefix="/events" />
  </intent-filter>
</activity>

Each element has a job. Android specifies the VIEW action "so that the intent filter can be reached from Google Search." The DEFAULT category lets the activity respond to implicit intents. The BROWSABLE category "is required in order for the intent filter to be accessible from a web browser. Without it, clicking a link in a browser cannot resolve to your app." The data element must include at least a scheme; the host and a path, path prefix or path pattern narrow the match. Note that a pathPrefix needs its leading slash.

Only list hosts you control and can serve a file on. The troubleshooting guide asks you to check whether "you include a URL that your app doesn't own" in an intent filter, The same guide notes that non-verifiable links added for testing make Android 11 and lower skip verification of all App Links, so keep such hosts out of release manifests.

How verification differs by Android version

The Android 11 rule matters for brands that run several hosts, for example a separate host per licensed market or a help center on its own subdomain. One host without a correct file can stop verification for every host on older devices, so either serve the file everywhere or keep the extra host out of the verified filters.

Choosing routes on a casino or sportsbook site

Hand the app the routes where the app does the job better: event and market pages, the bet slip, account screens. Keep pages on the web when they must stay readable to everyone, including people without the app and search engines: licensing details, terms, help and safer gambling pages. Android 15 dynamic rules and Apple's components both support exclusions, so you can open most of a path in the app and leave specific pages on the web. The same routes on iPhone are set up in the iOS Universal Links setup guide.

Market scope matters too. A real-money app is distributed only where the operator is licensed and must block other locations, as the store rules guide sets out. A link printed in a campaign for one market should land on a web page that still works for a visitor somewhere the app is not offered.

Confirm that Android verified each host

Install a release-signed build and wait. Android's test guide asks you to "wait at least 20 seconds after installation of your app to allow for the system to complete the verification process." Then read the state with adb shell pm get-app-links PACKAGE_NAME. A host marked verified passed. A state of none "indicates that the verification agent might not have completed the verification process yet." legacy_failure means a legacy verifier rejected the host for an unknown reason.

On Android 12 and later you can reset and re-run verification with pm set-app-links and pm verify-app-links --re-verify. Google also offers the Play Console Deep Links page and the Android Studio App Links Assistant. The full sequence, with the iOS equivalents, is in the deep link test plan, and the items to sign off are in the implementation checklist.

Mistakes that stop verification

• A redirect on the file host, such as http to https or the bare domain to www. The troubleshooting guide says the system then doesn't verify any App Links for the app.
• A fingerprint that does not match the certificate that signed the build, including the Play App Signing key.
• A lower-case fingerprint; the guide says it should be in upper case.
• No autoVerify attribute on any web intent filter.

Each fault, with the check that finds it, is in the taxonomy of broken app links.