New Android Q features could relieve IT headaches

With the release of Google Android Q, IT departments should prepare for changes that accompany the new OS.

One of the biggest new Android Q features involves work profiles on corporate-owned but not fully managed devices. This mobile deployment option is similar to corporate-owned, personally enabled (COPE), but in this scenario, organizations take a minimalist approach to management. Perhaps the most significant deprecation is for Device Admin. Android Q features a new management API to replace the longstanding Device Admin API.

In this Q&A, Jason Bayton, owner of Bayton.org, provides analysis on the new Android Q features, major deprecations and other Android Q-related news.

What Android Q features are you most interested in?

Jason Bayton: One of the big features that [Android] is introducing is zero-touch capability for work profile devices. We've never had a low-effort way of properly deploying corporate devices with a work profile. Samsung Knox Mobile Enrollment was an option, but that isn't universal.

Organizations may only care about the corporate data on a mobile device, and [they are] not interested in managing the personal side at all. They're happy to forego the limitations on device restrictions in favor of just having devices that users can use as they want.

This method is not necessarily something that I've advocated for in the past because it makes more sense to go down the COPE road and put profiles on fully managed devices whenever possible. COPE is the closest deployment type to legacy management, and IT manages the full device and puts a container on there for corporate data. 

Nonetheless, [zero-touch for work profiles] are obviously popular, and Google thought, 'We'll make that possible.' So now you can take the corporate-owned device, put it into zero-touch [enrollment], and you can depict which direction that flow goes as long as the enterprise mobility management [EMM] supports it. [The enrolled device] either goes into fully-managed or a normal device with a work profile. It's all about flexibility, and it's popular enough to warrant Google to add it to Android. It's going to help a lot of people who wanted that option. 

I like the ability to manually handle system updates, especially in corporate environments where the network is not up to the job or limited on bandwidth. You can pull down the system updates from its source and manually push it out to devices [via EMM] within your network.

For organizations with warehouses and supermarkets where there are a lot of devices that all pull for the latest update, admins could only push back the install and delay the update for a bit. Ultimately, those devices are going to connect to the network and pull that update. That may take 800 [MB] per device. It is absolutely going to annihilate the network for the period of time it takes to go on if they're all  pulling at the same time, which is not unheard of. 

I like the ability to manually handle system updates, especially in corporate environments where the network is not up to the job or limited on bandwidth.

The ability to pull updates down manually and push them via EMMs over the local network where it doesn't have to go through the [over-the-air] servers or anyone else is great. A lot of network admins will be very happy because it can save them a lot of headaches.

Do you have any major concerns for Android Q, such as feature deprecations?

Bayton: Device Admin being deprecated is going to be one of the most disruptive things that comes with Android Q. [The problems] won't happen as soon as devices upgrade to Q for now. There's a requirement for Android Enterprise Recommended EMMs to target the Q API level by the start of 2020. Any devices that come out today won't be affected whatsoever.

When the EMMs do update their device policy controllers to target that Q API level, then we'll see Device Admin APIs [causing] an exception when invoked [by IT]. [Google is] giving people some time to adjust, but organizations need to get off Device Admin as soon as possible. Even if you are not affected right now and you're running Android Oreo or Android Pie devices that are never going to see Q, you still have to think of the devices in their last year of support that may need a refresh.

I'm sure there are still organizations that don't know about this, and they will be affected. I don't think there's any documentation or blog post in the world that's going to catch everyone.

How will the deprecation of Android Beam for near-field communications [NFC] affect organizations?

Bayton: I'm a big fan of Beam, and so I wasn't very happy to see it's being deprecated. In reality, the device to device bump isn't that great of a loss because a lot of big or more advanced deployments will purchase NFC tags and they'll just have the devices provision with a bump on those tags. For larger deployments, that functionality will carry on working through alternative means and is not going to cause a headache, but for the admin who sits in the office and does some very quick testing, that's not going to work anymore unless some specific OEMs decide to carry on support.

I'm disappointed to see that it's being dropped, but, at the same time, it won't have a massive impact on anyone in the grand scheme of things. An NFC tag is about 25 cents, and they're even cheaper if you buy in bulk, so you can keep some of the same processes in place.