It looks like iOS already assigns a UA to the request (woot), but it doesn't look like it is using the same value that Chrome would use to make the request (I think).

It's going to be difficult to get the correct UA string on Android for the same reasons we didn't use Chrome's network stack in the first place.  The GetUserAgent() method is in the native layer so we'd need a JNI call to grab it.  We don't want to use any JNI methods to show notifications because it would require loading all of Chrome to do background scanning.

I think reverse engineering it to get close enough would work also.  Perhaps we can just get the version of Chrome without crossing the JNI bridge and the rest is a hardcoded string?

Here's a proper Clank UA string (from M50):

Mozilla/5.0 (Linux; Android 5.1.1; Nexus 4 Build/LMY48T) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.89 Mobile Safari/537.36

I was able to reconstruct most of it correctly without JNI:

Mozilla/5.0 (Linux; Android 5.1.1; Nexus 4 Build/LMY48T) AppleWebKit/0.0 (KHTML, like Gecko) Chrome/52.0.2726.0 Mobile Safari/0.0

The "0.0"s are for the WebKit version, which doesn't appear to be cached anywhere in the Java layer.  It's not important to us so we could leave it as 0.0 or omit it.  We could also hard code 537.36 since apparently the value hasn't changed since ~M27:

http://useragentstring.com/pages/Chrome/

Any preference?  I'd prefer to leave it as 0.0 so it's clear we have no intention to update it.

That's totally awesome!

How much of that is hard coded?  Assuming Android version and Chrome
version are real numbers, and the rest is a fixed string?  I'm fine with
0.0.

Great work!

It's filling in:

Android version (5.1.1)
Device model (Nexus 4)
Build ID (LMY48T)
Chrome version (52.0.2726.0)

The rest of the pattern is hard-coded:

Mozilla/5.0 (Linux; Android %s; %s Build/%s) AppleWebKit/0.0 (KHTML, like Gecko) Chrome/%s Mobile Safari/0.0

 Issue 603222  has been merged into this issue.

Chrome for iOS recently (M48) switched from UIWebView to WKWebView.  WKWebView doesn't support adding HTTP request headers so Chrome for iOS uses the default values for Accept-Language based on the user's locale settings.  This value depends on the user's locale (language and region settings).  It's easy to get the locale settings but the mapping to Accept-Language strings isn't straightforward and I haven't found a way to grab these values directly.  (eg, English + Canada will set Accept-Language to en_ca, but English + India sets it to en_us)

I think we should just pass the language for now ("en" instead of "en_us") since in most cases the metadata will be the same for locales that only differ by region.

Seems reasonable.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6bf0bb56d7536accdddeaf0429de7e619953e367

commit 6bf0bb56d7536accdddeaf0429de7e619953e367
Author: mattreynolds <mattreynolds@chromium.org>
Date: Mon Jun 06 21:00:18 2016

Set User-Agent and Accept-Language request headers for PWS requests

The HTTP request headers normally used by Chrome for Android are
generated in the native layer. We do not want to load native when the
Physical Web is resolving URLs in the background, so we cannot access
these values directly. Instead, they are reconstructed from values
accessible from the Java layer.

BUG= 607660 

Review-Url: https://codereview.chromium.org/1989963003
Cr-Commit-Position: refs/heads/master@{#398120}

[modify] https://crrev.com/6bf0bb56d7536accdddeaf0429de7e619953e367/chrome/android/BUILD.gn
[modify] https://crrev.com/6bf0bb56d7536accdddeaf0429de7e619953e367/chrome/android/java/src/org/chromium/chrome/browser/physicalweb/BitmapHttpRequest.java
[modify] https://crrev.com/6bf0bb56d7536accdddeaf0429de7e619953e367/chrome/android/java/src/org/chromium/chrome/browser/physicalweb/HttpRequest.java
[modify] https://crrev.com/6bf0bb56d7536accdddeaf0429de7e619953e367/chrome/android/java/src/org/chromium/chrome/browser/physicalweb/JsonObjectHttpRequest.java
[modify] https://crrev.com/6bf0bb56d7536accdddeaf0429de7e619953e367/chrome/android/java/src/org/chromium/chrome/browser/physicalweb/ListUrlsActivity.java
[modify] https://crrev.com/6bf0bb56d7536accdddeaf0429de7e619953e367/chrome/android/java/src/org/chromium/chrome/browser/physicalweb/PwsClientImpl.java
[modify] https://crrev.com/6bf0bb56d7536accdddeaf0429de7e619953e367/chrome/android/java/src/org/chromium/chrome/browser/physicalweb/UrlManager.java
[modify] https://crrev.com/6bf0bb56d7536accdddeaf0429de7e619953e367/chrome/android/java_sources.gni
[add] https://crrev.com/6bf0bb56d7536accdddeaf0429de7e619953e367/chrome/android/javatests/src/org/chromium/chrome/browser/physicalweb/PwsClientImplTest.java
[modify] https://crrev.com/6bf0bb56d7536accdddeaf0429de7e619953e367/chrome/browser/android/preferences/pref_service_bridge.cc
[modify] https://crrev.com/6bf0bb56d7536accdddeaf0429de7e619953e367/components/components_locale_settings.grd
[modify] https://crrev.com/6bf0bb56d7536accdddeaf0429de7e619953e367/components/strings/BUILD.gn

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b6c861975caa530967100d68329e1d7cb520c194

commit b6c861975caa530967100d68329e1d7cb520c194
Author: mattreynolds <mattreynolds@chromium.org>
Date: Fri Jun 10 09:13:26 2016

Set the Accept-Language header in Physical Web requests

The Physical Web service now supports locale-specific
metadata caching.  To receive metadata specific to the
user's locale, attach the language code for the current
system locale to the metadata request.

BUG= 607660 

Review-Url: https://codereview.chromium.org/2042863002
Cr-Commit-Position: refs/heads/master@{#399140}

[modify] https://crrev.com/b6c861975caa530967100d68329e1d7cb520c194/ios/chrome/common/physical_web/physical_web_request.mm

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b6c861975caa530967100d68329e1d7cb520c194

commit b6c861975caa530967100d68329e1d7cb520c194
Author: mattreynolds <mattreynolds@chromium.org>
Date: Fri Jun 10 09:13:26 2016

Set the Accept-Language header in Physical Web requests

The Physical Web service now supports locale-specific
metadata caching.  To receive metadata specific to the
user's locale, attach the language code for the current
system locale to the metadata request.

BUG= 607660 

Review-Url: https://codereview.chromium.org/2042863002
Cr-Commit-Position: refs/heads/master@{#399140}

[modify] https://crrev.com/b6c861975caa530967100d68329e1d7cb520c194/ios/chrome/common/physical_web/physical_web_request.mm