In Part 1 of this teardown, we saw what may be the return of [email protected], or at least something similar. There were also new pieces to Nearby, Google's unique technology for finding two devices (and people) in close proximity, and a possible (subtle) change to the way Smart Lock responds to wearable devices. In Part 2, we'll continue with the possible centralization of Chrome Sync to Play services, project Sidewinder, a mysterious appearance by Facebook, and more.
Chrome Sync Comes To Play Services
If you've ever used Google Chrome on Android –let's be honest, you probably have– then you've probably signed into your account and activated Chrome Sync to have things like bookmarks, history, and passwords in constant harmony across all of your devices. While this works really well, the setup process gets a little redundant for users that install all three variants of Chrome (Stable, Beta, and Dev). However, it looks like Chrome Sync is going to move, or at least become available directly through Google Play Services. Several activities and providers have been added, along with some of the necessary strings to implement the same functionality in the GMS package.
<activity android:excludeFromRecents="true" android:exported="false" android:name="com.google.android.gms.chromesync.ui.CustomPassphraseDialog" android:process="com.google.android.gms.ui" android:theme="@style/ChromeSync.Dialog"/>
<provider android:authorities="@string/chromesync_sync_authority" android:exported="false" android:label="@string/chromesync_sync_adapter_title" android:name="com.google.android.gms.chromesync.sync.SyncContentProvider" android:syncable="true"/>
<provider android:authorities="@string/temporary_value_provider_authority" android:exported="false" android:label="@string/temporary_value_provider_label" android:name="com.google.android.gms.auth.api.credentials.be.persistence.TemporaryValueProvider" android:syncable="false"/>
<provider android:authorities="com.google.android.gms.chromesync.persistence.provider" android:exported="true" android:name="com.google.android.gms.chromesync.persistence.ContentProvider" android:permission="com.google.android.gms.chromesync.permission.CONTENT_PROVIDER_ACCESS"/>
<provider android:authorities="com.google.android.gms.common.stats.net.contentprovider" android:exported="false" android:name="com.google.android.gms.common.stats.net.contentprovider.NetworkUsageContentProvider"/>
<service android:exported="false" android:name="com.google.android.gms.chromesync.service.ChromeSyncOperationService">
<service android:exported="false" android:name="com.google.android.gms.chromesync.sync.SyncReceiverService"/>
<service android:exported="true" android:label="@string/chromesync_sync_adapter_title" android:name="com.google.android.gms.chromesync.sync.SyncService">
<service android:exported="true" android:name="com.google.android.gms.chromesync.service.ChromeSyncApiService">
<permission android:name="com.google.android.gms.chromesync.permission.CONTENT_PROVIDER_ACCESS" android:protectionLevel="signature"/>
<string name="chromesync_custom_passphrase_explanation">" Your existing passwords for "<g id="account_name">%1$s</g> were encrypted with your passphrase. If you have forgotten your passphrase, stop and reset sync via <g id="chromesync_dashboard_domain"><a href=%2$s>Google Dashboard</a></g>". "</string>
<string name="chromesync_custom_passphrase_title">ChromeSync passphrase</string>
<string name="chromesync_enter_passphrase_hint">Enter passphrase</string>
<string name="chromesync_entered_wrong_passphrase">Wrong passphrase</string>
Of course, it's unlikely that Google would see it as necessary to move this functionality out of the browser and into Play services just to keep us from entering a password a couple of extra times. It's more likely that this move is related to the recent announcement that almost all of the Chrome for Android browser is now open source. It's likely that Chrome Sync is one of the last remaining closed source components. To relocate this piece from the browser apks into Play services would leave little, if any code that couldn't be made available to the public. Of course, there's no certainty that Chrome Sync will actually be removed from the browser apks. Whatever the specifics turn out to be, there are probably a few other advantages to bringing the functionality to a centralized location.
I see a lot of mysterious and unexplainable things during teardowns, not least of which are obscure codenames that evade all reasoning. Normally, I leave them be since they often turn out to be uninteresting little libraries or widgets that are shared around Google. There are other times that something stands out, begging for attention. A new project by the name of Sidewinder turned up, and it's raising at least a couple of flags... literally.
There are a couple of simple strings and a few bits in the Android Manifest, but those don't tell us anything very interesting. The interesting part is a single image:
For those who many not immediately recognize it, this image is based on the national flag of China. The large golden star that normally resides in the upper left corner has been replaced by Google's Play logo. There have been rumors circulating for a while that Google may be working with the Chinese government to allow limited access to the Play Store and some other Google services, which seems to be reinforced by this image. There are probably a lot of details that we simply don't know, so I won't try to speculate too much about the meaning.
It's worth noting that both the image and a few bits from the manifest contain the word 'auth,' which identifies them as part of a sign-in procedure. This isn't surprising in any way, but it adds a little weight to the likelihood that this would probably be shown to Chinese users when they are setting up a phone or adding a Play Store account to an existing device.
<receiver android:enabled="true" android:name="com.google.android.gms.auth.sidewinder.SidewinderBootReceiver">
<service android:enabled="false" android:name="com.google.android.gms.auth.sidewinder.SidewinderAccountAuthenticatorService" android:process="com.google.process.gapps">
<service android:label="@string/auth_confirm_creds_sync_title" android:name="com.google.android.gms.auth.sidewinder.SidewinderCredentialStateSyncService">
Rule Enforcement With Kids Accounts
Back in November, we covered an upcoming new feature called Kid Accounts, a special type of account that parents can use to limit the ways their children can use certain Android devices. We already know a fair amount about Kid Accounts from a teardown, and a few more details were filled in after a Chrome teardown, but there's still room for new information.
The latest update brings a pair of new background images called timeout_bg and bedtime_bg. It doesn't take rocket science to come to any conclusions about how these will be used, but I did look a little further for details.
left: timeout_bg, right: bedtime_bg
We already know it's possible to set a curfew for children when they should be headed to sleep, and that's obviously where the bedtime image will be used. It looks like this image will probably take over the regular lockscreen background as a visual way to communicate that the day is over and it's time to put down the device. This screen will also include the words, "It's time for bed."
The timeout background follows the same general principle, but it happens to be used in a layout named kids_grounding_alert, which leaves no mystery that this is the image kids will see when their device is locked up as punishment for bad behavior. There's also text for this screen that reads, "It's time for a break," but it looks like parents will either be able to change this to a custom message or add their own text below it.
This doesn't really give us any new information about functionality, but it makes the whole experience a little easier to imagine. Since we're looking at details and elements of polish, I'd be willing to bet that this will be an on-stage topic at I/O.
Sign-in with Facebook, Amazon, Microsoft and others?
Perhaps the least-expected discovery of this teardown came from a pair of new images. They are named auth_signin_idp_facebook_icon and auth_signin_idp_google_icon. There are also some xml definitions of how they should be drawn, leading to an end result approximately like this:
Note: the xml also calls for 2dp rounded corners, but I had to rush to finish these images before heading out the door, so you're getting square corners.
I'm sure everybody recognizes the all-to-familiar Facebook and Google logos, backed by their brand-specific colors. While it's strange enough that a Facebook logo is present, the naming convention, like Sidewinder, includes the 'auth' prefix again. That means there's something sign-in related. As strange as all of this is, it's only made more interesting to see the specific brand colors of AOL, LinkedIn, Microsoft, Paypal, and Yahoo are also included.
I'm reluctant to venture too many guesses because it seems incredibly unlikely that Google is planning to encourage users to sign into all of these assorted services. While many of these companies offer somewhat overlapping products, there is no single area in which they all directly compete. However, there is one common element among all of them: they make extensive use of OAuth 2.0, and most are even single sign-on providers. It's plausible Google is working with these other companies on a project related to simplifying secure sign-in around the Internet, but there's not enough information to make any bigger assertions than that.
Aside from a single reference to PayPal, there isn't any code that explicitly names any of these other companies, so it's possible that this project isn't that far along. Whatever the case may be, we'll probably have to wait a while before there are any firm details. Still, this gets the imagination going.
It would be hilarious to see Apple in that list. I might have called this a prank. :)
If you look back over both parts of this teardown, you might notice quite a few links to previous articles; and believe me, I skipped a lot of links that could have been added. I think the reason for this may be that Google is finally ready to launch many of the products and features that have been in the oven for a while.
We're less than a week away from Google's biggest event of the year (at least for developers), and the things we've seen in teardowns can only begin to scratch the surface of what could hit the stage. I'm sure there are plenty of surprises remaining, so let's gear up for another spectacular presentation. Artem Russakovskii and I will be there, so be sure to check out our live coverage and follow along for all of the latest news!