I don't think we were aware that this had ever worked. Is this documented as being supported by Android anywhere? Android does not generally use Java system properties for anything.

There should not be any difference with the webview provided by chrome vs the standalone webview here - the exact same code is used in both cases and all behaviour should always be identical - so it sounds like you just mean this is broken in version 67, but works in 66, and this should apply to both.

If this did actually used to work and it regressed in webview we should probably fix it, but this is another data point for needing a real API to set the proxy as in internal bug b/80326334

Without digging too deeply into the code, it looks like Chrome might actually use this:

https://cs.chromium.org/chromium/src/net/android/java/src/org/chromium/net/ProxyChangeListener.java?type=cs&q=System%5C.getProperty
https://cs.chromium.org/chromium/src/net/proxy_resolution/proxy_config_service_android.cc?q=case:yes+%5CbproxyHost%5Cb

Passing to network component to check what the intended behavior is.

Can anyone with webview expertise comment?

It doesn't look like that code has changed in a long time, so I am guessing the problem here is due to a change in how WebView is run.

It looks like both System.getProperty() and the android specific proxy settings properties are being checked on Android, with preference given to the latter.

I presume that System.setProperty() affects only the current JVM. Could the difference be that network portion of WebView was previously hosted in the same java instance, whereas now it is hosted in a separate process and hence does not see any changes to System.properties?

AFAICT, System.setProperty() applies only to the current JVM instance. So if webview is backed by Chrome

re #c1, that internal bug should be publicly visible at https://issuetracker.google.com/issues/80326334

+1 to what torne@ said.  I think Chromium uses the proxy System properties as a way to infer what proxy Android has set, but not as a supported and intentional way for apps to override Android's proxy settings.  I think the more supported way to change the proxy settings would be via java.net.ProxySelector.setDefault() but AFAIK I don't think Chromium has ever supported that.

Can you instead use android.webkit.WebViewClient.shouldInterceptRequest() to proxy the HTTP traffic as you desire?

I don't think there is any actually supported way to set application level proxy settings on Android in general, alas.

shouldInterceptRequest can't really be used to proxy requests in general - it only allows you to replace the response with your own response, which would require you to use your own network stack to make the actual request (and there's a bunch of limitations, like not being able to see POST bodies).

As Nate linked to in #4 we are considering adding an actual supported API for this in future, but we should still check if this workaround method actually used to work reliably and regressed, and if so consider fixing it since it's possible a number of apps depend on it..

chauhan.deepti24@, what was the last WebView version where this worked? The narrower a range you can give us, the better.

Even better, can you supply an APK configured to use a proxy like this, which we can use to check whether the proxy is working or not? Or can you give us access to the proxy you're using?

Otherwise, testing this is going to be difficult for us. I guess someone could run a local proxy and connect an emulator to it?

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

We are able to replicate the issue only when chrome version 67 is installed on device. The issue is not observed on chrome version 66 or below. It works well on all versions of webview if chrome is disabled. 
I have attached following files:
1) WebViewIssue.apk : This is the apk in which issue is replicable. The proxy is hardcoded as "localhost" and port 10000 in this apk. Also, by deafult "www.google.com" is hardcoded as default url for webview to load.Hence, when app is opened , it will open google website in case proxy is not applied. Otherwise, we will get error page saying "ERR_PROXY_CONNECTION_FAILED". 
2) MainActivity.java: Source code for MainActivity in above apk.

Also note, we did not setup any proxy server while testing above app as we just need to observe that webview is trying to send traffic to proxy. As in our case proxy server does not exist, it will just show error screen with above message hence proving whether proxy is being respected or not.

Hence to be able to replicate the issue follow these steps:
1) Install WebViewIssue.apk on the device
2) Upgrade chrome to version 67.
3) Now when this apk is run, since proxy is already set, ideally we should get error screen as mentioned above. But in this case we won't get error screen. Hence, we can conclude that proxy is not respected when chrome based webview is used.

Now downgrade chrome or disable it, and follow these steps:
1) Install WebViewIssue.apk.
2) When app is opened, we will get error screen with proxy connection failed error. This is expected behavior as webview is respecting proxy in this case and as it could not find the proxy server, it gave us an error screen.

Deleted: MainActivity.java 4.9 KB

MainActivity.java 4.9 KB View Download

