Welcome back! Google Play Services 3.1 is such a ridiculously huge update; I had to stretch it out over two articles - that's a first for APK Teardown. If you somehow missed the Google Play Games extravaganza, part one is right here.

Part two is all about the non-games discoveries, which there are a lot of.  Before we get into that though, there is one detail I left out of the games article that I really should mention:

The Play Games Codename


Google always comes up with the coolest code names for projects, and the Play Services games client is no exception. The internal name is "OneUp."

Four New Sync Adapters

Sync adapters are the things listed in Settings -> Google -> [your email] (at least, these are the Google sync adapters; anyone is free to write one). The job of a Google sync adapter is to ship data back and forth between you and the Google mother ship. Sync adapters make sure that that Gmail message that you archived on your phone is also archived on your desktop, and your tablet, and anywhere else you access your data. They sync stuff. Google likes to have one sync adapter for each Google service. When Google launches a new app or service, they usually include a new sync adapter in the app package.


Google Play Services can include sync adapters, too, and the most visible parts of the 3.1 update are these two new sync adapters: "App Data" and "People details."


The thing is, Play Services 3.1 actually shipped four new sync adapters: App Data, People Details, Game Data, and Location Reporting. It turns out Sync adapters can be flagged as invisible; a simple "android:userVisible="false"" will send them into hiding, so, while you can't actually see Game Data and Location Reporting, I assure you they are there.

App Data Syncing


Yes, that "App Data" entry in the sync settings means all the things you think it means. Provided the developer supports it, you'll be shipping your app data off to Google, and it will sync just as reliably as your Gmail data does.

<string name="appstate_sync_label">App Data</string>
<string name="appstate_clear_app_data_dialog_title">Clear app data?</string>
<string name="appstate_clear_app_data_dialog_description_single_account">You are about to delete all third-party app data stored with your Google account %1$s. This data will no longer be available on any of your devices.</string>
<string name="appstate_deleting_app_data">Deleting app data…</string>
<string name="appstate_could_not_delete_data">"Couldn't delete data."</string>

Google will, of course, give you control over your cloud data. The language used here is particularly interesting: they call this data "app data stored with your Google account," which means it's the same "app data" we all know and love from the "clear app data" button. That means all your 3rd-party app data in the cloud, seamlessly synced across devices.

Most of the big questions with this will not be answered with code, but with policy: How much data can developers store? How often can they access it? Is there a limit on users-per-app? Does it cost money? Etc. Having limits or charging for this doesn't seem very Googley, so for now I'm expecting that Google will allow you to store whatever you want and sync it however often you want, as long as you are under a certain storage limit. Most app data is microscopic, so a storage limit wouldn't be a big deal.

There's also a question of how they're going to deal with multiple devices - for instance, the launcher data on my phone would be very different than the launcher data on my tablet. There's an I/O session called "From Nothing to Nirvana in Minutes: Cloud Backend for Your Android Application," and after reading the description, it sounds like this is the "Cloud-Stored App Data" talk:

The best Android applications take full advantage of the cloud to power great user experiences. This talk shows, in detail, how to use the server-code optional backend on the Google Cloud Platform to store application and game state in the cloud. We will then walk through adding your own custom logic via Google Cloud Endpoints and the Google Plugin for Eclipse.

Hopefully all of that "server back end" functionality allows this to differentiate between devices.

This would be a huge game changer. You're basically looking at fully cloud-stored Android devices at this point. Every useful piece of data on your phone would be continually, automatically backed up using the rock-solid Android sync framework. That is just awesome.

Besides being completely amazing for users, this has the bonus side effect of making a forked version of Android even more unappealing; this is one more killer back-end feature that you wouldn't have access to. Good luck replicating this, Amazon and Samsung.

Game Data Syncing

This is the last games thing, I promise. There's a separate sync adapter for games data, but, uh, games are just apps, right? So what's with the extra adapter?

