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.
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.
As it stands now, only 9.7 percent of all devices hitting the Google Play Store are running Lollipop and hardware partners are still working on their upgrades to change that.
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.
The software won't look dramatically different then but have refinements and improvements in multiple areas, which should make ZDNet's Chris Duckett happy.
Look for Google to highlight security in Android, either through Android M itself or through a Google Play Services update in the coming months. Instead of applications simply showing the permissions the software has access to, users will likely be able to specify and customize which permissions and data and app can use.
While notifications got a nice upgrade last year in Android 5.0 Lollipop, Google clearly hasn't stopped working on improvements. The evidence of that is found right in the Google I/O schedule which shows an informal talk to be given twice this week called "Notifications, Interruptions and Volumes: Coming Attractions."
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.
Fingerprint sensors are another area Android M is likely to highlight. Currently, Samsung has an API for developers to tap into a fingerprint sensor.
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.
A platform-wide identification API could potentially be integrated with Google Wallet which Ars Technica reported in February may be changed to, or supplemented by, Android Pay. If that happens, I think it's a smart move.
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.
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.
Just last week, we heard rumors of Brillo, a likely Android-based platform for the Internet of Things (IoT). I'd expect this to be part of the keynote announcement, since it's a new area for Google.
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.
There have been some rumors -- even some code snippets -- to suggest that Google will bring its Android Wear companion app to iOS. If it plans to do so, this week is the right time. I'm not convinced it will bring much benefit, however.
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.
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.
The 2016 model year vehicles are just around the corner, for example. And as we found out earlier this month, in-car connectivity is going to be big: A one billion dollar business for AT&T alone in the U.S.
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.
Last year, Google demonstrated a way to run Android apps on the Chrome framework; a handy way for me to actually run Skype on my Chromebook Pixel.
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.
The company faces a challenge similar to that of Microsoft: How to entice app makers to port or convert apps from one platform to another.
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.