Google Play Services 4.1

The latest Google Play Services release adds support for turn-based multiplayer in Google Play games and introduces a Google Drive API for Android that you can use as a developer preview. 

Google Play services 4.1 also includes an updated Google Mobile Ads SDK that supports DoubleClick for Publishers and publisher-provided location, and in the Google+ Platform for Android an improved Google+ sharing experience makes it even easier to share right from your app. 

We’re currently rolling out Google Play services 4.1 to Android devices across the world, a process we expect to take several days. Once the rollout is complete, you'll be able to download the latest Google Play services SDK and start developing against the new APIs. Watch for more information, documentation, and videos coming next week. 

To learn more about Google Play services and the APIs available to you through it, visit the Google Services area of the Android Developers site.

Link: http://android-developers.blogspot.com/2014/01/google-play-services-41.html

#AndroidDev
378
115
Roberto Fabrizi's profile photoApostol Apostolov's profile photoGDG Philippines's profile photoTed Chien's profile photo
59 comments
 
Not a minute too soon!
 
Where is the new Drive API? I can't find within 3 clicks of this :P
 
Play Services is the heart of +Android ! This, is like an OTA, which will hit every single Android silently!!! You should start producing pie charts with Play Services ! :)
 
As said in the blog post, also seems to fix the currently high battery usage of location services.
 
Does this mean the broken G+1 button (button won't work unless the user logs into G± inside the app) bug has finally been fixed after it was introduced in the last update?
 
+Robert Cooper The SDK is not useful without the APK installed on your device, which is why we don't publish it until the rollout is complete and everyone is eligible to upgrade to the latest version of the APK.
 
+Jeff Hamilton The SDK is useful on the emulator without a single physical device having it, and drafts of the docs are useful well in advance of release so people can start to understand the deltas.

Something deployed to every device in the wild before developers know about it is a curious definition of developer preview.
 
+Friedger Müffke Google Drive already participates in DocumentsProvider.  Google Play services is for Google's own proprietary services, and one of those services is Drive.
 
Turn-based multiplayer support ? Awesome !!!
 
I'm very amped for a flurry of awesome turn based games i n the Play Store.
Final Fantasy Tactics would be Grrreeat
 
+Dianne Hackborn even more interesting to see what the Drive API in Google Play Services looks like and why you duplicate the API.

+Tadej Rudec +Dianne Hackborn Sure, hence the name. However, +Android Developers shouldn't loose sight of all the great APIs of other companies and projects in the Android ecosystem, like Unclouded.io, OpenXC for Android, ANT, MQTT and so on ..
 
+Friedger Müffke Semantics much ? We're all aware the +Android Developers is maintained by Google, hence why it informs mainly about their own presentations to Android ecosystem. Although I did saw quite some re-shares and +1 on other non Google projects, presented by other people/pages. 
 
Why would they announce this...but not provide the APIs or any documentation for devs to help prepare them for this? Come on Google!
 
Hope this solves the bug that drives the play services ti use data without any aparent reason. It's starting to really mad me!
 
+Friedger Müffke It's not a duplicate API.  The platform provides a generic backed-neutral API for operating on data.  It isn't even cloud-specific -- one of our back-ends lets you operate on files on additional SD cards.

The API Google provides is a specific cloud access API to their drive service.
 
+Friedger Müffke Put another way, Google's Drive API is basically what you would use to implement a Drive plug-in to the platform's DocumentsProvider architecture.
 
+Dianne Hackborn Could you gives us an example when we should be using the DocumentsProvider  API vs. going directly to Google Drive with this yet-unseen API?  Of course, assuming we only want to read/write files which live on Google Drive.
 
+Jeff Hamilton and I completely agree that it's utterly pointless to even talk about a "preliminary API" and "developer preview", if it's not available for developers to try.   Sometime I just don't get what's the thinking behind some of these announcements are.
 
+Tom anMoney They are just for different things.  DocumentsProvider lets you bring up a system UI for the user to pick where they want to have you store a file, which can be wherever people have written providers for -- as I said, this allows putting them on the SD card, in Google Drive, other back-ends like DropBox etc will also hopefully at some point have providers.

The Google Drive APIs are for...  well, directly interacting with files in Google Drive, and only in Google Drive.
 
+Dianne Hackborn Thanks.  So a use case would be if I want to provide a generic file load/save capability, I'd use DocumentsProvider, whereas, I am using Google Drive more like a internal implementation detail or that I want to be able to provide some file load/save functionality pre-KitKat, I might choose the Google Drive API.

I am very thankful for providing this, by the way, as it solves one of my long-standing issues of having to add the Internet permission for cloud storage.  With this, I can finally implement a cloud storage option in my app.
 
+Roberto Fabrizi there's no way to get rid of those wake locks because they are a must for geo fencing.
But reducing wake locks aren't the only way to reduce battery. More important than the wake locks is what happens after waking. The amount of processing that comes after waking is more important than the wake locks their self.
And that processing is where Google must have improve.
Like I said you can't judge that solely by the number of wake locks
 
+Joaquim Santos  On google's website you can read that the number of location updates isnt on a fixed timer, it depends on many factors. Don't you think that me being serviced by the same cell tower and in range of the same wifi should mean that the wake ups don't occur so ofter, for no reason at all?
 
PS: I have disabled them all but I can use geofencing just fine where I need it (Tasker) and can use Maps navigation or check in G+ also just fine, so stopping them hasnt caused my phone and my usage any issue at all
 
+Roberto Fabrizi if you move your device more you'll have more wake locks. That's how the system Google implemented works. It depends on way more things than cell tower and wifi.

 
+Roberto Fabrizi you may not use it but it is still working on the background. If not then geo fencing wouldn't work at all
 
+Roberto Fabrizi and by the way. . Have you got the latest version 4.1? Put a screen shot there cause I haven't seen nobody with it already. .maybe your the first. .
 
+Joaquim Santos 1) that's what I was saying. If it wakes up my device as many times in 3 hours that the cell hasnt moved at all (sensors, cell tower, wifi proximity, screen off), then it's badly implemented. If I was on a motorbike it'd have waken my device up a million times? Come on, it's direly coded and needs fixing.
2) That I get, but which features and functionalities am I actually sacrificing? Cause all my apps, even the ones that use geofences like Tasker, works just fine. Id rather have more battery than a phantom feature with a cool name that brings me no benefits.
3) I dont generally wait for Google's updates to arrive, I push apk and sideload otas: https://dl.dropboxusercontent.com/u/66751019/Screenshot_2014-01-11-14-17-51.png
 
