Blog Post

Google’s new message to developers: don’t screw up Android

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!

Cars, watches, TVs: Google (S GOOG) is bringing Android everywhere, and it wants to provide consumers with a consistent experience across all devices. That expansion across multiple platforms was on full display at Google’s I/O developer conference in San Francisco last week, where the company touted its new Material Design principles as the thread that ties all of these platforms together. But the bold new design and ambitious expansion came with an overt message to developers: Don’t screw this up.

Photo by Janko Roettgers/Gigaom
Photo by Janko Roettgers/Gigaom

Google has traditionally touted Android as the open alternative to iOS(s aapl), with fewer restrictions and without Apple’s tedious app approval process. But as the company is extending Android to additional platforms, that open spirit is increasingly making way for a more guided, restrictive approach.

Not only is Google putting limits on what its hardware partners can do with these new products, preventing them from customizing Android TV and Android Wear devices with custom skins, it is also increasingly influencing how developer’s apps will look and what they can do on these devices.

In some cases, this is done simply by giving developers tools to more easily develop apps that look good on the targeted platform. In other cases, Google has gone even further and redefined what apps are and how they have to look. Here’s how this approach, which you could describe either as more guided or less open, depending on your point of view, plays out across different platforms:

Android TV comes with Leanback, a framework that lets apps look like Google would like them to.
Android TV comes with Leanback, a framework that lets apps look like Google would like them to.

Android TV. Google’s new TV platform, which was officially unveiled at Google I/O, comes with a framework called Leanback that developers can use to quickly get their Android apps up and running on the TV screen. Apps built with Leanback all offer a similar look-and-feel, with a left sidebar navigation for content categories and content galleries that users can scroll through horizontally. Leanback isn’t mandatory for Android TV developers, but Google strongly recommends using it.

Android Wear. The Android Wear experience is heavily focused on notifications. Developers can elect to extend the notifications of their Android phone apps to the wearable device to show users that they got a new mail, message or tweet. Google has tightly defined how these notifications are going to look, and what features developers can offer to interact with them. Developers can also write full-blown Android apps, but once again, Google offers them a guiding hand to make sure that their apps don’t ruin the experience.

Photo by Janko Roettgers/Gigaom
Photo by Janko Roettgers/Gigaom

Android Auto. The in-car platform introduced at Google I/O last week is likely going to be the most restrictive new Android platform. Here’s Google’s official sales pitch to Auto developers: “Integrate your content with easy-to-use APIs and let Android Auto take care of the rest.”

Android Auto only offers developers minimal app customization options.
Android Auto only offers developers minimal app customization options.

In practice, this means that developers won’t be able to run dedicated apps on the platform at all. Instead, Android Auto will simply connect to existing apps on mobile devices and display their content in a highly defined fashion. Customization is limited to using different logos, theme colors, background images and icons that are then rendered by Auto.

Glass. It’s no accident if Google’s approach towards wearable devices and in-car integration in particular sounds familiar. Google first experimented with a more restrictive approach towards development when it introduced Glass to developers last year, only allowing them to launch cards through the Glass Mirror API. The company eventually launched a more robust SDK to develop full-blown Android apps for the device, but still closely keeps a tab on what developers can and cannot do. Facial detection or ads are a no-go, for example.

Chromecast. Google’s first successful foray into the living room isn’t billed as a running Android but instead as a Chrome OS device, even though some differ on its heritage. Still, it’s another example of Google tightly controlling development. Chromecast doesn’t offer developers any way to load full-blown apps on the device. Instead, it runs what amounts to web apps in a browser, which are controlled by existing mobile apps as well as web apps running in Google’s Chrome browser.

Photo by Janko Roettgers/Gigaom
Photo by Janko Roettgers/Gigaom

Developers have to follow certain guidelines to integrate casting into their apps, and users on unsupported platforms — think Windows Phone(s msft) or native desktop apps — are left out. That point alone has prompted others to step up and try to compete with Google, as is the case with the Firefox OS-based Chromecast competitor currently being developed with help from Mozilla.

Is Google abandoning its roots, or finding its way?

Chromecast may also be a good example on why Google went down this route. The company failed with its Google TV platform, which tried to entice developers to build full-blown Android apps as well as web apps with few restrictions. There are many reasons why Google TV failed — but Google’s attempt to bring the entire web to the device, which led to the decision to ship the first devices with traditional keyboards and overly complicated remote controls, certainly played a role.

The company has since learned that not every device is alike, and that things that work well on the desktop or even a mobile phone may make no sense whatsoever on a TV, an in-car dashboard or a watch. Google also learned from working with big handset manufacturers like Samsung and thousands small-time Android app developers alike that it won’t be able to offer users a consistent experience across apps and devices if it doesn’t put down its foot every now and then.

Photo by Janko Roettgers/Gigaom
Photo by Janko Roettgers/Gigaom

That development has coincided with an internal refocus on design, which began with a more consistent design language of Google’s own apps across Android, iOS and the web, and has led to Material Design — arguably the most ambitious redesign of Android since its launch.

One could argue that this process is leading to Google becoming more like Apple, and we will certainly hear more from developers who don’t like what they’re being fed. But when I talked to developers at Google I/O last week, the response was more positive. Because in the end, being more like Apple may be what Google needs to succeed in the car, in the living room and on your wrist.

Image courtesy of Flickr user carlstr.

3 Responses to “Google’s new message to developers: don’t screw up Android”

  1. The point on Google clamping down on developer freedom is greatly disturbing. The primary reason I use Android is because of its open source roots and fairly robust developer network that facilitates quality application development. Migration to the draconian, super-max lockdown system employed by their most prominent competitor is a step in the wrong direction and an affront to a good portion of the Android user base that holds dear the concept of open source development. I certainly hope that this does not progress further, but given the profit potential inherent with locked up eco-systems, I highly doubt that this is the end of this trend.

  2. richbordoni

    Google is being very careful around Android Auto because there are big regulatory issues around that kind of tech in cars. People obviously do dangerous (distracted) stuff on their Android handset while driving but now that it’s baked into the car itself the Department of Transportation can come in and say that it’s within their purview to regulate to keep people safe.

  3. I think Google is definitely finding its way here. Like you cited, Google TV failed because expecting developers to take the risk to build out a full app UI/interface is just unrealistic when an ecosystem is starting out. More than just the design guidelines, I feel that Google has really started to figure out how to build out these new platforms that have failed and they’re pushing hard for their approach.

    One thing Google mentioned during the I/O keynote was that this whole approach is centered around Mobile (i.e., the phone), which to me seems to be pretty central because it recognizes that the smartphone is something that (at least right now) people understand and connect with, whereas with TV/wear/auto, the app ecosystem is still unfamiliar to most people.

    So the whole approach of keeping just one app ecosystem–with one APK file being used for the app across the entire phone/tv/wear/auto platforms–this is going to help developers expand out onto these new platforms. And so, while it might seem restrictive for Google to tie everything together one design guide or to the smartphone ecosystem, it really gives these new platforms a chance to flourish and gives devs an easier path forward to these platforms.