This is the apk I have referred to in my previous comment

Deleted: WebViewIssue.apk 1.5 MB

WebViewIssue.apk 1.5 MB Download

Test team, can you verify if this actually behaves differently with webview vs monochrome at the same version? If so that's a very strange issue we need to investigate, because differences between monochrome and webview aren't supposed to happen.

Also, if it indeed repros with Monochrome 67 and not 66, can the test team please bisect?

We (test team) will check and update the bug.

chauhan.deepti24@, Is this issue specific to 

Device name: Samsung Galaxy Tab A
Android version:7.1.1

or any samsung tablet we will be see this issue

It is replicable for our customer on following devices:
1) Redmi Note 4 - OS 7
2) Samsung SM-T819 - OS 7
3) samsung SM-G955W - OS 8
4) Pixel C and Pixel 2 - OS 8

Also, issue should be replicable on any device which has OS version >=7 and chrome version 67.

https://chromium.googlesource.com/chromium/src/+log/67.0.3376.0..67.0.3377.0?pretty=fuller&n=10000

67.0.3376.0 - Good
67.0.3377.0 - Bad

we are working at per-cl-bisect, will update 

Hi
Any update on this issue?

Hello,

I confirm that this way to set proxy to the webview is used by many apps, including mine. My customers started to complain few days ago, and happen on any Android 7.X+ with the latest Chrome release.

Is there any workaround that can be implemented while the issue is fixed ?

Unfortunately I don't think there's any good workaround.

Thank you for your response.
I see that the status of the task is still Unconfirmed. Do you know if it's planned to fix the the issue and in which delays ?

My apps are currently not working anymore for many users that have enabled automatic updates and they cannot downgrade Chrome on their phones.

We can't guarantee when it'll be fixed. It's too late to fix in version 67 but we may be able to fix it in 68.

Dheenu, can you confirm that this definitely regressed in both WebView and Monochrome and isn't actually dependent on whether the device uses monochrome or not?

Also, Nate, re #4: Android issuetracker bugs don't actually appear to be public; they're only viewable by the reporter as far as I can tell? At least, that one...

> Android issuetracker bugs don't actually appear to be public; they're only viewable by the reporter as far as I can tell? At least, that one...

I think it depends on the bug. For example, I see public (anyone with a google/gmail account) access for https://issuetracker.google.com/issues/36991047

ping; it'd be really helpful to establish whether this is actually different in monochrome vs standalone webview :)

torne@, I'm working on it will update in a while, thanks

torne@ 

Looks like i see this issue only on monochrome builds, 

used the same "67.0.3377.0" webview build cannot repro this issue.

Now i wonder why I'm not able to get cl-bisect 

You mean, you can't bisect, and you don't know why you can't bisect? Or you wonder what the bug is, because you can't bisect? What sort of problem did you encounter when bisecting?

If it only reproduces in Monochrome per c28, then we can't per-cl bisect using the archived builds since the monochrome builds are not archived.

Can't reproduce this on ToT - it works fine in monochrome.

Oh, I see the issue. The problem isn't anything to do with System.setProperty - those properties aren't even being set until after we already read them the first time. The issue is that the code is trying to find our proxy change broadcast receiver via reflection to dig into the framework internals, and is assuming that it will be in a class called ProxyChangeListener. Monochrome is proguarded with obfuscation, so the class may not be called that.

It worked on my local build because I have proguard disabled. :)

We don't appear to have proguard obfuscation turned on for WebView - that's probably a bug, there's no reason why WebView should be treated differently. So, the actual surprise here is that it should be broken on *both*, and it only works in webview by accident.

This reflection code is just bad. Assuming class names inside the webview APK is not a reasonable way to do anything. But: it looks like this case might be quite common in the wild, which sucks.

