Google's developers took a couple of weeks off for the holidays – or from my perspective, they gave me a couple of weeks to rest – but now they're back and it's time for the app updates to resume. Naturally, it's time to breathe life back into the teardowns, and we're back with a big one. Google Search v4.1 began rolling out to users yesterday, and we've already seen quite a few little adjustments and improvements. After plenty of digging, a stack of additional changes have surfaced, including one that is already live, and several more just waiting for some finishing touches.
'Ok Google' Now Overlays Current Activities
Let's start with a feature that's definitely live already. If you're an avid user of the "Ok Google" command, you've probably flipped the switch to enable hotword detection everywhere on your phone. In older versions, speaking the key phrase with any other app in the foreground would immediately launch Search, sending the current app into the background. There was one exception, but only when the Google Now Launcher was on the screen. In this specific situation, users would see an overlay representing their interaction, with GNL remaining visible in the background. Well, now that overlay works everywhere, regardless of which launcher or application is active. (Thanks, Dominic Powell.)
Left: Old version. Center & Right: New version showing TouchWiz launcher and Play Store.
Search From The Lockscreen
With the introduction of Smart Lock for use with Bluetooth devices (and signs of more methods to come), and features like Screen Pinning to partially expose a select app, it seems like Google is looking to turn the lockscreen into a wall with many holes. It makes sense, because the lockscreen rarely adds usability, but it can certainly get in the way when we're in a rush. Google already has an option to turn on "Ok Google" even with a secure lockscreen enabled, but it looks like there will be some more granular options coming soon.
A small set of strings provide the clues for this one. These are all used as part of a preferences screen named hands_free_settings and specifically call for allowing search requests when issued through either wired or Bluetooth headsets.
<string name="search_lockscreen_pref_header">Allow requests with device locked</string>
<string name="search_lockscreen_bluetooth_pref_title">For Bluetooth devices</string>
<string name="search_lockscreen_headset_pref_title">For wired headsets</string>
<string name="search_lockscreen_headsets_confirmation_title">Make requests with device locked?</string>
<string name="search_lockscreen_headsets_confirmation_body">Someone else may be able to use voice commands, such as calling or texting, or access your address, contacts, and other personal information – even if your device is locked</string>
Note, the last string in that batch matches the warning that is now shown when enabling 'Personal results' on the lockscreen.
Alongside those strings, a couple of others might shed a little more light on how this feature will work.
<string name="hands_free_unlock_device_bluetooth">"Hi! To get started, you'll have to allow Bluetooth to work with your phone, which is locked. Here's how. Go to your Google App settings, choose Voice, and under Hands-free, turn the Bluetooth option on."</string>
<string name="hands_free_unlock_device_wired_headsets">"Hi! To get started, you'll have to allow wired headsets to work with your phone, which is locked. Here's how. Go to your Google App settings, choose Voice, and under Hands-free, turn the wired headsets option on."</string>
I highlighted the names of the strings instead of the text because they tell a more interesting story. Referred to as "hands free unlock," it would appear that the headsets will actually be able to initiate an unlock, perhaps via voice command, or just as a side effect of starting a query. The only piece of code that currently uses these strings is called HeadsetQueryCommitService.
Finally, a few new activities are likely connected to the strings above.
<activity android:autoRemoveFromRecents="true" android:excludeFromRecents="true" android:exported="false" android:name="com.google.android.search.lockscreenentry.LockscreenEntryActivity" android:process=":search" android:taskAffinity="" android:theme="@style/Theme.Velvet"/>
<activity android:autoRemoveFromRecents="true" android:excludeFromRecents="true" android:exported="false" android:name="com.google.android.search.lockscreensearch.LockscreenSearchActivity" android:process=":search" android:taskAffinity="" android:theme="@style/Theme.Velvet"/>
<activity android:autoRemoveFromRecents="true" android:excludeFromRecents="true" android:exported="false" android:name="com.google.android.search.dismisskeyguard.DismissKeyguardActivity" android:process=":search" android:taskAffinity=""/>
LockscreenEntryActivity is fairly dull, as is DismissKeyguardActivity, despite its obvious purpose. However, LockscreenSearchActivity is moderately large, and happens to load up the standard search box, which suggests that it might even allow for loading up a keyboard and typing in searches, if a user chooses to do so.
Hands (and Eyes)-Free Notifications
In the same batch of preferences for headset unlock, a few more strings emerge to indicate a long-awaited feature: vocalized notifications. There's not much to go on, but it's clear that this feature will generate audible notifications to be read aloud as they arrive. Based on the final option, it might be possible to limit output just to a bluetooth or wired headset, maintaining some level of privacy.
<string name="notifications_pref_header">Read notifications aloud when</string>
<string name="read_notifications_hands_free_pref_title">Hands-free is active</string>
<string name="read_notifications_headset_pref_title">Using Bluetooth or headsets</string>
<string name="read_notifications_headset_pref_summary">While Bluetooth devices or wired headsets are connected</string>
Naturally, this will be invaluable to drivers, or really anybody that is indisposed and can't take the time to focus on the screen of their phone when a new notification comes in. This brings us much closer to keeping both our hands and eyes firmly dedicated to driving while still giving us all of the necessary elements while driving. It's not like this hasn't been coming for a while (1, 2, 3, 4), but every step closer is a good thing.
Here's a little secret about doing teardowns, there are a few strings that come and go on a regular basis. They never actually make it into any live interface, and that's why they are typically ignored. Quite frequently, these strings represent the same items that appear in other apps, or even Android itself. This time around we have some that look like they belong to the quick toggles. You know, the icons that allow you to switch on and off Wi-Fi, Bluetooth, and maybe your flashlight. Those strings are back, which is no surprise. The reason this is interesting is that they also happen to be accompanied by iconography, and even an animated Wi-Fi logo. While these strings tend to be fairly transient –and even the images, too– it's rare to see both show up at the same time. There still isn't any code or resource that actually uses either the images or strings, so they could just as easily go away in the next release. Who knows, maybe there will finally be a card in Google Now, or possibly something in the launcher... It's possible, but don't hold your breath.
Socially Social Networking
One of the more interesting experiences with Google Glass comes from the first time sharing something to Google+, Facebook, or Twitter with just a set of voice commands. If a bundle of new icons are any indication, it looks like Google might be carrying that concept over to a mainstream product.
Each of the icons is actually named ic_post_<name>, which makes it fairly clear that these will specifically be used to add content to those networks. Before anybody asks, there is also an icon for Google+, but it's been there for a while, whereas these icons are brand new. There are still no layouts or pieces of code that make use of this set, so it's fair to assume that we'll have to wait for at least one more update before these begin to make appearances.
I actually don't have much to say about the rest of these icons. They're all new, but there's not much to add. May as well include them so you guys can take a peek, too.
A few months ago, I came across what appeared to be a mostly complete feature which would allow users to send some text from a desktop computer directly to a phone. Once on the phone, the text would exist as a notification until it was moved into the clipboard, saved to a note, or dismissed. It wasn't a particularly complicated feature, but it looked like it was ready to launch at any time. Google still hasn't moved forward on this one, but it seems that it hasn't been forgotten or abandoned, either. A few new strings and some additional code might be enough to get this one off the ground.
<string name="phonelink_clipboard_label">Note to self body</string>
<string name="phonelink_action_error">Something went wrong</string>
<string name="phonelink_link_my_phone">"Correct your phone's setup"</string>
<receiver android:name="com.google.android.phonelink.PhonelinkNotificationActionReceiver" android:process=":search">
These new pieces clearly share the same naming convention and resemble the actions described in the original teardown, so there's really nothing new to share; but this reinforces the likelihood that the feature is probably coming pretty soon. Hmm, déjà vu...
Project Hera Strikes Again
If there was ever a more confusing, less clearly defined, but so clearly real thing on Google's roadmap, it's definitely Project Hera. Almost one year ago Liam Spradlin shared details of an ambitious change that would close the gap between Android and the web. Subsequently, we've seen elements of the original rumor appear piecemeal, but there's been no clearly formed characterization of Project Hera. However, another clue popped up in this version of Search, and it gives us yet another link (no pun intended) to integration between Chrome and Android. A new layout was added with the name hera_to_gsa_transition. It resembles Chrome's Omnibar and has been inserted directly into the search_plate layout, which is the basis for the Google Search bar. Of course, the layout itself is less relevant than the functionality behind it, but the code is of little help in this case. Exactly how this relates to Project Hera is –as usual– still a mystery. Nevertheless, the search box, in all of its incarnations, now has a direct connection to Hera.
Project Hera isn't the only thing hinted at by a new layout. Version 4.1 also contains a fairly simple layout named third_party_welcome. The header image for this view presents a set of five cards, each with a distinct color and unique iconography.
It's only natural to assume that this is a sign that Google Now is opening its doors to non-Google developers. In fact, that idea would be further supported by a newly added class named TrustedTestService, which happens to reside within the newly added nowdev path. These could also be unrelated coincidences, and it's entirely possible that Google Now is nowhere near opening up to developers. It's also plausible, and even more likely, that Google is simply planning to open up Now just to select partners. Since the possibilities are fairly extensive and Google doesn't seem to be in a rush to add hooks into Now, it seems premature to spend much time speculating on this.
That's about it for this teardown. It's clear Google is preparing quite a few changes for the coming months, and there's definitely something for everybody on this list. It's only January, and there's already a lot showing up in the Search app, so by the time I/O rolls around, most of this list will probably be live and we'll have a whole new set of toys to look forward to. I think it's going to be a good year.