Deep Dive Into Deep Link. Part 2. Issues: Device, OS Version
Last time we discussed the following topics:
- Introduced the main concepts: Deep Link, Web Link, Android App Link, disambiguation dialog.
- Talked about their similarities and differences.
- Explored the features of the URI format in Android.
- Described the initial task.
- Presented the Deep Link Tree.
If you haven’t read the first part yet, please read it and come back :)
Today, we will dive into two problems related to deep link functionality on different devices and Android versions. We will analyze each problem through a series of experiments (we already conducted over 280 of them).
Before diving into the problems, let’s familiarize ourselves with the experiment format. We decided to approach the investigation empirically by testing how deep links actually function in real-world conditions.
We selected seven devices: Pixel 2, Samsung A70, Samsung A7, Honor 9 Lite, Samsung Galaxy Tab A, Xiaomi Mi5.
We tested on eight versions of Android: 5.0, 6.0, 7.0, 8.0, 9.0, 10.0, 11.0, 12.0.
We considered five OS shells: One UI 2.5, Samsung Experience 9.0, One UI 3.1, EMUI 9.1.0, MIUI Global 10.2.2.0.
Additionally, we used seven applications: default SMS client, Telegram, VK, WhatsApp, Gmail, Google Search, VK Toasters.
Armed with patience, tables, and our testing process underway, we started the experimentation phase.
Let’s take a look at the table above. We have decided to describe the configuration in the form of a set of six parameters:
- Config: Configuration identifier
- Real/Emulator: Indicates whether the device is real or an emulator
- Android OS: The version of Android
- OS Shell: The operating system shell and its version
- Device: The name of the device
- App: The application from which we will be navigating using a deep link
Now let’s analyze the experiment table. It includes three test URLs: developer.android.com/about, http://developer.android.com/about, and https://developer.android.com/about, as well as two schemes: http and https.
Q: Why specifically these URLs?
A: Let’s recall the initial task: we needed deep links to resources like http://domain1.domain2.ru/landing, https://domain1.domain3.ru/path1/path2/{id}, and others. In other words, we required both http and https links with a host (the specific host is not crucial) and a path (the specific path is not crucial).
Q: So, what about developer.android.com/about (without a scheme)?
А: Such links also work! They do not include the mandatory scheme parameter, but they function properly.
Let’s now describe the procedure for conducting the experiment:
- Select a real device or emulator, the Android version, the OS shell, and the application.
2. Launch the chosen device or emulator.
3. Open the selected application.
4. Insert the three types of links (send SMS, email, etc.).
5. Configure the intent-filter within our application. Since the initial task was to implement Web Links, we chose the http and https schemes. We start with http.
<data
android:host="developer.android.com"
android:path="/about"
android:scheme="http"/> <!-- here–->6. Compile and open the application into which we inserted the links. Now, let’s start clicking :)
7. If Android prompts to open our application, mark that scenario with a plus sign. Otherwise, mark it with a minus sign.
8. HTTP scheme has been tested! Let’s repeat steps 5, 6, 7 for the HTTPS scheme.
By the way, here’s a link to the tables of all the experiments. Do not hurry to look at them in a very detailed way, there are spoilers to the following articles.
Chronology of the appearance of problems
Now you are ready! Let’s take a look at the list of issues we faced while solving the initial task:
- Different devices: Deep link handling varied across different devices.
- Different Android versions: Deep link handling differed across different Android versions.
- Different OS shells: Deep link handling varied across different Android OS shells.
- Different applications: Deep link handling differed depending on the application from which the link was opened.
- Links without a scheme: Links in the format of host/path were processed differently.
- Second host: We overlooked the presence of a second domain.
- Interception of all links: At one point, the application started intercepting all links with our domain (even those for which we didn’t have handling scenarios).
This time, we will address the first two problems, while the rest will be covered in subsequent articles. Let’s get started!
Problem №1: Different Devices
Let’s describe the conditions under which the problem occurs:
On both devices we open Gmail and send ourselves an email with the link domain1.domain2.ru/landing, and then open and click on it.
Get Valery Petrov’s stories in your inbox
Join Medium for free to get updates from this writer.
Unfortunately, expectation did not match reality. Despite opening the same link, in the same application, on the same Android version, our application was only able to be accessed by Config X-1 (Samsung A70). We formulated a hypothesis:
Hypothesis 1: Different devices
The device (hardware) affects the functioning of the Deep Link
The answer came quickly. Firstly, the devices have different shells. Secondly, Deep Link is a mechanism implemented at the software level (meaning there is no dedicated chip in the device responsible for deep link processing).
Therefore,
Hypothesis 1: Different devices — BUSTED
The device (hardware) does not affect the functioning of Deep Link
This means that in subsequent test cases, the Device configuration parameter is considered insignificant (changing it does not affect the experimental results).
Problem №2: Different Android versions
Just like last time, let’s describe the conditions under which the problem occurs:
On both devices, open the default SMS client, send a message with the link http://domain1.domain2.ru/landing to somewhere, and then click on it.
And now we get a different approach of the system to opening links, but, as in the previous case, an unsatisfactory result.
Just like last time, we are opening the same link, in the same application, but on different Android versions. This time, our application was only accessed by Config X-2 (Android 10.0).
Let’s formulate a hypothesis:
Hypothesis 2: Different Android versions
The Android OS version affects the functioning of Deep Link
To test this hypothesis, we will use major versions of Android: 5.0, 6.0, 7.0, 8.0, 9.0, 10.0, 11.0, 12.0, 13.0…
Got you! :)
Starting from 12.0, web links are not processed by the application (only Android App Link, see the previous article), so we exclude 12.0 and 13.0 from the list.
Within the scope of the hypothesis, we kept all parameters fixed except for the Android OS to track its influence on Deep Link processing. The results were ambiguous. Take a look at the tables:
Let’s focus on the most common result (sources here Config 1, Config 2, Config 3, Config 5, Config 6, Config 7):
- For the http scheme, the first and second links open in our application, but the https link does not.
- Https behaves similarly, but the https link is processed unlike the line above.
Now, let’s examine the exceptional case:
- For https, Android 8.0 showed a difference. In this case, the system prompted to open the application when clicking on the first two links (indicated by + in the previous table)
- There are no differences for the http scheme
Let’s not rush to conclusions. When conducting the experiment, it became clear that Android 8.0 behaves a bit unexpectedly, but still accomplishes the original task. The interesting thing is that the system still offers to open the application we need, but through a kind of crutch — opening the browser first.
Initially, our application is not listed, but when selecting the browser, a disambiguation dialog appears where our application is present!
If we don’t nitpick, we can say that in the end, the user was offered to open our application (with the caveat that they had to choose the browser first). Let’s adjust the tables taking this assumption into account.
Let’s return to the hypothesis. If we consider that transitioning through the browser to our application is equivalent to a direct transition to the application, then Android does not affect the processing of Deep Links. Otherwise, the conclusion would be opposite. Since we consider these transitions to be equivalent, we can conclude that:
Hypothesis 2: Different versions of Android — BUSTED
The version of the Android OS does not affect the functioning of Deep Links
This means that in subsequent test cases, the Android OS configuration parameter is considered insignificant (its variation does not affect the experimental results).
Let’s summarize the results
Today we have examined two out of the seven problems encountered while solving the original task.
The first problem: Deep Links are handled differently on different devices. Does this mean that the hardware components of the device can influence the processing? No. Deep Links are implemented at the software level (there is no specific chip responsible for Deep Link processing).
Hypothesis 1: Different devices — BUSTED
The device (hardware) does not affect the functioning of Deep Links
The second problem was that Deep Links were not always processed as expected on different versions of Android (take another look at the screen recordings). Initially, we were unable to access the application on Android 8.0. However, after selecting the browser, a disambiguation dialog appeared with our application. Some may argue that there was no direct transition to the application (which is valid). However, we believe that it exists (even if it requires the user to make an additional click).
Hypothesis 2: Different versions of Android — BUSTED
The version of the Android OS does not affect the functioning of Deep Links
Congratulations! You’ve done a great job twice! The second part of the journey is behind us, but the real challenges lie ahead. How do you feel? Let us know in the comments if you expected these outcomes for the first and second hypotheses.
Next time, we will address two more problems and draw conclusions regarding the hypotheses:
Hypothesis 3: Different OS shells
The Android OS shell influences the functioning of Deep Link
Hypothesis 4: Application
The application from which the link is opened influences the functioning of Deep Links
See you in Part 3!