So we need to decide whether we add a proguard directive to keep this class name or not, basically. :(

I'm just going to mark the relevant classes/methods @UsedByReflection so that proguard won't mangle them; the cost is pretty low (we aren't likely to restructure this code significantly as it implements a system interface, so there's not many degrees of freedom). This will work for webview in future as well if we enable obfuscation there.

Probably not going to merge this to M68 though as this isn't something that is supported or a good idea to actually do.

Hi
I understand that setting a proxy on WebView like this is not a good idea, but unfortunately we have an app that relies on this and hence is broken for all our customers. Since this was working in the previous Chrome version and also works for Android System WebView, I would request that the fix be added to Chrome as early as possible.
If this approach is going to be stopped, we should get some time before it's actually stopped so that we can figure out some alternate approach for our app. But as of now, our production app (155k active users, 65% on Android 7 and above) is broken on Android 7+ devices, and this fix is extremely critical for us.

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

commit 0f71a543910198ee5b4104ea0066494a3fcba309
Author: Torne (Richard Coles) <torne@google.com>
Date: Tue Jun 26 19:00:44 2018

Mark ProxyChangeListener as @UsedByReflection.

A number of WebView applications in the wild use reflection to call the
proxy change broadcast receiver directly as a hack to allow them to set
an application-local proxy setting. The reflection code used searches
for ProxyChangeListener by name, so fails with proguard obfuscation
enabled for the monochrome APK. Mark the relevant classes/methods as
@UsedByReflection to ensure they don't get renamed, because while it's
not good that applications do this, there is no supported API to achieve
the same thing either, and it appears to be a commonly repeated piece of
code.

Bug:  851995 
Change-Id: I6174181491f57fd71fece91c98ae8b96f36b425f
Reviewed-on: https://chromium-review.googlesource.com/1112564
Reviewed-by: Paul Jensen <pauljensen@chromium.org>
Commit-Queue: Richard Coles <torne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#570479}
[modify] https://crrev.com/0f71a543910198ee5b4104ea0066494a3fcba309/net/android/java/src/org/chromium/net/ProxyChangeListener.java

Estelle, is it reasonable to merge this to 68? It's low risk (it's just telling proguard not to rename some code, no actual code changes) but it's to fix a weird and unsupported abuse of our internals via reflection :|

This bug requires manual review: M68 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Yes! it is reasonable to merge it! 

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

commit c339320be9ea823e5a7db5a747deb5a5fb593016
Author: Torne (Richard Coles) <torne@google.com>
Date: Wed Jun 27 19:26:41 2018

Mark ProxyChangeListener as @UsedByReflection.

A number of WebView applications in the wild use reflection to call the
proxy change broadcast receiver directly as a hack to allow them to set
an application-local proxy setting. The reflection code used searches
for ProxyChangeListener by name, so fails with proguard obfuscation
enabled for the monochrome APK. Mark the relevant classes/methods as
@UsedByReflection to ensure they don't get renamed, because while it's
not good that applications do this, there is no supported API to achieve
the same thing either, and it appears to be a commonly repeated piece of
code.

TBR=torne@google.com

(cherry picked from commit 0f71a543910198ee5b4104ea0066494a3fcba309)

Bug:  851995 
Change-Id: I6174181491f57fd71fece91c98ae8b96f36b425f
Reviewed-on: https://chromium-review.googlesource.com/1112564
Reviewed-by: Paul Jensen <pauljensen@chromium.org>
Commit-Queue: Richard Coles <torne@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#570479}
Reviewed-on: https://chromium-review.googlesource.com/1117331
Reviewed-by: Richard Coles <torne@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#554}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/c339320be9ea823e5a7db5a747deb5a5fb593016/net/android/java/src/org/chromium/net/ProxyChangeListener.java

Thanks for the help guys.
Just wanted to know the approximate date when v68 will be available in the Chrome stable channel?
We need to communicate that to our customers.

Also when would this be available in the Chrome beta app on the Play Store?

Release dates can be found here: https://www.chromium.org/developers/calendar

You can see in the OmahaProxy section that Android beta is currently on 68.0.3440.33. The merge to 68 landed in 68.0.3440.45.

I see that Chrome stable would upgrade to v68 on July 24th.
Can you tell me when Chrome Beta would be upgraded to build 68.0.3440.45?
Right now I see the Chrome beta is on 68.0.3440.40

We also faced this issue in our Browser which is based on WebView where release version of the Browser works fine as expected but not the debug version of the Browser. We found that by removing WebView.setWebContentsDebuggingEnabled(true) in our code, the debug version of the Browser worked as expected. All this is seen in Chrome 67 and not in the previous version.

Some history. These StackOverflow posts have code samples that show how Android developers have been setting proxy on the WebView from 2010 - 

