This is part three of a four-part technical guide to deep linking on Android. The previous posts covered URI schemes and Chrome Intents and the next will cover Google Play Referrer.
Deep Linking with Android App Links
With the recent release of Android Marshmallow (6.0), Android introduced a new mechanism for opening up the app directly, called App Links. This mechanism is meant to replicate the functionality of Universal Links from iOS 9, where if a normal HTTP/HTTPS link is clicked and the corresponding app is installed, it will open immediately. Here’s the redirect logic of the App Link:
- Open app with intent if installed
- Fall back to web link if not installed
The Android App Link is simply a way to turn your existing website links into app links as well. An example would be: https://imbd.com/title/12345. If IMDB properly configures their website for app links, when IMDB is installed on the phone, it will open up immediately when the link is clicked. If the app is not installed, the web URL will be opened in a browser.
In a few months, after 6.0 becomes more prevalent, it could bypass the standard URI and Chrome intent mechanisms. In the meantime you’ll need to support it alongside all other mechanisms to be sure you handle all of the edge cases– again, Android is extremely fragmented. To learn more, keep reading or request a Branch demo.
Requirements for Android App Links
- Must have a functional website
- User must be on Android 6.0 +
Configuring Android App Links
There are two steps to configure your service to use app linking:
- Configure the manifest to receive intents
- Register your website as an App Link
Step one – Add the intent filters to your manifest
This is fairly straightforward. You need to tell Android what web site(s) should open your app instead of the site.
Step two – Configure your website for App Links
You must create a file called assetlinks.json file in the following format:
Note: we’ve gotten App Links to work without changing the default value of “android_app”.
The SHA256 fingerprints of your app’s signing certificate. You will need to use the `keytool` to generate the fingerprints. From the command line, `cd` into the java home directory, then `cd` into the `bin` folder. Then run the following command:
$ keytool -list -v -keystore my-release-key.keystore
(For help locating the keytool, see this example on Mac or Windows.)
Lastly, the assetlinks.json file must be hosted at `/.well-known/assetlinks.json`. We setup the one for all Branch integrated apps using our Node+Express link servers. Here’s the code we used:
Handling the Deep Link in the App
To handle the deep link in the app, you simply need to grab the intent data string in the Activity that was opened via the click. You can do it like so:
Unfortunately from here you’ll need to do string parsing to read the full string of the App Link which triggered the app to open.
Practical Use for Deep Linking
Practically, this would be the easiest mechanism to use if everyone were on 6.0+ and you had a website built. Since that won’t happen for another few years, you’ll need to handle the edge cases.
For now, we recommend enabling your website with App Links, but still leveraging your existing deep link mechanisms around the URI scheme and Chrome intents until these are more universal. For example, if a user opens up your site and has the app installed, you want to trigger a Chrome intent or URI scheme if they click a button on your mobile site to launch the app. It appears that App Links do not handle that scenario.
If you don’t have a website, but want to leverage App Links, we’d recommend incorporating Branch Deepviews into your overall product strategy. They are mobile web previews of your app content, automatically generated and hosted by us. Deepviews offers a good alternative for users to view/experience content when they don’t have your app installed, and is a good fallback for Android App Links.
Stay tuned for upcoming episodes of Android deep linking.