Obsolete
Status Update
No update yet.
Comments
va...@chromium.org
I notice the same issue and LogCat shows the following message:
Google Play services out of date. Requires 3159100 but found 3136130
Google Play services out of date. Requires 3159100 but found 3136130
pe...@chromium.org
Same here.
"Google Play services out of date. Requires 3159100 but found 3136130"
"Google Play services out of date. Requires 3159100 but found 3136130"
av...@chromium.org
me as well....
Google Play services out of date. Requires 3159100 but found 3136130
Google Play services out of date. Requires 3159100 but found 3136130
av...@chromium.org
I was hopeful that the release of API 18 (4.3) would have created a solution to this, unfortunately it includes version 3158130
av...@chromium.org
Having the same issue:
07-25 00:03:54.998: W/GooglePlayServicesUtil(27293): Google Play services out of date. Requires 3159100 but found 3158130
07-25 00:03:54.998: W/GooglePlayServicesUtil(27293): Google Play services out of date. Requires 3159100 but found 3158130
av...@chromium.org
same
av...@chromium.org
SAME ! - Google can't do sth working in 100 percent?
av...@chromium.org
same issue - Google Play services out of date. Requires 3159100 but found 3158130
li...@chromium.org
Having the same issure:
07-26 03:14:00.731: W/GooglePlayServicesUtil(2566): Google Play services out of date. Requires 3159100 but found 3136130
07-26 03:14:00.731: W/GooglePlayServicesUtil(2566): Google Play services out of date. Requires 3159100 but found 3136130
dt...@chromium.org
API 18 (4.3) same issue
07-26 03:54:03.303: W/GooglePlayServicesUtil(1207): Google Play services out of date. Requires 3159100 but found 3158130
07-26 03:54:03.303: W/GooglePlayServicesUtil(1207): Google Play services out of date. Requires 3159100 but found 3158130
pb...@chromium.org
Same issue here.
dt...@chromium.org
Same issue here. How can i fix this bug?
qi...@chromium.org
We're working on this. I don't have an ETA yet other than the maddeningly vague "soon".
qi...@chromium.org
Thanks for the update @sbarta. It is good that you are keeping us informed. This is a very critical and blocking bug for anyone developing with maps.
da...@dana.is
FYI also getting same with PlusClient sign in, so this is not just a maps issue:
ConnectionResult.SERVICE_VERSION_UPDATE_REQUIRED
07-30 12:35:50.059: W/GooglePlayServicesUtil(16054): Google Play services out of date. Requires 3159100 but found 1013
ConnectionResult.SERVICE_VERSION_UPDATE_REQUIRED
07-30 12:35:50.059: W/GooglePlayServicesUtil(16054): Google Play services out of date. Requires 3159100 but found 1013
xi...@chromium.org
Same page here!
07-31 22:47:40.277: W/GooglePlayServicesUtil(1009): Google Play services out of date. Requires 3159100 but found 3158130
Thing is: we work under timelines too, and we need this fix quick! I cannot go wondering around asking for cellphones all over the place... I used to have this fixed with my emulators!!
07-31 22:47:40.277: W/GooglePlayServicesUtil(1009): Google Play services out of date. Requires 3159100 but found 3158130
Thing is: we work under timelines too, and we need this fix quick! I cannot go wondering around asking for cellphones all over the place... I used to have this fixed with my emulators!!
xi...@chromium.org
av...@chromium.org
The Play Services team knows about this issue and is working on it with a high priority. The fix for this will go in the same emulator image in the same timeframe. Sorry I'm being vague about when it'll go out; I don't want to tell you something and then have us miss it. I'll update this bug when I know more.
xi...@chromium.org
Just would like to add that we are experiencing this on device as well, not just in AVD. Not sure if that matters...
xi...@chromium.org
Any ETA on this fix? Appreciate your reply.
de...@chromium.org
There's no ETA yet. I think a new version of the Google Play Services add-on in the SDK manager is going out today, but this doesn't help the issue of needing to update the emulator system images.
xi...@chromium.org
Any update on this?
Any chance you could put a note in the tutorial/setup documentation as it is infuriating (not to mention a waste of time) to follow steps exactly as described and not get something working. Resorting to Stack Overflow to find a load of hacks (and a lot of incorrect answers) for manually installing the required .apks and finally a link here to see that the issue is at least 3 weeks old with no target fix date.
Any chance you could put a note in the tutorial/setup documentation as it is infuriating (not to mention a waste of time) to follow steps exactly as described and not get something working. Resorting to Stack Overflow to find a load of hacks (and a lot of incorrect answers) for manually installing the required .apks and finally a link here to see that the issue is at least 3 weeks old with no target fix date.
pm...@chromium.org
I agree, please update the documentation while it is not working.
ha...@google.com
Agreed on updating the documentation. I wasted two days on this issue and it pains me to see it repeated Ad nauseam.
ha...@google.com
I lost hours on this problem thinking it was my fault.
Is ridiculous that a company like google do shit like that.
Is ridiculous that a company like google do shit like that.
is...@google.com
This should go out today.
Description
Example URL:
Steps to reproduce the problem:
Working on a page where the user is presented with a download link for a .pem file, we discovered that Blink-based browsers on Windows and Linux (including Chrome, Opera, and Edge) change the extension of the downloaded file if the URL contains a query string. I was able to replicate this with the following DigiCert URL:
1. Download the .pem file in Chrome using the above URL; it should save with the expected file name — BaltimoreCyberTrustRoot.crt.pem
2. Change the URL so that it has e.g. ?foo=bar at the end, then download again. This time it should save with a file name like BaltimoreCyberTrustRoot.crt.cer
What is the expected behavior?
I expect Chrome to leave the file extension the way it is, regardless of whether there is a query string in the URL. Firefox behaves this way on all three platforms, as do Chrome and Safari on macOS.
(curl retains the entire query string in the downloaded file name, which i also find unhelpful, but at least it makes sense — it's not just arbitrarily changing it.)
What went wrong?
Chrome changed the extension.
Did this work before? N/A
Chrome version: 80.0.3987.122 (Official Build) (64-bit) Channel: stable
OS Version: OS X 10.14
Flash Version:
Obviously the scenario in question is without Content-Disposition; i haven't tested it but i have no reason to believe that Chrome would change the file name if it was specified that way. Unfortunately i can't send Content-Disposition in my particular case.
I also noticed that it doesn't mess with the file name if the extension is .crt (/cert.crt?foo=bar) instead of .pem.