+Roberto Fabrizi 1% per hour isn't bad. .In fact it's good. .that's what you got. number of wake locks isn't what you should judge by because of the reasons I said above.
Instead judge by battery usage
 
oh come on, stop changing subjects. you dont even know which background tasks ran in this hour that i didnt touch the phone (sync on or off?), which kernel im running, if im undervolting or underclocking. These userspace wakelocks are a result of poorly implemented code and the 4.1 update didnt fix it, end of story
 
+Roberto Fabrizi lol. I'm changing subjects? Lol

If you don't know 1% per hour it's what Google advertised as its location services use..(see Google io of last year) Even if the phone was just idle that 1% use is normal and it's considered good.
Instead of present the number of wake locks as a bad thing, you should learn more about wake locks to see that it's not just the number of them that drains battery but more importantly it's what happens after the device has waken. 
What you present as bad in fact it's really normal
 
I've pointed out that despite their claims, the battery drain of the location services aren't fixed and even though the cell stood still, with the screen off, connected to the same wifi and cell tower, therefore the whole geofencing thingy was completely pointless, it still wakelocked like crazy. My battery consumption is not the argument of the discussion here. Besides, you are making things up. My 1% battery consumption is NOT from Play Services only as you say, it's a combination of many factors, like cell signal strength, custom kernel efficiency (cpu scheduler etc), which apps I am letting sync or not, how much I'm undervolting and underclocking the cpu, etc etc. My battery consumption has really nothing to do with the amounts of wakelocks that the play services is requesting for no reason. 
Besides, you still havent provided me a concrete functionality or issue that I would incur in by blocking those wakelocks and saving a ton of wasted battery life, so why don't you start there?
 
I made my point and got a lot more things to do. It seems that you don't want to listen but just to argue..
Bye

 
ahahah right, bye bye, off you go and have fun with your geofences :)
 
Post what happens if I block those wakelocks if you want me to take you any more seriously. Right now you are no more than a random google follower, lets see your dev skills

EDIT: and not something vague like it breaks geofencing, that won't do it

PS: I forgot to mention that my 1% was also due to a patched wifi driver, the stock one is dire, kernel wakelocks like crazy. but lets get back to these userspace location wakelocks now
 
oh noes someone on the internet told me to grow up...im so hurt now....proof of why google play services needs to grab 300 wakelocks in 3 hour of my phone idling and what blocking those actually breaks?
 
Which part of "Do not acquire PowerManager.WakeLocks unless you really need them, use the minimum levels possible" did you not understand when you started developing on android?
 
Can anyone at Google comment on whether the turn-based multiplayer feature will be implemented in the iOS version of Google Play Games? I build games for both platforms and this would be a killer feature. Thanks.
 
Why don't Google play have a gift option for apps/games? I would like to buy apps that I like and gift them to my android friends!
 
sounds good - when will the documentation be released?
 
+Tom anMoney I would be surprised if your app won't need internet permission when using the drive API. The user would trust your app to not transfer any data and you would do it never the less?
Ads in Google Play Services require internet permission as well...
 
I'm confused, the Mobile Ads documentation still says: "Note: The SDK doesn’t currently support DFP, Ad Exchange or Search Ads for Mobile Apps but support is coming soon." 
Add a comment...