After initialization, google play works well behine proxy

nope, google play doesn't work at all behind proxy. I was confused by offline support of google play.

Now Google Play works behind a proxy... after the first initialization, which still requires a proxy-free connection. So the bug title is perfect.

Reproduced with 64.0.3265.0, 10128.0.0 version built today, Shift-Alt-i feedback sent please attach.

Yes, feedback report is @ https://listnr.corp.google.com/report/84655471728 (Google-internal only)

Do we know which URL exactly is breaking on the proxy network?

Are you keeping all the URLs mentioned in [1] whitelisted in your proxy?

In particular: Hostname whitelist for Chrome devices using Android apps (Google Play Store)
If you use Android apps on Chrome devices (Google Play Store), whitelist the following hostname in addition to the hostnames listed above under Hostname whitelist for all Chrome devices.

connectivitycheck.android.com



[1] https://support.google.com/chrome/a/answer/6334001

> Do we know which URL exactly is breaking on the proxy network?

Isn't that found in one of the log files attached to the feedback reports?

> Are you keeping all the URLs mentioned in [1] whitelisted in your proxy?

There's no SSL inspection so I don't think this is relevant. If it were then I guess there would be many more network issues than just this very specific, very first time Play Store initialization. Everything just works before *and* after that initial step.

Has Google ever tested this step behind a proxy?

A lot more than just Play is involved during initial login. The logs unfortunately are not very useful as they are full of unrelated errors. However, some code is complaining about missing accounts and that matches my hunch: I think we are failing to copy the user's GAIA account to ARC++.

+Hongming, will the auth module use a proxy configured on the device? Or will it try to bypass it?

Attaching two captures of all DNS and TCP SYN packets during the failure to initialize the play store.

The first capture is during the initial failure, the second one is when hitting the "retry" button.

None of the TCP SYN packets are directed at the proxy, they're all misdirected to (Google?) public addresses and all the corresponding TCP connection attempts fail (there were actually 4 SYN packets sent to the https_proxy in one of the two captures but I removed those)

Deleted: playstore-noproxy.pcap 21.9 KB

playstore-noproxy.pcap 21.9 KB Download

Deleted: playstore-noproxy-retry.pcap 24.8 KB

playstore-noproxy-retry.pcap 24.8 KB Download

> A lot more than just Play is involved during initial login. 

In the feedback reports I submitted (much earlier), I did NOT try to initialize the play store *immediately* after boot and login, instead I waited a minute or two with the deliberate intent to make log parsing easier thanks to their timestamps.

I support G Suite / ChromeOS devices and my team is experiencing issues with the Play Store on Chromebook devices. They are unable to connect to the Play Store while on our corporate network. All of the necessary URLs and ports are being allowed through the firewall, Google Cloud Support has determined that it is likely related to this case. 

Our environment uses Zscaler as a web filter, and ChromeOS is set for web proxy autoconfiguration. When authenticated through Zscaler, the Play Store connection is still being refused. 

Derek, this bug is specifically about the very first, once off ARC++ initialization and not about anything happening past that.

What happens if - for pure testing purposes - you temporarily take a device out of Zscaler, successfully initialize the Play store there and then get back behind Zscaler? If that's still causing problems then you have at a different proxy issue (probably in addition to this one).

+Philipp will be working on proxies for ARC++ soon. This bug is of interest to him as it prevents first-time setup behind a forced proxy.

There's another, more general issue with ChromeOS and proxies. Please point at the corresponding bug if any.

The Chrome browser on Windows always had excellent and super fast proxy autodetection: switch between various networks and never have to configure anything. ChromeOS on the other hand always required many clicks to merely enable auto detection. How come?

On Windows, we get configuration from the OS (Which is actually extremely bad for a fair number of users - Windows has WPAD autodetect by default for home users, despite the fact that none should have it enabled, and some people are on networks where WPAD requests end up going to a black hole).  On ChromeOS we have our own configuration UI, which I'm not familiar with.  There's a bug to get rid of WPAD support, actually.  See https://crbug.com/798865.

Reproduced with 66.03359.10 10452.1.0

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/19/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.

I found a workaround: use command `android-sh` to enter Android container's shell, then use `settings put global http_proxy <http_address>:<port>` to set proxy in Android container.

If you reproduced with a recent version then please share that exact version so this bug can be re-opened.