Android enterprise vs device administrator (legacy) enrolment

(Jason Bayton) #1

Originally published at:

If you’ve read What is Android enterprise and why is it used?, you’ll know Android enterprise (AE) offers several rather useful features and deployment scenarios to suit many business requirements. A recurring query when discussing Android enterprise is, as you might expect: How is it different from “standard” (device administrator/legacy) enrolment? The answer depends on whether we’re talking about standard, vanilla Android or Samsung. I’ll explain why: Vanilla Android What’s vanilla Android in this context? Basically any device not running Samsung’s Knox APIs – devices may be heavily skinned, have additional features over and above AOSP but as far as management goes, they’re essentially pretty much what you get when building from source. Out of the box, Android as provided by many OEMs offers almost (or) no management APIs for EMMs to leverage, simply because they’ve never – before Android enterprise – been included as standard in the Android source code OEMs use to build their device images. Some OEMs have over the years implemented their own APIs here and there for different capabilities that make for a partially manageable device, however this equally requires that EMMs choose to leverage these bespoke APIs for the functionality offered, which hasn’t always been the case. When they do, in addition to having to request device administrator permissions for the EMM agent, it’s not unlikely the EMM would require an additional in-house application is installed on the device to better leverage these APIs – that normally involves enabling unknown sources (via a user prompt) and sideloading…