Sailthru supports the validation requirements of Android’s App Links functionality for our customers who use white-labeled link domains in Sailthru templates (for example, link.yourdomain.com).

About App Links

This functionality facilitates a streamlined end-user experience within Android, allowing users to click a link in an email or SMS and have it directly open to a registered native app. Previously, users were shown a disambiguation popup to choose which app to use to handle the link. However, as of Android 12, these links will always be handled by a web browser unless App Links are supported.

This new functionality allows a standard “https://” link to open straight to a registered app, as opposed to embedding deep-link protocol links in emails.

You must provide Sailthru one (1) file to successfully enable App Links using your Sailthru Link Domain:

• An Android assetlinks.json file

If you’re ready to go, you can upload these files through the Mobile App Links settings page in my.sailthru.com. If you’re looking for details on these files, continue reading.

Authentication

To protect rogue links from hijacking your app, Android uses an authentication and validation process. You can read more about the process and the full specification for this file here.

Enabling app links from your link domain requires a small JSON file called the assetlinks.json file to be accessible on your domain. The file provides permissions to Android to open links directly in apps. Your assetlinks.json file can provide permissions for multiple apps, including development and staging versions, if they have their own app IDs. For example, it may resemble this sample:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.site",
    "sha256_cert_fingerprints": ["<app_release_fingerprint>"]
  },
  {
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.development",
    "sha256_cert_fingerprints": ["<app_release_fingerprint>"]
  }
}]

Points to remember for your assetlinks.json file:

• Sailthru can host this file for you at your established link domain.
• Apple requires the assetlinks.json file to be accessible via https.
  • By default, Sailthru serves rewritten links and link domain pages using https.
• You may upload as many assetlinks.json files as you have established link domains in the Sailthru link settings page.
• Once a link domain is saved in the “Link Domain” settings page, it will be made available in the Universal Links setting page and API.
• Android studio has an `App Links Assistant` that can help generate the assetlinks.json for you.
• If you use Play App Signing for your app you will need to get the SHA fingerprint from the Play console developer account for the assetlinks.json to work correctly.

Link Parsing and Tracking

When App Links to your domain are clicked within supported apps and your app is installed on the device, these links bypass the browser and hand the clicked URL directly to the app.

The Sailthru Mobile SDKs can handle Sailthru email link rewrites and can give the native application the original link’s destination. Mobile App developers should read the Mobile SDK documentation/ReadMe for information on setting up this functionality.

Establishing App Links with Sailthru Email Link Rewrites

1. Create an assetlinks.json file matching Android’s specifications using the Android App Link Documentation or the Android Studio App Links Assistant.
2. Using the my.sailthru.com Mobile App Links settings page or API, upload your AASA file.
   
   
3. Test the assetlinks.json file by entering your link domain in Android’s Validation Tool and by using links to your app.

Enable Opening Links in the Native Browser

To enable this free feature on your account, contact Sailthru Support or your CSM.

1. Check that your assetlinks.json is uploaded to Sailthru.
2. In your AndroidManifest.xml, set the pathPrefix values that you would like the app to handle. Other paths will be handled by the browser.

The SDK should be set up to receive the link, parse it to the original destination, and also call back to Sailthru to report the tracked link click.

Examples

The following examples show how Sailthru parses links.

Link domain: link.example.com

AndroidManifest File:
pathPrefix: /click/

Marketer adds this link: https://www.example.com/products/product-name?psrc=browse:category
Sailthru rewrites it to: https://link.example.com/click/<hash>
App Will Open: Yes
Why: The original root domain “example.com” matches a link domain in the account and used the /click/ path as a result.

Marketer adds this link: facebook.com/example
Sailthru rewrites it to: https://link.example.com/external/<hash>
App Will Open: No
Why: The original root domain “facebook.com” does not match the link domain and the link rewrite used the /external/ path as a result.

Marketer adds this link: https://www.example.com/how-example-works.htm?noapp=true
Sailthru rewrites it to: https://link.example.com/external/<hash>
App Will Open: No
Why: The original root domain “example.com” did match the link domain, however the marketer adding the “noapp=true” query param and the link rewrite used the /external/ path as a result.