Google I/O 2015

Why the boring Android M is good news for IT

The few changes at worst do no harm to IT and in some cases may make things a little easier or safer

IT likes systems to be stable and not change, which is why it took a decade for most enterprises to begin replacing Windows XP with Windows 7, and why Windows 10 may not get widespread enterprise adoption until 2020. But in mobile, the major OSes change every year, and IT has much less control -- often, no control -- over what OSes are in use.

So, Google's Android M, announced yesterday, is a comforting update for IT. Android M is a minor update to Android 5.0 Lollipop OS that was announced a year ago, was formally released in November, and began appearing on mainstream devices only in February. It should have few, if any, implications to IT when it ships this fall and starts showing up on mainstream devices next winter.

Overcoming flaws in today's Android

Google says the focus for Android M (its candy-themed formal name will be revealed this fall) is on stability and quality. In other words, fixing lots of bugs and poor design choices. Google hasn't said much about what it will fix, other than promise to improve battery life for devices in standby mode. Power efficiency has long been a big weakness in the Android platform.

Giving users more control over app permissions

In terms of functional enhancements, Android M will change its app permissions model to be like that of Apple's iOS. That means apps will ask for permission to use resources like the microphone, calendar database, contacts database, and camera when first needed, when users can better judge whether to agree to that request.

Earlier Android versions presented an all-or-nothing list of requested access during app installation, which meant apps often were granted permissions that users didn't understand. And that let nefarious apps gain access to information and hardware that could be used to spy on or phish users.

Android M users will be able revoke those privileges once granted, as they can now in iOS. But it's unclear whether they can grant and revoke individual access permissions per applications, as iOS allows.

Directing users more easily between apps and the Web

Another significant change in Android M is the notion of app linking, which lets developers essentially associate their Google Play Store apps to the app provider's domain. Then if a user accesses a service from a link on a Web page, in an e-book for content item, or in an app, Android will offer the user the chance to open the service on the Web or to use or install the corresponding app instead.

Both Android and iOS do some of this app detection now, but Android M will let developers bake the associations more deeply into Android, to remove the mental separation between apps and Web services.

For IT, this could mean more users are prompted to download apps for services they normally access from the Web, which some might consider a management problem. (I do not, since IT can still use an MDM tool to manage app access.) And it could mean users are more easily pointed to a Web service for apps that aren't installed (or that IT blocks), again threatening IT's control. But that control is illusory; users can simply use something else to get what they want, so why drive them out of your visibility?

Moving app backups to users' Google Drive storage

Finally, Android M can back up user data in apps to users' Google Drive accounts so it can be restored if a device is wiped, reset, or replaced. Previous Android versions had a different mechanism to do the same thing; what's different here is that the data is now backed up to the user's specific storage location at Google, not to a developer's storage space at Google.

Many IT folks will get upset by the mention of Google Drive, since many view cloud storage as evil. But you need a Google account to use Android, so whether IT likes it or not, users have Google accounts and access to them. 

Copyright © 2015 IDG Communications, Inc.