I am working on setting up my Android app to work with HTTP Web Links according to the various guides and protocols and have successfully setup the deeplinks which includes serving my assetlinks file from /.well-known/assetlinks.json. Everything is working as expected. What I am struggling with from an operational perspective is how to go about maintaining this file -- specifically during update and failure scenarios.
Let's say I have existing customers who have downloaded my app and are using weblinks just fine. I update my assetlink file and push the new version to my server. When do my customers get the updated assetlink file? Is the OS configured to check for updates on some cadence or app launch? Is it only on app update or reinstall?
Similarly, imagine my website is down. New users are installing my app and the OS will not be able to associate my domain and when customers click the HTTP web links they will not be deeplinked into the app. This makes sense. But after I recover from my outage when will the customer get their assetlink file given the app is already installed?
Similarly lets say I upload an invalid assetlinks.json file. Will this break the current web links for existing customers who already had a valid association when they first installed the app?
Understanding these issues will ultimately help me better troubleshoot customer issues and tune the expected traffic I should expect to see for my assetlinks file from my server.
Let me try to briefly put down how app linking works. I'm listing down all the things which I have learned gathered while playing with app links. Also attaching a very good article which covers in more details about the following.
There are two key components in registering and updating app links: Package manager and Intent Filter Verifier. These are the usual steps in which the workflow runs:
Every time an app is installed or updated through the package manager an intent named INTENT_FILTER_NEEDS_VERIFICATION is generated.
The Intent Filter Verifier looks up the domains specified in the tags defined in the manifest of your app.
For every domain/hostname specified for the app, the IntentFilterVerfier tries to fetch statements for each of the domain using an API call.
Based on the result of the API call, the domain/hostname is categorized into one of the following buckets
undefined — apps which do not have link auto-verification enabled in their manifest
ask — apps which have failed verification (i.e. ask the user via the "Open with" dialog)
always — apps which have passed verification (i.e. always open this app for these domains)
never — apps which have passed verification, but have been disabled in the system settings
Package Manager updates and applies the behavior.
Failure handling
If any of the domains' fetch statements returns an invalid response, it will affect all your existing app links.
In the case statement fetch failure occurs due to connectivity, Android will retry to fetch the statements. Although it is not mentioned anywhere in the documentation what will be the retry policy, we can safely assume that it is done through JobScheduler and will be linear retry.
If you are planning to make the changes to the domain properties, you need to return a Cache-Control key in your statements JSON.
You can get more information and debug workflows in this very well written Blog by Christopher Orr