https://stackoverflow.com/questions/4488338/webview-android-proxy

https://stackoverflow.com/questions/19979578/android-webview-set-proxy-programatically-kitkat

First of all, thanks for the OP by chauhan....@gmail.com.

We have the solution based on the same approach and we have about 10 M users monthly using our service today. Combining both Android 7 & 8 penetrations, we estimate over 1 M of our users are impacted by this issue on daily basis. We are very desperate for any fix or workaround as soon as possible. We see that the Chromium build 68 (with fix) is coming out on July 24, 2018. But we are looking for:
1. What is beta availability date for 68 (with the fix)?
2. Any possibility to expedite the release date
3. Can we get a build for our lab testing or build instructions to build the chromium ourself for internal testing?
Any response on these is greatly appreciated.

1) Beta releases are weekly, so I would expect to see this available approximately midweek next week, if it's not in this week's beta.
2) No, the stable release timeline can't be changed.
3) On an N+ device you can install Chrome Dev (currently 69.0.3475.0, which contains the fix) and select it as the webview provider in developer settings.

Thanks tobiasjs@chromium.org for the quick reply.
We can verify that the Chrome Dev (69.0.3475.0) works perfectly and our solutions works

I also hit this in our app. Yes, we use reflection to find the ProxyChangeListener to invoke it to set the http proxy for the webview in our app. If there was a proper API to set the http proxy in our app's webview, I would love to use that and throw away the reflection, because it is an ugly hack.

I built a workaround in our app, so that we don't need to wait for v68. For this workaround, if we don't find the ProxyChangeListener class during reflection, we look for other classes that look like they may have been renamed by Proguard - the full class name is 4 characters or less. Then we use that class in place of ProxyChangeListener. Today we find two classes via reflection with short names, "bMh" and "bMw". We invoke them both. Through trial and error, it appears that "bMh" is the Proguard-renamed ProxyChangeListener. We aren't seeing any ill effect in also invoking "bMw", I assume it ignores the Proxy.PROXY_CHANGE_ACTION intent.

Yes, this makes an ugly hack even worse. But without a proper API, we don't have much choice.

Here is my original ticket I opened against Android, and was pointed to this Chromium ticket: https://issuetracker.google.com/issues/111201650

Verified the fix on webview: on M68/ 68.0.3440.57 and M69/69.0.3487.0

Pixel XL/P and LG V30/N2G4H


 chauhan.deepti24@, Can you please verify this issue is fixed when the build are availabe on play store and mark it verified, Thanks

Just wanted to confirm if the stable release is still as per schedule ?

Thanks

yep

With Android P imposing restrictions on using reflection for Android SDK classes, relying on reflection for a major feature like this is prone to breakage in future. A public API to set proxy on the WebView is required urgently. 

@Chromium team - What should be done to expedite this? Will a new ticket help? Or is there any existing one?

Android P restrictions on reflection - https://developer.android.com/preview/restrictions-non-sdk-interfaces

This API is currently greylisted due to the existing usage in the wild, and so there are no current restrictions on calling it via reflection. It won't be removed from the greylist until there is a supported API to replace it. We are working on this already; there is no need to do anything to expedite this.

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

commit 74732cc5bd751944f978ea1ff40f10cde31f2100
Author: Laís Minchillo <laisminchillo@chromium.org>
Date: Thu Aug 09 10:51:37 2018

Add support library support for Override Proxy API

Static WebView methods are implemented using the class
WebViewFactoryProvider.Statics, in this CL we implement the
corresponding class for the WebView support library.

