As the resident teardown guy, Update Wednesday was a huge letdown this week. After slicing and dicing a dozen or so apks, all I saw were bug fixes, minor adjustments, and updates with full changelogs. Come on Google, I can't write about the neat stuff if none of the secrets are allowed to leave Mountain View. Fortunately, I did get to look at an unreleased version of Play Services, and there are a few interesting things to take away from it. (Sorry, we don't have an APK to share with this one.)
System Updates For Android One
It's a safe bet Android One is Google's top priority right now. Google is flinging itself headlong into emerging markets with a launch procession that began in India and will continue on to Indonesia, Bangladesh, Nepal, Sri Lanka, and certainly many others.
When Android One was first announced, it came with the promise of quick, Nexus-style updates, but not much in the way of details about how that will work. Around the middle of last year, an update mechanism appeared in Play Services, which initially seemed to be connected to Android Silver. After Silver was squashed a few months later, the OTA mechanism in Play Services mysteriously updated to include the ability to install firmware updates from an SD card, which gave a pretty strong hint that it was intended (or repurposed) for Android One. With a new set of strings, we can make a few more assumptions about the update process and what it entails.
<string name="system_update_download_waiting_full_off_peak_status_text">Update will start downloading automatically between ^1 and ^2.</string>
<string name="system_update_download_waiting_off_peak_status_text">You can download this update over Wi-Fi at any time. Otherwise, it will start downloading automatically between ^1 and ^2.</string>
<string name="system_update_download_waiting_operator_mismatch_text">To download this update, first switch to your other SIM card.</string>
There's not much here, but the strings are pretty self-explanatory. If a user is connected to Wi-Fi, it will be possible to download an update at any time. However, users connected to cellular data can look forward to automatically downloading their updates during off-peak hours, typically when most people would be asleep. This makes a lot of sense in countries where cellular data is incredibly limited and heavily metered. Many cellular services relax their data and calling restrictions at night to encourage customers not to overcrowd limited resources during the hours of peak usage.
Smart Lock (a.k.a. Personal Unlock) via Activity Recognition
Smart Lock (formerly Personal Unlock) was definitely one of the show-stoppers at I/O 2014. Not only does it give Android Wear a true killer feature, but it's just simply cool. Where proximity to Bluetooth devices would probably be considered the preferred and most common example of unlocking, it certainly doesn't have to be the only one. It looks like Google is playing around with the Activity Recognition features that were first introduced at Google I/O 2013.
<CheckBoxPreference android:title="@string/auth_trust_agent_pref_activity_recognition_unlock_title" android:key="auth_trust_agent_pref_activity_recognition_unlock_key" android:defaultValue="false" />
<string name="auth_trust_agent_pref_activity_recognition_unlock_title">Trusted behavior (experimental)</string>
Right now, there's just a checkbox to enable the option and a string to describe it, but the names don't leave much room for interpretation. This is a method of triggering Smart Lock by Activity Recognition. The label clearly identifies this as an experimental feature, which isn't surprising given how tricky this type of feature must be to get right. Unfortunately, there's no sign of code to drive this, so it's probably going to remain hidden
The question to ask about this feature is how it will actually work. Is Activity Recognition precise enough to identify the unique gait of a person's walk? Is this possibly something more akin to pattern unlock, where a user would shake their phone in a specific pattern to unlock? Both of those seem more like novelties than serious features, but it's not like Google hasn't shown off easily bypassed security measures in the past (i.e. Face Unlock). Just imagine, we might get to watch a Googler do the Hokey Pokey on stage to unlock a phone at I/O 2015. Seriously, who doesn't want to see that?
While there aren't any other new strings or distinct code elements worth calling out, I noticed a pretty substantial increase to the code for Kid Accounts, Android Auto, and a handful of other upcoming features. This isn't to say that there's anything new for these projects, per se; but there's definitely a lot of motion as Google prepares them for the public. We'll probably have quite a bit to see on-stage at I/O this year.