This doc summarizes the total feedback we’ve heard and things we’ve learned so far from running an Origin Trial for GetInstalledRelatedApps (“InstalledApp”).
GetInstalledRelatedApps’ Origin Trial started in Chrome 59 and Chrome 63 is the last release in which the Origin Trial will be available.
Intent to experiment: https://groups.google.com/a/chromium.org/d/msg/blink-dev/j-e8iI-WWg8/OjoJbm_zCgAJ
Intent to extend origin trial:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CYbJ-2cNc5w/_pEgwCm-BAAJ
Note: Trial was extended due to the addition of a new feature, Android Instant Apps detection.
Previous result summary:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/0R7zbrVdhds/UaqgHdEbAgAJ
mgi...@chromium.org, owe...@chromium.org
https://github.com/WICG/get-installed-related-apps/blob/master/EXPLAINER.md
https://www.chromestatus.com/features/5695378309513216
As of 2017-09-21, 66 origins have registered for access to the origin trial. Tokens were renewed 6 times for this feature. (That’s 25 more total signups, and 4 more renewals, than at the previous milestone.)
We received the following feedback (NB: all of this feedback came from a single developer):
Positive:
The API is simple.
Negative:
Want debug info as to why no apps were returned (possibly as an API).
We are unlikely to provide this as an API, as it would mean leaking information to the developer about the user’s system. Most of the reasons an installed app isn’t returned is because of privacy (e.g., the app does not reference the site in its Digital Asset Links).
However, we could conceptually have a verbose flag that logs the state of each app listed in the manifest to the console, similar to the --bypass-site-engagement-checks flag which does the same for install prompts. This future change does not affect the API surface.
Want the app version and “app hash” (not sure what this would be; perhaps a hash of the APK) returned, so you can see what version of the app is installed.
This could potentially be added in the future without breaking existing users.
This would present an additional privacy risk, and it is not clear that the benefits outweigh the risks.
Want to be able to call the API from within a service worker. (Otherwise, individual notifications can’t be suppressed.)
This could potentially be added in the future without breaking existing users. However, the API may not be very useful in its current form.
The Android app Digital Asset Links “target.site” URL doesn’t allow wildcards (makes it harder to develop on sandboxes that generate random domains).
This is out of scope, as it’s an issue with Android Digital Asset Links spec (https://developers.google.com/digital-asset-links/v1/statements), not the web API.
Want the API to use the web-to-app relationship defined in “.well-known/assetlinks.json”, instead of the manifest (https://github.com/WICG/get-installed-related-apps/issues/4).
Marked as WontFix. That file is proprietary to the Android platform, and we are specifying this in a W3C standard. We are purposely duplicating the web-to-native part of Android’s Digital Asset Links in the Web App Manifest in order to be platform neutral. See the bug.
None of these issues block the launch of the API.
Determine whether the API design is ergonomic
It seems fine, aside from the above complaint that we are requiring sites to duplicate the Android Digital Asset Links metadata. As discussed, this is by design.
Determine whether the API solves the notification de-duplication issue
It seems that it does not solve this issue properly (needs to be implemented in Service Worker).
In the renewal form, we also asked some additional questions:
Do you need to be able to use getInstalledRelatedApps from a Service Worker (or Web Worker)? [Note that this is not currently possible.]
Three respondents (including the one who gave all of the above feedback) ticked “Yes”.
How many native Android apps do you intend to list as related_applications for your site?
The highest chosen was “3-10”. Most listed “1”.
Why do you intend to use getInstalledRelatedApps? [Choose from a list]
1 response: “De-duplicating notifications”.
1 response: “Android Instant Apps holdback test”.
Past:
2017-06-06: M59 (first stable release).
2017-08-01: M60 stable release.
2017-08-08: Feedback from M59 origin trial.
2017-09-12: M61 stable release.
2017-09-21: Feedback from M60 origin trial (this email).
Future:
2017-10-24: M62 in stable channel.
2017-10-31: Feedback from M61 origin trial.
2017-12-12: M63 in stable channel.
2017-12-19: Feedback from M62 origin trial.
2018-01-30: M64 in stable channel. Experiment ends.
2018-02-06: Feedback from M63 origin trial.
The following metrics come from UMA and (NOT adjusted for UMA opt in rates), since 2017-08-08:
The `getInstalledRelatedApps` method was called 909 times, an average of 27.5 times per day.
Interesting data points:
Large spike on 2017-08-22 (356 calls).