Page MenuHomePhabricator

Create and host assetlinks.json file. (Android 12 deeplinking support)
Closed, ResolvedPublic


Android 12 changes the default behavior of how web links are resolved by the system:

Starting in Android 12 (API level 31), a generic web intent resolves to an activity in your app only if your app is approved for the specific domain contained in that web intent. If your app isn't approved for the domain, the web intent resolves to the user's default browser app instead.

This means we'll need to set up a Digital Asset Link file that officially associates our app with the domain. (We haven't had to do this up until now, since it hasn't been mandatory in Android 11 and lower.)


We must create a file at the following location:
...that has the following contents:

  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "org.wikipedia",
  • If possible, the above file should reside at the base domain (not any specific subdomain).
  • The content-type must be application/json
  • Must not be a redirect, and must be crawlable via robots.txt

Event Timeline

Dbrant renamed this task from Support deep-linking changes in Android 12 to Create and host assetlinks.json file. (Android 12 deeplinking support).Nov 1 2021, 5:58 PM
Dbrant added a project: serviceops.

Tagging serviceops to see if they're the correct team to help with this, or please re-direct as necessary.

Hi @Dbrant,

in the mediawiki-config repo there is a path ./docroot/ For example there is a "spec.yaml" there which you can see at

There are also different types of auth files for Bing, Google and Apple in there.

So I think you could just upload this as a change into Gerrit and get some reviews and have it deployed with a deployment window.

Ahh excellent! Thanks, @Dzahn
This looks like all we need, and we'll have a patch ready soon.

Change 736042 had a related patch set uploaded (by Dbrant; author: Dbrant):

[operations/mediawiki-config@master] Add Android site association file.

Change 736042 merged by jenkins-bot:

[operations/mediawiki-config@master] Add Android site association file.

Mentioned in SAL (#wikimedia-operations) [2021-11-03T18:22:16Z] <urbanecm@deploy1002> Synchronized docroot/ 2331d061b95ba3fc4de8844008fac93ce18f9063: Add Android site association file (T294776) (duration: 01m 02s)

@Urbanecm thanks for the help with deployment. Just one follow-up question:
Would it be possible for this file to be served without redirecting to (i.e. literally from the base domain, without a 301 to

To be clear, it should work OK with the redirect, but would be even better without.

@Dbrant Thanks for asking! That's a very good question, but unfortunately not for me -- the redirect appears to happen at the cache level rather than at the MediaWiki level.

@ssingh As today SRE clinic duty, could you please answer @Dbrant's question above, or help me route it to someone who can answer it? Thanks!

Hi Traffic, the question here is.. how come we get a redirect at the caching level from bare domain to www.wikipedia and from there to en.wikipedia for the new file at:

but not for the existing file, for example at:

P.S. Actually, I do get the "" -> "" -> "" in both cases. Same for them. So it's just about all files in the bare document root.

(@Dzahn The spec.yaml file is also redirecting)

Removed traffic again because I actually found it at the apache level, not at caching level after all.

 1 <VirtualHost *:80>
 3     ServerName
 5     # Redirecting from subdirectories of to subdomains
 6     RewriteEngine On
 7     RewriteRule . - [E=RW_PROTO:%{HTTP:X-Forwarded-Proto}]
 8     RewriteCond %{ENV:RW_PROTO} !=https
 9     RewriteRule . - [E=RW_PROTO:http]
11     RewriteRule ^/([a-z]{2}|meta)/(.*)$ %{ENV:RW_PROTO}://$$2 [R=301,L,NE]
13     # Prevent the catch-all redirect below from breaking the apple-app-site-association alias
14     RewriteRule /apple-app-site-association - [L]
15     Alias /apple-app-site-association /srv/mediawiki/docroot/
17     RewriteRule ^(.*)$ %{ENV:RW_PROTO}://$1 [R=301,L]
18 </VirtualHost>

See above how the comments talk about preventing the redirect for apple-app-site-association. That seems to be the same thing just for Apple instead of Android and they also wanted this. How important is it though? Getting a special rewrite rule into that config we should only do if we really have to.

@Dzahn Thanks for finding that.

The more I look into it, the more important this seems to be for Android 12 compatibility. If we can add a similar rule for this file, that would be ideal, especially if there is already a precedent for the Apple case.
Can you point me to the repo that has this configuration? (assuming this is a patch that we can do ourselves)

@Dbrant This is in the repo operations/puppet in ./modules/mediawiki/templates/apache/sites/wwwportals.conf.erb.

Change 736595 had a related patch set uploaded (by Dbrant; author: Dbrant):

[operations/puppet@production] Create alias for Android site association file.

@Dzahn Does this kind of change get merged/deployed in the same way as other config changes? Whoops, nevermind -- I see the special puppet request windows in the deployments.

Change 736595 merged by Dzahn:

[operations/puppet@production] Create alias for Android site association file.

@Dzahn Does this kind of change get merged/deployed in the same way as other config changes? Whoops, nevermind -- I see the special puppet request windows in the deployments.

Yea, but the puppet request window is also better for smaller changes. This one touching apache-config is probably not the best example for that. Either way, it was deployed now.

deployed to prod servers (which refreshes apache on all of them) carefully via:

  • disabled puppet on mw*
  • re-enabled on canaries, then codfw, then finally eqiad
  • tested from both cumin1001 and cumin2001 with httpbb and updated tests (44 assertions vs 43) and it passed all
  • after manually re-enabling a couple by hand letting puppet do the rest and _not_ forcing puppet run on all at once, puppet deployed the rest

and Reedy then purged from cache:

19:11 Reedy: echo "" | mwscript purgeList.php enwiki

This should be resolved now.

  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "org.wikipedia",