While it’s indeed true Android Enterprise was introduced as Android for Work with Lollipop (and supported even earlier with the app (but we don’t talk about that), Android Enterprise was an opt-in feature with little uptake and a lot of teething issues. From Android Marshmallow (6.0) it became a mandatory requirement.

In other words, Marshmallow is chosen as a reasonably reliable reference point for when Android Enterprise was guaranteed to be widely supported. There will be OEMs that can confidently state they supported it from Day Zero, however few did.

This is already handled with existing permission management capabilities in EMMs, Click here for more details on the change.

No.

An Android Enterprise bind is undertaken with only one EMM at a time. Under all normal circumstances attempting to bind with the same Google account on another EMM will return an error stating an Enterprise already exists.

It is possible to unbind from one EMM and then bind with another, however this will delete the existing Enterprise and create a brand new one, losing all approved applications, etc.

The only exception to the above is in high availability and/or disaster recovery scenarios where an instance of an EMM may be replicated, but no two EMMs should be generating managed Google Play accounts from the same Google account simultaneously.

For an in-depth take on this, check out:

• Android Enterprise vs Device Admin: Why DA is no longer suitable
• What is Android Enterprise?

In a nutshell, device admin was introduced with Android 2.2 as a means of granting admin permissions to applications. Any number of admins can sit on a device and have excessive, often unnecessary control. It has been widely abused by PHAs (malware, etc) and is very limited in scope of capability, leaving each OEM to build upon it in a fragmented and difficult to support manner.

Android Enterprise takes a more sane approach to device administration by permitting only one owner on a device at a time with scope for task delegation to other apps as defined by the management server, this approach is fundamentally more secure and easier to support as the APIs are universal cross-OEM.

Add in features such as no Google account management, silent app distribution, managed system updates, simple provisioning and streamlined enrolment, and it’s easy to understand why Android Enterprise is basically better in every way.

The account type chosen can have a significant impact on enrolment if not done so correctly.

User based accounts are tied to an EMM user and will be used across all devices enrolled by said user.

Device based accounts are created per-device irrespective of the user the device enrols under.

In either scenario, that standard limitation of 10 devices per Google account applies, therefore if using one EMM user account to enrol many devices – a common staging exercise – it is imperative device based accounts are selected.

How these account types are changed is EMM specific, so do reach out to your EMM vendor for instructions.

Yes.

Since Android 5.x (Lollipop), like all other OEMs, it has been possible to deploy for free a work profile or provision a fully managed device using Samsung devices and a preferred EMM solution. From Android 8.0 and Knox 3.0, Samsung further integrated AE by having the Knox Workspace container use the Android Enterprise Profile Owner APIs to inflate the Workspace, and as of late 2020 also began supporting zero-touch in addition to their existing KME service. Customers can optionally select to activate a Knox Platform for Enterprise license to enable premium features on the device, including all of the APIs from the previously separate Knox Standard, Knox Custom and Knox Premium SDKs.

Officially no, these devices are not officially supported for Android Enterprise and therefore would be expected to be managed using the legacy and mostly deprecated Device Admin APIs. These devices may also be referred to as AOSP, and an excellent example of an uncertified, AOSP device is the Kindle Fire.

Unofficially without GMS certification modern Android devices do allow for limited Android Enterprise management with an EMM that supports closed network or non-GMS management, but your mileage may vary.

No.

Unless you are already a G Suite customer, you can use your EMM console to register a new Android Enterprise organisation with any existing Google account and your EMM will create unique and generic managed Google Play service accounts on each Android device that allow you to sign into the Google Play Store and receive configs & policies. These accounts are silently added to the device. You do not need to configure your domain, create users, or manage the authentication to services like Active Directory.

This question comes up often and isn’t always simple to answer.

Organisations ideally need to understand the use case for the devices to be selected. This could be normal knowledge worker devices for employees needing a corporate phone, something tough (doesn’t need to be rugged) to withstand harsher environments, or something bespoke such as a kiosk on a reception desk used for checking in or something with an integrated printer/scanner.

After this, the minimum OS required for what the organisation wants to do, for example setting a passcode on a work profile (a challenge) requires Android 7.0, ensuring that passcode cannot be the same as the device passcode requires 9.0. More of these comparisons are made in considerations when migrating from device administrator to Android Enterprise.

Once determined, the best place to start looking is the Android Enterprise Recommended list. If nothing suits requirements, get in touch and I’ll try to help out!

Android Enterprise was introduced with Android 5.0 Lollipop under the moniker Android for Work.

With that said, very few OEMs originally supported Android Enterprise in the earliest days of its existence; Android Enterprise was not a component of the Android Compatibility Definition Document (CDD) nor did Google throw any significant weight behind it. It is commonly considered a mandatory requirement from Android Marshmallow (6.x) and above, with reasonably universal compatibility almost guaranteed from Android Nougat (7.x).

If considering support for older versions of Android today, AE compatibility should be only one small factor in the decision. Other considerations should include:

• Android app compatibility for enterprise applications
• Security update support, for which only Android 10 and above is currently subject to Google's security backport support. Any older versions of Android require manual backporting by the OEM and cannot be guaranteed.
• The OEM and their commitment to security updates and support
• Management/API support for the Android Enterprise solution set, for example zero-touch is only supported on 8.0 and later.

For details on the changes to COPE in Android 11, please read Android 11 COPE changes.

Android 8-10 – Yes, for work profiles on fully managed devices, however this would need to be supported by the EMM. VMware Workspace One UEM can do this for example by uploading an APK to the console, though there are no current examples of EMMs being able to push Google Play applications to both profiles.

Android 11+ – No, this is not supported for work profiles on company owned devices.

Yes, however this requires EMM support. I am not aware of any EMM that supports this today, despite it’s incredible value particularly to early Android Enterprise adopters.

Where the EMM does not support this, or the device runs Android 11, the organisation would need to retire and reprovision the device.

Android 8-10 – My normal advice, where supported through DPC extras (so NFC, QR, zero-touch, but not DPC identifier), is to enable system applications on COPE devices.

Organisations are providing a device provisioned for personal use, and as such the closer to stock it feels, the more familiar users will be with using it.

Most EMMs support the ad-hoc management of system applications, so there’s no reason bloatware can’t still be disabled, but things like system gallery, calculator, health apps and other OEM app suites being enabled should be harmless outside of the secure work profile.

Android 11+ – While there is still application management to a degree, the act of enabling or disabling system applications during provisioning is no longer supported.

Yes.

As of 2020, Intune supports work profiles on fully managed devices from Android 8.0. This is because Google’s Android Management API introduced support for the deployment scenario (albeit silently, intentionally avoiding stating as such in it’s wider Android 11 COPE announcement).

Android 8-10 – Yes. This is because the DPC sits both in and outside of the work profile normally, and the DPC will collect an app inventory surrounding it. Organisations can opt to disable this within the EMM under a privacy policy, and EMMs may even disable it by default, however do consider there is a privacy consideration when installing personal applications.

Android 11+ – No, this is because in Android 11, work profiles on fully managed devices was deprecated in favour or work profiles on company owned devices. This new deployment scenario aligns the privacy aspect with that of a work profile deployment, because it sort-of is one.

A reseller has the ability to upload any devices through their reseller portal, however it is their obligation to ensure that the device identifiers (IMEI or serial) are correct and that the organisation in question owns the devices, not another organisation or an employee. If the organisation does own these devices, can prove this, and can supply accurate device identifiers, please discuss this with a preferred reseller for assistance. It is up to the reseller if they wish to upload devices already purchased since there are consequences for resellers who upload incorrect data to the zero-touch portal.

This will change in future.

As of late 2020, all Android Go devices support zero-touch through expanded zero-touch availability. Prior to this, Android Go supported zero-touch on an opt-in basis. Validate support ahead of bulk purchase.

No.

While zero-touch is mandatory for Android Enterprise Recommended, devices that don’t meet Google’s requirements for storage or spec can and still do support provisioning via zero-touch.

Yes, via the CSV template provided, or the customer API

Yes, either by requesting a new account from a new reseller, or adding a new reseller through the existing console.

Nothing until the device is reset, at which point the new config will apply.

No, it is a free service, from Google at least. Reseller partners can choose to charge for this service, or bundle it as part of other offerings if they choose to do so.

Should you be unhappy with a reseller charging for the service, have a look for another reseller who does not.

Yes.

Zero-touch is just a provisioning method which deploys an EMM agent to your device over the air (OTA), to enrol into a Fully Managed Device profile using Android Enterprise (not legacy Device Admin) APIs. Google do not provide a free EMM solution, though device management is available through Google Workspace (G Suite) with the appropriate licenses.

No, zero-touch is for corporate-owned devices only.

No, please use an EMM solution for day-to-day device management.

Nothing until the device is reset, at which point it will not be prompted to enrol into management.

It will be forced to enrol back into management automatically following the data erase, unless a config has not been applied, or has since been removed.

As of late 2020 yes!

As zero-touch is a little light on features, Knox Mobile Enrolment has full support for Android Enterprise and a little more control over the how and when for device provisioning, so organisations may still opt not to use zero-touch on a Samsung device.

Through supported EMMs and the minimum Knox version (2.9), organisations can use either KME or zero-touch (9.0+) to deploy an Android Enterprise fully managed, dedicated, or COPE device, or work profile via KME only.

Yes, however this only affects new devices added and not those already on the console. For existing devices, leverage either CSV or API to make bulk changes.

The config won’t apply until after the device is reset. Anything after the “checking for updates” prompt is too late.

The upload may complete successfully, but the device will not initiate the zero-touch enrolment flow once connected to a network. The device will need to be deregistered and re-registered with the correct manufacturer.

From 2020, the manufacturer field is no longer required for IMEI-based uploads and can be ommitted.

These are a selection of DPC-specific key-pairs which manipulate the enrolment experience. An example may be pre-populating the EMM server, or enabling system applications. They vary between EMMs so do validate before attempting to use one.

Nothing until after the device is reset. Zero-touch configurations only download during the setup wizard, and not after. This is also why once a device has been partially set up, it needs to be factory reset in order to pull down the zero-touch config once more.

This action results in the device being irreversibly removed from zero-touch management. Please contact the device reseller to add it back in. The IMEI or serial (WiFi only devices) will be required.

Any currently-enrolled devices will not be impacted until they are factory reset.

As of late 2020, all GMS certified Android 9.0+ devices from all OEMs support zero-touch.

OEMs supporting zero-touch on 8.0/8.1 include:

• Sony
• Huawei
• HMD Global
• Google
• LG
• Motorola
• Sharp

Along with the change to globally support all Android 9.0+ GMS certified devices with the integration of zero-touch into GMS Core (Google Play Services), the previous Google-maintained list of zero-touch supported devices, including those running older Android versions, is no longer live.

A collection of DPC extras for various EMM/UEM vendors can be found here: Android Enterprise zero-touch DPC extras collection.

As EMM vendors begin supporting the zero-touch iFrame introduced in late 2020, manual editing of DPC extras should diminish as EMMs will handle it automatically.

Zero-touch resellers can be found globally. The complete list of resellers can be found here.

No, only authorised resellers. Customers are not able to add devices to the zero-touch portal at this time.

This will change in future.

Only console admins or owners from the customer portal, or the reseller. End-users cannot remove their device from zero-touch enrolment.

Fully managed (including COSU), work profiles on fully managed devices (8.0-10), and work profiles on company owned devices (Android 11)

This could be a few things:

• Check the manufacturer name is correct, the example CSV file downloaded from the portal lists Google as the manufacturer, and resellers may not have changed it.
• Confirm the IMEIs are correct.
• Confirm a configuration is present and assigned to the device.
• Is the device being setup on WiFi? Try cellular to rule out restricted networks.
• Is the device connected to a network at all? Check and connect if required.
• Is the device running 8.0+? With the exception of Pixel, no device running less than Oreo will support ZT.
• Does the OEM support ZT on the device? Unless Android Enterprise Recommended, zero-touch is optional and may therefore not be supported even on 8.0+ devices.

No, it does this extremely quickly.

The term “zero-touch” is aimed at admins and IT teams that no longer need to manually touch each device in order to undertake managed provisioning. This is in context of IT teams often pre-staging devices before shipping them to end users to avoid non-enrolment, which is no longer needed when devices are zero-touch registered.

It does not apply to the act of end-users running through the provisioning process, which has admittedly required more and more taps over the last few major Android versions due in part to the often unnecessary interruptions of unskippable privacy prompts.