localaia.a("games", "game_icon_image_id");
localaia.a("games", "game_hi_res_image_id");
localaia.a("games", "featured_image_id");
localaia.a("game_badges", "badge_icon_image_id");
localaia.a("players", "profile_icon_image_id");
localaia.a("players", "profile_hi_res_image_id");
localaia.a("achievement_definitions", "unlocked_icon_image_id");
localaia.a("achievement_definitions", "revealed_icon_image_id");
localaia.a("leaderboards", "board_icon_image_id");
localaia.a("leaderboard_scores", "default_display_image_id");
localaia.a("notifications", "image_id");
localaia.a("participants", "default_display_image_id");

It looks like the App Data sync adapter is for third parties, and the Game data adapter is specifically for Play Games. According to the content provider, this is for shipping out achievements and leaderboard status and other Play Games data. It looks like games will use the App Data sync adapter for cloud saves.

People Details

<string name="people_service_title">People Service</string>
<string name="people_sync_service_title">People details</string>
<string name="people_content_provider_title">People details</string>

There is a new "people details" sync adapter, which seems to be all about syncing Google+ data to your phone. There is already a sync adapter for basic contact information, so this would have to be something else.

<string name="people_avatar_dialog_title">Set profile photo</string>
<string name="people_avatar_dialog_item_take_photo">Take photo</string>
<string name="people_avatar_dialog_item_pick_photo">Choose photo</string>
<string name="people_avatar_progress_message">Setting profile photo…</string>
<string name="people_avatar_preview_accept_button">Accept</string>
<string name="people_avatar_error">"Couldn't save profile photo."</string>
<string name="people_avatar_error_not_plus_user">You need a Google+ profile to set a profile photo.</string>

This all seems to be stuff the Google+ app already does, but moved from the G+ app to Google Play Services, nothing groundbreaking.

Activity Recognition And Push Location

There's a new sync adapter for location reporting, which is completely crazy. Currently, shipping out location data is an app-based process. Apps request location data from the system however often and for however long they want. Developers that screw that up can often reduce your battery to nothing in an hour - that's bad.

<string name="location_ulr_sync_label">Location reporting and history</string>

I'm not an expert on Android location services or anything, but having a location sync adapter seems like a huge change from the current way Android handles location information. (If you're a developer, feel free to chime in in the comments.) A sync adapter would presumably push your location information to the cloud, and apps would ping that cloud information. I not sure why apps would want to get information from the cloud that is already available on your device, perhaps this is for a social service, or apps on other devices, or something like that.

It could be a boon for the upcoming wearable computing revolution. Something like Google Glass or a smartwatch would want my location, but power and/or size requirements mean they don't have a GPS chip. Right now, Glass's solution is a 24/7 Bluetooth connection, but if Glass and my phone are already pinging the internet all the time, why not get location updates that way, too?

<string name="activity_recognition_permission_label">activity recognition</string>
<string name="activity_recognition_permission_description">Allows an app to receive periodic updates of your activity level from Google, for example, if you are walking, driving, cycling, or stationary.</string>

Google is cooking up a use for this, and it is called "Activity Recognition." Apps will be able to tell if you are "walking, driving, cycling, or stationary" and do something with that information. This says apps will get your activity level "from Google" which backs up my theory that this is a cloud-based, push location service.

There's a session at Google I/O called "Beyond the Blue Dot: New Features in Android Location" where they will probably announce this. Start practicing your "surprised face" in the mirror now.


Google Play Services will not do anything on its own - everything requires some kind of support from other apps. For some reason though, people keep asking for it. So if you would like to poke around, here it is: Google Play Services 3.1.36.


Whew. Well, this easily qualifies for the longest APK Teardown ever, and I even left out some items. There was also lots and lots of Wallet movement. It's probably just for in-app purchases in games though, nothing exciting.

In one update Google shipped a games service, app data cloud storage, and a new push location service. It's crazy to think that there will be even more goodies waiting for us at Google I/O; which is in just 2 days. Wow.