Bug:  851995 
Change-Id: I2f9ed164d3b468acf77feaff4b0f192724ff511e
Reviewed-on: https://chromium-review.googlesource.com/1148384
Commit-Queue: Laís Minchillo <laisminchillo@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581856}
[modify] https://crrev.com/74732cc5bd751944f978ea1ff40f10cde31f2100/android_webview/browser/aw_browser_context.cc
[modify] https://crrev.com/74732cc5bd751944f978ea1ff40f10cde31f2100/android_webview/browser/aw_contents_statics.cc
[modify] https://crrev.com/74732cc5bd751944f978ea1ff40f10cde31f2100/android_webview/browser/net/aw_url_request_context_getter.cc
[modify] https://crrev.com/74732cc5bd751944f978ea1ff40f10cde31f2100/android_webview/browser/net/aw_url_request_context_getter.h
[modify] https://crrev.com/74732cc5bd751944f978ea1ff40f10cde31f2100/android_webview/browser/net/aw_url_request_context_getter_unittest.cc
[modify] https://crrev.com/74732cc5bd751944f978ea1ff40f10cde31f2100/android_webview/glue/java/src/com/android/webview/chromium/SharedStatics.java
[modify] https://crrev.com/74732cc5bd751944f978ea1ff40f10cde31f2100/android_webview/java/src/org/chromium/android_webview/AwContentsStatics.java
[modify] https://crrev.com/74732cc5bd751944f978ea1ff40f10cde31f2100/android_webview/support_library/boundary_interfaces/src/org/chromium/support_lib_boundary/StaticsBoundaryInterface.java
[modify] https://crrev.com/74732cc5bd751944f978ea1ff40f10cde31f2100/android_webview/support_library/boundary_interfaces/src/org/chromium/support_lib_boundary/util/Features.java
[modify] https://crrev.com/74732cc5bd751944f978ea1ff40f10cde31f2100/android_webview/support_library/java/src/org/chromium/support_lib_glue/SupportLibWebViewChromiumFactory.java
[modify] https://crrev.com/74732cc5bd751944f978ea1ff40f10cde31f2100/net/proxy_resolution/proxy_config_service_android.cc
[modify] https://crrev.com/74732cc5bd751944f978ea1ff40f10cde31f2100/net/proxy_resolution/proxy_config_service_android.h
[modify] https://crrev.com/74732cc5bd751944f978ea1ff40f10cde31f2100/net/proxy_resolution/proxy_config_service_android_unittest.cc

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

commit 08260e4c1445f7d2986843299671ed11787b8c7b
Author: Laís Minchillo <laisminchillo@chromium.org>
Date: Fri Sep 21 10:20:51 2018

[aw] Fix null pointer dereference in aw_url_request_context_getter

Fix trying to access the proxy_config_service that was moved to the
url_request_context in InitializeURLRequestContext

Bug:  851995 
Change-Id: Icc31c661ff4bd0e6b92d899a9d427ed75db0a295
Reviewed-on: https://chromium-review.googlesource.com/1234154
Reviewed-by: Matt Menke <mmenke@chromium.org>
Reviewed-by: Tobias Sargeant <tobiasjs@chromium.org>
Commit-Queue: Laís Minchillo <laisminchillo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593140}
[modify] https://crrev.com/08260e4c1445f7d2986843299671ed11787b8c7b/android_webview/browser/net/aw_url_request_context_getter.cc
[modify] https://crrev.com/08260e4c1445f7d2986843299671ed11787b8c7b/android_webview/browser/net/aw_url_request_context_getter.h

This bug requires manual review: M70 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This hasn't made it to canary yet. Let's verify and follow up on Monday.

The NextAction date has arrived: 2018-09-24

This last CL fixes a bug in code that isn't being called anywhere else at the moment. There is no way to verify it other than running local code.

> There is no way to verify it other than running local code.

I think usual protocol is to install the canary and run your tests locally. If it's all good on your end, I think this is a reasonable cherry pick.

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

Commit: b2a019f14bfc3d23808c65963bccf1c439f17fc1
Author: laisminchillo@chromium.org
Commiter: tobiasjs@chromium.org
Date: 2018-09-25 12:42:01 +0000 UTC

[aw] Fix null pointer dereference in aw_url_request_context_getter

Fix trying to access the proxy_config_service that was moved to the
url_request_context in InitializeURLRequestContext

