The annual Google I/O developer event is nearly upon us. The conference, which takes place this Thursday and Friday in San Francisco, is Google's public planning session: The company outlines all of the software tools developers can use for Google platforms, services and software.
Last year, Google showed off an early look at Android L, which later launched as Android 5.0 Lollipop, the new Material Design look for Android, Android apps on Chromebooks, the Google Fit health platform and more.
So what's in store for this year? We'll find out later this week, but here's what I expect.
Android M where "M" is for More refinements
There's nothing surprising in the fact that Google will surely give a glimpse of the next Android version. I say "glimpse" because I don't anticipate Google will launch the new software.
Instead, the company will highlight new features that will arrive with Android M. Most visual changes will likely be incremental at best since there are still apps that don't yet use the Material Design look and feel introduced last year.
I wouldn't expect many changes to be unveiled here but there should be some mention of them at the I/O keynote, along with a possible example or two.
With so many apps now competing for our attention on phones, tablets and watches, I think the burden is on end-users to better manage which notifications do and don't pester them in general. I'd like to see time-based settings on a per-app level however: Maybe you only want Twitter notifications during non-work hours for example.
Personal identity and payments across the platform
But of course, that API is limited to Samsung devices. If Google wants all of its hardware partners to use a similar sensor, it really needs an Android-wide method to do so. One solution for the platform is a better approach than requiring each individual hardware partner to create -- or re-create -- a way to use fingerprint sensors for identity, app purchases and more.
The name change alone would send a subtle message to Google's hardware partners that all Android participants can benefit from a single payment platform. Android Pay could also let all of Google's hardware participants to work with a single NFC solution for payments, making it easier to add to the service to a phone, tablet or watch.
Can you hear me now?
Look for developers to get access to more voice actions at this year's event too. Recently, Google added more voice command support for a limited number of third party apps and it should expand that number this week. Again, the Google I/O schedule gives us the big clue here, with a session called "Building voice actions for your Android app" and this description:
"In this talk, attendees will learn how to drive traffic to their Android app using voice actions. We'll cover how apps should inform Google which "OK Google" requests they can handle on phones, tablets, and watches."
Google Now looks to be the platform these voice actions will work though on phones, tablets and Android Wear watches. The latter is the biggest area for opportunity, I think: Finding an opening an app on Google-powered watches can be frustrating.
Well, at least in once sense: The company did debut Android@Home back at the 2011 Google I/O event but not much came from it.
The difference now is that the IoT market is quickly maturing. Four years ago, Google had lofty goals that may have been ahead of their time. Now, we're seeing connected devices for sale in mainstream stores such as Target, Lowe's, and Staples to name a few. So IoT awareness is on the rise. Also helping in that regard is Apple's HomeKit platform, which we should see a few devices support next month.
I anticipate Brillo takes the bare-bones of Android -- particularly the communication, notification and messaging aspects -- and readies them for low-power devices with minimal hardware resources. This would give Google a single platform for device control as well as a way to capture that all-important information from connected appliances, meters, thermostats and more.
Google eventually did this with Glass, bringing a MyGlass app to iOS, so there's a precedent here.
But one of the benefits of the iOS platform is that its very cohesive. By that I mean it has deep ties with OS X in Apple's Continuity and Handoff features, for example. Most iPhone owners see the benefit of going "all in" with Apple and would be more inclined to simply buy an Apple Watch over an Android Wear device even though the latter can be much less expensive.
And I'm not sold that an Android Wear app for iOS -- I'm guessing it would be called MyWear -- will be able to support all of the same features as an Apple Watch because Google won't have access to some of the low-level APIs, sensors and other data that Apple's own watch has with iOS devices.
While I use both Android and iOS devices and would appreciate the cross-platform support for an Android Wear watch, I'm not certain it's worth Google's effort in the long term.
Using both headlights to show off Android Auto
I'd be surprised if at least 15 minutes of the Google I/O keynote isn't devoted to Android Auto. While the platform itself isn't new, now is the time for Google to build momentum with it and show developers how to leverage the in-car system.
Google has already shown off how messaging apps can work with Android Auto. Look for software and service partners to be front and center showing ways to get streamed content to the car through voice and touch interactions that don't require use of a phone. I also wouldn't be surprised to see additional demos and news from automobile partners.
The company hasn't really pushed this as quickly as I had hoped however. Every few months another handful of Android apps gain compatibility, but not enough to address concerns by potential Chromebook buyers that they'll have a wide range of apps to use.
There's nothing on the Google I/O schedule that hints at changing this but I suspect Google has something in the works to address it.
Microsoft actually has the upper hand here in one regard: Porting an Android or iOS app to Windows brings a massive potential audience. In contrast, Chromebook sales aren't yet cracking 10 million a year. I'm looking for Google to get Android and Chrome OS working together in a way that adds more value as a way to show developers there's a reason to get their software on both platforms.
Regardless of apps, I do expect Google to find additional ways to tie Android and Chrome together. As of today, you can unlock your Chromebook with a trusted Android device, get Google Now cards on both devices and sync browser tabs between the two. Google would be wise to add more ways to bind these platforms together to offer the benefits of a cohesive device ecosystem.
And speaking of Chromebooks, I'd look for Google to highlight its progress on improving the touch capabilities of both the platform and partner devices that use it. The new Chromebook Flip ought to get some on-stage time and is the closest thing we have yet to a Chrome OS tablet; something I've been hoping Google would work towards for the past few years.