Minded Systems

When Android met Chrome

It’s no secret that Android and Chrome have become closer than ever before. Its come so far that Android is pitted against an OS derived from the Chrome experience (in ChromeOS). Looking to apps, well Chrome has those too in a manner of speaking. Surely Google has a plan in all of this madness, right? After reviewing some evidence, I have come up with some thoughts.

For starters, this NOT Google’s first rodeo. They employ some of the smartest and most creative people in the world; and many of those people work on Android or Chrome (or both). Google will be aware of the convergence of these two platforms and almost certainly has a strategy at work to deal with it. SO, what’s the plan?

Here’s my theory as it currently stands: Google intends to use Chrome as a ‘universal app boilerplate’ within the Android ecosystem to create a level of ‘stock’ apps delivered through a default app vehicle.

Let’s start with the ‘universal app boilerplate’ part, what does that even mean? The web has matured ….. A lot. Most of today’s browsers support a wide range of technologies that enable all sorts of sophisticated functionality. Much of this can be used to perform app-like behaviors for loaded web content. Chrome is no slouch in this department either. Google went so far as to fork its own browser engine, Blink. Some games run entirely within Chrome, most notably for me is Google Maps Pac-Man. In that sense, Chrome can serve as a common delivery vehicle for basic or common style apps. There is already precedent for “universal app”-ing of this nature across the Android platform as well. Many apps advertising ” Android Wear compatibility” have simply included wear-optimized Android notifications. The Wear OS handles these generically with a set of canned views. Apps that require special functionality would need a more traditional app development cycle; code, compile & distribute. Android TV functions similarly, Chrome(cast) handles simple / standard media playback but games that require more intense rendering and other local-hardware operations are installed and run as a traditional app to be used within the runtime for the OS.

There is no debating that Android is a full fledged operating system. Looking at Chrome as a default app vehicle runtime makes defining ChromeOS simple; Android with just Chrome. The ChromeOS ‘desktop’ is an Android home screen modified to have status bar information in the bottom right and the dock in the bottom left. Settings and user/multi-user elements in ChromeOS  get pulled in from Android. And to get a bit nerdy, removing native Android app support alleviates the need to make the native app runtime (Dalvik or ART) fully compatible on the various hardware used in ChromeOS laptops and desktops as Chrome and its Blink engine can suffice.

Does Chromecast fit in somewhere? It sure does. It’s quite close to a ChromeOS device but it has no direct input. No touchscreen, keyboard, mouse, joystick, or anything. This configuration removes the home screen as there is no method of selecting an app and simply auto-runs Chrome as a result / alternative. Add back the native Android app support and a method of input, say a remote or game controller; you have yourself Android TV.

Pull back on the hardware resources a little more, the conversation becomes about internet-of-things devices and Google’s recently announced ‘Project Brillo’. I think of Brillo as JUST Android (with some IoT optimizations of course), no native apps or Chrome. Since there is no app runtime for developers to use on Brillo, Google included Weave. This provides a method for developers and devices to interact with Brillo devices, exercising OEM hardware functions (like turning on the lights or brewing the coffee) by calling them via the Weave protocol. Weave was acquired and developed by the Nest group. The resulting ‘psuedo-app’ allows the Brillo device to respond to app behavior without having any actual app being run. “Chromecast for app commands”, if you will.

So, what is the benefit to Google? In short, more developers. Using Chrome as a generic app vehicle instantly turns web developers into Android app developers. Doing so also lowers the barrier-to-entry for smaller web properties. Creating a native app is a financially significant task that many small business can’t afford. That said, most small businesses have invested in a web presence of some sort. Leveraging existing web developers, an already owned website and some Android-Chrome integration makes for a quick and easy native experience.

What differentiates a native app from a universal app then? Simple, a view-model that cannot be achieved by Chrome or unpredictable hardware availability (and even this part has its caveats). At its heart Chrome is a web browser and that’s the limitation. If the required layout can be expressed and rendered in HTML(5) and it doesn’t require special access to hardware (or potentially hardware not on the device) then its a candidate for being a “universal app”. Games that require intense rendering and other abilities beyond WebGL still need to be native. OEM apps that make use of device-specific hardware still need to be native. Apps that require complicated views that cannot be built in a web browser, like custom Android wear display configurations or non-standard feature controls; these must still be native. With all that said, Android apps already have many stock layouts available. Lists, grids, tabs, navigation drawers and other “standard” app layout objects. These are all achievable with modern web standards that can be delivered through Chrome. To facilitate the idea Google put out Polymer, a framework for building material design web interfaces for cloud applications. To make sure bloggers and other small business sites aren’t left high-n-dry they recently added the new ‘Material Design Lite’ or MDL libraries for a similar purpose.

The final shoe to drop in this tale will be the presence of Chrome apps in the Google Play store. While this is easily said the technicalities are not trivial. For starters, a “Chrome app” is more accurately a web application at some URL. The “Chrome Web Store” exists, but hasn’t received the kind of investment that I would expect to see from Google if it were meant to survive the long haul. On the other hand, having developers submit a URL to the Google play store for review and approval goes overboard; especially when it isn’t necessary because the overflow menu in the Chrome app already offers an “Add to Home screen” button to do exactly whats required. The recent “Mobilegeddon” may point to the answer in search. Collecting app-specific metadata from sites like icon information, push notification configuration, permission manifests and other components that may be defined could be used to scrape “Chrome app” configured sites for an store-like presentation of results. The move would signify a “two-tiered” app system and a sort of “house-warming party” at Android and Chrome’s place as they start their new beautiful life together.

Please provide a valid email address

Trackback URL

http://www.minded.ca/2015-07-26/when-android-met-chrome/trackback/