Bug:  851995 
Change-Id: Icc31c661ff4bd0e6b92d899a9d427ed75db0a295
Reviewed-on: https://chromium-review.googlesource.com/1234154
Reviewed-by: Matt Menke <mmenke@chromium.org>
Reviewed-by: Tobias Sargeant <tobiasjs@chromium.org>
Commit-Queue: Laís Minchillo <laisminchillo@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#593140}(cherry picked from commit 08260e4c1445f7d2986843299671ed11787b8c7b)
Reviewed-on: https://chromium-review.googlesource.com/1243144
Cr-Commit-Position: refs/branch-heads/3538@{#649}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}

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

commit b2a019f14bfc3d23808c65963bccf1c439f17fc1
Author: Laís Minchillo <laisminchillo@chromium.org>
Date: Tue Sep 25 12:42:01 2018

[aw] Fix null pointer dereference in aw_url_request_context_getter

Fix trying to access the proxy_config_service that was moved to the
url_request_context in InitializeURLRequestContext

Bug:  851995 
Change-Id: Icc31c661ff4bd0e6b92d899a9d427ed75db0a295
Reviewed-on: https://chromium-review.googlesource.com/1234154
Reviewed-by: Matt Menke <mmenke@chromium.org>
Reviewed-by: Tobias Sargeant <tobiasjs@chromium.org>
Commit-Queue: Laís Minchillo <laisminchillo@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#593140}(cherry picked from commit 08260e4c1445f7d2986843299671ed11787b8c7b)
Reviewed-on: https://chromium-review.googlesource.com/1243144
Cr-Commit-Position: refs/branch-heads/3538@{#649}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/b2a019f14bfc3d23808c65963bccf1c439f17fc1/android_webview/browser/net/aw_url_request_context_getter.cc
[modify] https://crrev.com/b2a019f14bfc3d23808c65963bccf1c439f17fc1/android_webview/browser/net/aw_url_request_context_getter.h

verified on pixel 2xl / PPR1.181005.003 vs 70.0.3538.44

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

commit e2dd9b16afe9c2808aaa11566aa54fa854282db2
Author: Laís Minchillo <laisminchillo@chromium.org>
Date: Fri Oct 12 10:36:11 2018

[aw] Add callback to proxy override methods

Add an optional callback to proxy override methods introduced in change
https://chromium-review.googlesource.com/c/chromium/src/+/1148384

This adds an optional callback developers can use to know when the
changes have been made to the network settings, since the methods are
not synchronous with the UI thread.

Bug:  851995 
Change-Id: I08dc7cc87c57d213b67774d3391562ca07fd0217
Reviewed-on: https://chromium-review.googlesource.com/c/1258770
Commit-Queue: Laís Minchillo <laisminchillo@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#599166}
[modify] https://crrev.com/e2dd9b16afe9c2808aaa11566aa54fa854282db2/android_webview/browser/aw_contents_statics.cc
[modify] https://crrev.com/e2dd9b16afe9c2808aaa11566aa54fa854282db2/android_webview/browser/net/aw_url_request_context_getter.cc
[modify] https://crrev.com/e2dd9b16afe9c2808aaa11566aa54fa854282db2/android_webview/browser/net/aw_url_request_context_getter.h
[modify] https://crrev.com/e2dd9b16afe9c2808aaa11566aa54fa854282db2/android_webview/glue/java/src/com/android/webview/chromium/SharedStatics.java
[modify] https://crrev.com/e2dd9b16afe9c2808aaa11566aa54fa854282db2/android_webview/java/src/org/chromium/android_webview/AwContentsStatics.java
[modify] https://crrev.com/e2dd9b16afe9c2808aaa11566aa54fa854282db2/android_webview/support_library/boundary_interfaces/src/org/chromium/support_lib_boundary/StaticsBoundaryInterface.java
[modify] https://crrev.com/e2dd9b16afe9c2808aaa11566aa54fa854282db2/android_webview/support_library/boundary_interfaces/src/org/chromium/support_lib_boundary/util/Features.java
[modify] https://crrev.com/e2dd9b16afe9c2808aaa11566aa54fa854282db2/android_webview/support_library/java/src/org/chromium/support_lib_glue/SupportLibWebViewChromiumFactory.java
[modify] https://crrev.com/e2dd9b16afe9c2808aaa11566aa54fa854282db2/net/proxy_resolution/proxy_config_service_android.cc
[modify] https://crrev.com/e2dd9b16afe9c2808aaa11566aa54fa854282db2/net/proxy_resolution/proxy_config_service_android.h
[modify] https://crrev.com/e2dd9b16afe9c2808aaa11566aa54fa854282db2/net/proxy_resolution/proxy_config_service_android_unittest.cc

Why are we merging this? c#72 landed under a separate Feature name, there's no technical reason I'm aware of to require a merge.

Your change meets the bar and is auto-approved for M71. Please go ahead and merge the CL to branch 3578 manually. Please contact milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@ntfschr
This CL adds a callback to the methods that were previously merged. If we get it into 71 developers will have access to the API sooner, that's why I made the merge request.

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

commit 3df2d819383e63d4cab7ce11b9eab3eb2906f861
Author: Laís Minchillo <laisminchillo@chromium.org>
Date: Mon Oct 15 10:54:24 2018

[aw] Add callback to proxy override methods

Add an optional callback to proxy override methods introduced in change
https://chromium-review.googlesource.com/c/chromium/src/+/1148384

This adds an optional callback developers can use to know when the
changes have been made to the network settings, since the methods are
not synchronous with the UI thread.

Bug:  851995 
Change-Id: I08dc7cc87c57d213b67774d3391562ca07fd0217
Reviewed-on: https://chromium-review.googlesource.com/c/1258770
Commit-Queue: Laís Minchillo <laisminchillo@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#599166}(cherry picked from commit e2dd9b16afe9c2808aaa11566aa54fa854282db2)
Reviewed-on: https://chromium-review.googlesource.com/c/1280604
Reviewed-by: Tobias Sargeant <tobiasjs@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#19}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/3df2d819383e63d4cab7ce11b9eab3eb2906f861/android_webview/browser/aw_contents_statics.cc
[modify] https://crrev.com/3df2d819383e63d4cab7ce11b9eab3eb2906f861/android_webview/browser/net/aw_url_request_context_getter.cc
[modify] https://crrev.com/3df2d819383e63d4cab7ce11b9eab3eb2906f861/android_webview/browser/net/aw_url_request_context_getter.h
[modify] https://crrev.com/3df2d819383e63d4cab7ce11b9eab3eb2906f861/android_webview/glue/java/src/com/android/webview/chromium/SharedStatics.java
[modify] https://crrev.com/3df2d819383e63d4cab7ce11b9eab3eb2906f861/android_webview/java/src/org/chromium/android_webview/AwContentsStatics.java
[modify] https://crrev.com/3df2d819383e63d4cab7ce11b9eab3eb2906f861/android_webview/support_library/boundary_interfaces/src/org/chromium/support_lib_boundary/StaticsBoundaryInterface.java
[modify] https://crrev.com/3df2d819383e63d4cab7ce11b9eab3eb2906f861/android_webview/support_library/boundary_interfaces/src/org/chromium/support_lib_boundary/util/Features.java
[modify] https://crrev.com/3df2d819383e63d4cab7ce11b9eab3eb2906f861/android_webview/support_library/java/src/org/chromium/support_lib_glue/SupportLibWebViewChromiumFactory.java
[modify] https://crrev.com/3df2d819383e63d4cab7ce11b9eab3eb2906f861/net/proxy_resolution/proxy_config_service_android.cc
[modify] https://crrev.com/3df2d819383e63d4cab7ce11b9eab3eb2906f861/net/proxy_resolution/proxy_config_service_android.h
[modify] https://crrev.com/3df2d819383e63d4cab7ce11b9eab3eb2906f861/net/proxy_resolution/proxy_config_service_android_unittest.cc

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

Commit: 3df2d819383e63d4cab7ce11b9eab3eb2906f861
Author: laisminchillo@chromium.org
Commiter: tobiasjs@chromium.org
Date: 2018-10-15 10:54:24 +0000 UTC

[aw] Add callback to proxy override methods

Add an optional callback to proxy override methods introduced in change
https://chromium-review.googlesource.com/c/chromium/src/+/1148384

This adds an optional callback developers can use to know when the
changes have been made to the network settings, since the methods are
not synchronous with the UI thread.

Bug:  851995 
Change-Id: I08dc7cc87c57d213b67774d3391562ca07fd0217
Reviewed-on: https://chromium-review.googlesource.com/c/1258770
Commit-Queue: Laís Minchillo <laisminchillo@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#599166}(cherry picked from commit e2dd9b16afe9c2808aaa11566aa54fa854282db2)
Reviewed-on: https://chromium-review.googlesource.com/c/1280604
Reviewed-by: Tobias Sargeant <tobiasjs@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#19}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}

Verified on webview : 71.0.3578.31

Device: 
Samsung S5/MMB29M
Pixel Xl/PQ2A
Pixel C/ OPR1