Update Wednesday wasn't particularly active this week, but Google did push a few bug fixers out before the day was done. While most of the apps only saw minor version revs with little more than minor tweaks, Chrome Beta 41 came down the pipe with some noteworthy improvements like pull-to-refresh and an option to block only 3rd-party cookies. However, it turns out that those weren't the only new bits to be found in this release.


Kid Accounts, Again

A couple of months ago, Google Play Services 6.5 landed with a handful of new bits and pieces, including the first signs of a feature referred to as Kid Accounts. This will give parents control over their children's use of the devices they have been given. Now some similar strings have been added to Chrome Beta that make it pretty obvious it will be hooking into the same system, giving parents control over the content their children can access on the Internet.

<string name="fre_signed_in_description_uca_addendum">Your parents help manage these settings.</string>
<string name="kids_account">"This is a kid's account"</string>
<string name="account_management_parental_settings">Parental Settings</string>
<string name="account_management_no_parental_data">Waiting for details of parents.</string>
<string name="account_management_one_parent_name">This account is managed by %1$s.</string>
<string name="account_management_two_parent_names">This account is managed by %1$s and %2$s.</string>
<string name="account_management_child_content_title">Content</string>
<string name="account_management_child_content_approved">Only approved sites</string>
<string name="account_management_child_content_all">Uncontrolled</string>
<string name="account_management_child_safe_search_title">SafeSearch</string>

There's not much to take away from the strings, but it's clear that Google wants to enforce the idea that a browsing session is completely at the mercy of a child's guardians. The only pieces that look like settings, as opposed to just warning labels, come at the very end. It will be possible to enable Google's Safe Search, and to restrict children to just approved sites. It's not really clear if there will be a smart filtering option, or if parents will have to manually build a pre-approved list, but it's an important feature to have.

Here's the lone icon that will be used to represent a kid account.


Now that we're seeing the first sign of a regular app including parental controls, and not just Play services, we might be getting closer to the launch of kid accounts.

Samsung AirView Support

Google's engineers seem to shy away from supporting OEM-exclusive features, but every once in a while they make an exception. This time, it looks like Chrome for Android is going to take advantage of Samsung's AirView technology. For those who don't remember AirView –or more likely, aren't sure which one of Samsung's countless features it refers to– Samsung has a fairly extensive set of examples in the support docs, and a few awkward demonstrations on YouTube. To put it simply, AirView is a technology that allows certain Samsung phones and tablets to detect a finger or stylus when it is held within a few centimeters of the touch-sensitive screen.

The relevant code is pretty simple, just a flag in the Android manifest that tells the OS to forward hover events to certain screens on the app.

<action android:name="com.sec.android.airview.HOVER"/>

I've examined the code, and there's no sign that Chrome Beta is actually doing anything with those hover events. Still, this isn't the kind of thing that would be added unintentionally, so it's clear Google plans to do something with AirView. So far, there's nothing to indicate how the Chrome team will use this technology on the browser, but we'll probably see something soon enough.

Note: Before anybody asks, yes... If you hover over the buttons in the UI or the text in the omnibar, they do respond. Everything worked the same way in previous versions, before the addition of this flag. Samsung achieved this through modifications to Android, and the Chrome team would only add this flag if there is an intention to override the default behavior.

Yet Another Bookmark Manager?

If you're even remotely following along, this is a weird one. At the beginning of December, Google added a flag so users could switch to a new and more stylish bookmark manager in Chrome for Android. (Yeah, I don't like it either.) Now, barely 2 months later, it looks like there is yet another bookmark manager in the works. Having been named "Enhanced Bookmark Activity" it seems like it would be a replacement for the current interfaces, or it may even extend the existing features.

<activity android:configChanges="keyboard|keyboardHidden|orientation|screenSize" android:name="com.google.android.apps.chrome.enhancedbookmark.EnhancedBookmarkActivity" android:theme="@style/EnhancedBookmarkActivity"/>

Is this yet one more bookmark manager? Could this be an "enhanced" version that is only available to certain users or types of devices? Maybe somebody wasn't happy with the old code and decided a total rewrite was in order. Right now, there's not enough to make a strong prediction; but I would like to think this is linked to Stars, Google's completely redesigned engine for managing bookmarks.

Notifications via Service Workers

Last month, Google posted about supporting a fairly new web API called "Service Workers." Basically, it's one more attempt to provide a platform for web apps to run offline. This time around, there are some much more compelling features that could allow crazy stuff like push messaging and background sync, even while web apps aren't even open and running. Support is still really limited, but the Chromium project is making good headway.

Of course, these features won't be that useful if users don't know things have happened in the background. For that reason, we need notifications. There isn't a lot here, but a service and receiver have been added to handle the interaction of a user tapping or clearing a notification.

<service android:exported="false" android:name="org.chromium.chrome.browser.notifications.NotificationService"/>

<receiver android:exported="false" android:name="org.chromium.chrome.browser.notifications.NotificationService$Receiver">
<action android:name="org.chromium.chrome.browser.notifications.CLICK_NOTIFICATION"/>
<action android:name="org.chromium.chrome.browser.notifications.CLOSE_NOTIFICATION"/>

Right now, evidence that this is specifically tied to Service Workers is a little thin, but there's enough to make an assertion, and not many other reasons for Chrome to post notifications on Android. Since the entire platform of service workers is still in its infancy, we're probably not going to see much happening here for a while. Frankly, I wouldn't expect anything until this summer at Google I/O, at which point, I'm anticipating this will be a pretty hot topic for the web developers in attendance. Speaking of... Can we get an announcement, Google?


Credit Card Camera Thing

One of the cool new features that can be enabled through chrome://flags is a handy trick for filling out forms that require a credit card. If enabled, users can take a picture of a credit card and have the information filled directly into a form without the pain of tapping everything out manually. This was already mentioned on our apk download post, but since the feature doesn't seem to be working for anybody yet, I wanted to include the FAB icon here in the teardown so people know what to look for.



Chrome for Android is rarely a source of good teardown material, especially since so much of the app is built around a completely open source project, but every once in a while it can surprise us. Support for Kid Accounts and Service Workers give promising indicators of pretty smart improvements. We might also have something big coming to the bookmark interface. And then there's upcoming AirView support, which is totally out of left field. This was an interesting update, so maybe we'll start to see more stuff happening for Chrome in the future.