[MUSIC PLAYING]
SPEAKER: In this video, you will use command line tools,
such as the Android Debug Bridge and curl,
to diagnose and debug common problems with Android app
links.
In previous videos, you were introduced to deep links,
shown their use cases, and walked through setting them up.
In this video, I will cover some common problems
you can face while creating Android app links,
how to detect them, and how to solve them.
The Play Console Deep Links page gives developers a single place
to view and resolve many common issues with app links.
The Deep Links page contains an analysis
of your app and deep links so you can quickly identify issues
at a glance.
With the console, you get domain validation, glanceable issue
reports, and code snippets to help resolve app link issues.
After being notified of an issue in Play Console,
you can follow these steps to quickly verify
your improvements of Android app links.
This video will show some command line tools
to debug your Android app links before your next upload
to the Play Console.
As a reminder, Android app links are
web links that are verified by your website
to belong to your app.
To get this verification, you need
to both add a specific intent filter definition in your app's
manifest file and publish an assetlinks.json
file to your domain that appears in your Android app links.
When a user navigates to one of your Android app links,
it's opened automatically in your app, not a browser.
This video will continue with the Droid Food application from
the previous video, which handles the links,
droidfood.example.com/list list and droidfood.example.com/menu.
You will use the Android Debug Bridge and commands
available in Android 12 to test and verify
the links' configurations.
Let's get started.
Droid Food's Android app links are
configured in its AndroidManifest.xml file.
Before you begin debugging, you should
check that these filters have all criteria for an Android app
link.
Each link requires the attribute, autoVerify equals
true, an action element with the name attribute set
to action.VIEW, a category element with the name attribute
set to DEFAULT, a second category element with the name
attribute set to BROWSABLE, at least one data element
with a scheme attribute of HTTP or HTTPS,
and a host attribute which matches the domain associated
with your deep links.
Let's switch to the terminal and test the application using
the Android Debug Bridge.
Use adb shell am start to check that the application can
handle a deep link which is explicitly sent to it.
The command tells the application
to open the URL, droidfood.example.com.
Our application opens the link correctly.
When a user clicks on a link, the system
launches an implicit intent and finds the default handler
for our deep link.
Removing the package name from the previous command
allows you to test which Android activity chooses
to handle the implicit intent.
The web browser has handled the request instead of the app,
so you will need to debug this further.
Our app can open links, but the Android operating system
isn't using the app to open links.
One reason this may happen is if the link's domains
aren't verified.
You can use the command, adb shell pm get-app-links,
to check out the verification status of domains
from the Android Package Manager in Android 12.
The domain, droidfood.example.com,
returns a legacy failure error.
This value should be verified.
It means that there is something wrong with our link's
configuration.
By default, Android will only use our application
to open a link if it is verified.
Android uses the Digital Asset Links
API to establish trust between a host and an app.
In practice, this means that each web host corresponding
to an app's intent filters in AndroidManifest.xml serves
an assetlinks.json file in the host's .well-known/ top-level
directory.
The assetlinks.json file for https://droidfood.example.com
references the key, beginning with 4C:D7.
But the sign-in key from pm get-app-links
does not match this.
We will need to replace it with the correct key.
We have updated and re-uploaded our assetlinks.json file.
We will use two adb commands to verify
that the file is correct now.
adb shell pm verify-app-links re-verify com.example.droidfood
will perform verification on the file.
adb shell pm get-app-links com.example.droidfood
will show us the verification status.
Our links are now successfully verified.
In this case, our assetlinks.json file
was using the wrong key.
But there may have been other problems,
and I will show you how to check for those.
Hosting for assetlinks.json must meet several criteria.
The host must serve the file using a secure HTTPS
connection.
Redirects may not be used to access the assetlinks.json
file.
The "Content-Type" HTTP header of the file must be
application/json.
And finally, assetlinks.json must be served publicly
and cannot be behind authentication or a VPN.
We can check each of these with the curl command.
First, confirm that the file is hosted using HTTPS,
using curl as shown to load the file with an HTTPS scheme.
If there is a connection error, this
means that your file is most likely not hosted correctly.
To confirm that the file is not hosted with a redirect,
examine the headers returned by curl.
Redirects are identified by an HTTP status
code in the 300 range.
For instance, a 302, as shown here,
means that the file has been moved.
This redirect will cause verification to fail.
The content header returned by the server hosting
the assetlinks.json file must be of the type application/json.
If your header is not application/json,
your file will fail verification.
Corporate networks are often behind VPNs which host content
not available for the public.
If your file is hosted on a VPN, then
links that verify in testing at your office
won't work for your users.
Use a public network without a VPN connection
to test that assetlinks.json is available from there.
Finally, let's review the disambiguation dialog,
which is shown when multiple installed applications can
handle a deep link, and there is not an application
selected as a default handler.
Beginning in Android 12, any intent filter
for a web link that passes validation
with the assetlinks.json file will be the default handler
for the deep link, and the disambiguation dialog
will not appear.
Before Android 12, however, if any intent filter
failed validation, then all deep links
your app supports will trigger the disambiguation dialog.
It is very important to validate your links with the command,
adb shell pm get-app-links.
If you have multiple intent filters that
can handle the same deep link, this
can cause the disambiguation dialog to appear.
Verify your intent filters do not
have overlapping deep links by testing
your links using the adb shell am start command from earlier.
It is also possible for the user to select
a different application to be the default link handler.
If your app detects that it's not the default link
handler for its links, you should prompt the user
to update their settings so your application can
handle its own deep links.
You can find more information and a code sample
for detecting default link handlers
on developer.android.com.
After you complete these steps, you
can be more confident that users will navigate directly
to your app without seeing the disambiguation dialog.
We hope that you have learned some useful techniques
for solving common problems with deep links in Android.
To see other content about deep links,
check out the Deep Links Videos series crash
course playlist in the Android Developer channel on YouTube.
If you found this video helpful, please leave
like or a comment below.
Thank you for watching.