Android Enterprise FAQ

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.

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.

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.

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!

Throughout this site and across Google's official documentation and resources there are multiple references to the bind, or binding of a Google account to an organisation's EMM/MDM platform of choice in order to use Android Enterprise, but what is it?

Android Enterprise consists, very simplistically, of three aspects:

1. the on-device APIs
2. the advanced account, application, and Play Protect functionality
3. the additional solutions, such as zero-touch and many more 3rd party offerings

In order to leverage 2 and 3, an enterprise is required. This enterprise is created when an organisation goes through the process of linking a Google account - either via Google Workspace or with a standard consumer Google account (@gmail.com or under an existing email address) - to their EMM.

For the organisation it's a reasonably straightforward sign-in and setup flow (at least for those who don't use Workspace) that'll create an enterprise, which generates the appropriate authentication tokens and assign an enterprise ID to allow the EMM to then handle all account and application management going forward.

What sort of account and application management?

• The EMM will create, maintain, and delete managed Google Play accounts (for non-Workspace deployments)
• The EMM will assign the appropriate account to one or more devices, depending on use case (user or device-based)
• The EMM can import and deploy approved applications
• etc

This is a very high-level explanation only, and doesn't cover off the intricacies of things like Play EMM API, AMAPI, differences between Google Workspace and Google accounts, and a multitude of other factors that determine the features and functionality associated with binding for device management.

I’ve encountered several examples of things not working quite right with AER devices, particularly when diving into the granularity of a specific function with a specific EMM.

The first point of contact for any device based issue would be the EMM vendor. While it may not be an issue which can be replicated on a different model or OEM, the EMM vendor will still investigate it, particularly if it can be replicated on one or more devices of the same model.

Before contacting the EMM, the organisation should ensure the issue can be replicated on more than one device. If so, attempt to collect logs from the EMM, the device (a bug report, though be aware this will collect personal account information also) and steps to replicate it along with all of the normal details – make, model, Android version, build number, etc. A video is always appreciated though do add the steps on paper also.

If the EMM can replicate it but cannot resolve it, they will have OEM contacts to reach out to to progress it. If necessary, Google will be involved once all other avenues are exhausted, or it’s determined to be a platform issue.

I do a fair amount of device testing, so if you do come across something and your EMM is not providing the support needed, feel free to reach out and I’ll be happy to help.

Adding accounts allows end-users to head into Settings - Accounts and add an account.

Configure credentials allows an end-user to configure account credentials in-app.

Both options have legitimate uses, for example the adding of accounts and configuring of credentials may be permitted in a COPE deployment as end-users would be allowed to add a Google account and download their own applications complete with personal accounts.

On the other hand, enabling add accounts in a fully managed or work profile deployment scenario would allow end-users to switch to their personal Google account within Google Play, providing full access to the Play Store from which they may install applications which encourage data leakage and raise DLP concerns (Dropbox sat alongside OneDrive, for example).

Android One and Android Enterprise Recommended are two different programmes offering a bit of overlap in security and consistency.

Android Enterprise Recommended ensures devices validated meet the minimum requirements and recommendations of a consistent UX for management, 90 day security updates for 3 years and at least one letter upgrade (O to P, P to Q.. ). OEMs maintain their value-adds, bundled apps, custom UIs and more.

Android One takes this a step further; any device in the Android One programme will use a system image developed with Google. Like the Nexus days of old, the UI is vanilla Android and the Android One team have to approve any additional applications bundled with the device.

Updates must be released every 30 days and the devices must support two letter upgrades (O to Q, P to R, etc).

When combined with AER, Android One offers additional benefits validated to work in the enterprise. It’s a great combination.

Restricting Android Device Policy to a single Google Workspace tenant is very straightforward. In your DPC extras, add the line:

{
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": {
"com.google.android.apps.work.clouddpc.EXTRA_FORCED_DOMAINS": "[\"domain.name\"]"
}
}

If your organisation leans on multiple domains across organisational groups, here's an example of allowlisting 3 domains within the ZT DPC extras for Google Workspace:

{
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": {
"com.google.android.apps.work.clouddpc.EXTRA_FORCED_DOMAINS": "[\"bayton.org\",\"jason.com\",\"impressivedomain.com\"]"
}
}

When a Google account entered during provisioning doesn't match one of these domains, a small red error will show beneath the text input as follows:

Please enter an email address for one of the following: bayton.org, jason.com, impressivedomain.com.

Yes, it is more recently possible to configure the accounts responsible for managing the Android Enterprise organisation (enterprise) ID

1. Log on to managed Google Play admin
2. Scroll down to Admins
3. Add or remove Google accounts as desired

Add an account

Adjust permissions

NB: Owners can add and remove other accounts, while Admins are limited to only managing the enterprise. This follows the same permissions model as other enterprise solutions Google offers, such as zero-touch.

Remove an account

Notes

The same recommendations continue to apply when adding new accounts - if you're making a new Google account to add in, please use the "current email address" option and associate the Google account with a work email address. This makes account recovery much simpler, and avoids questions around why emm.account.3@gmail.com exists in future.

In other words, don't do what I did when I bound my EMM to emmsetup@gmail.com back in 2017 (see above).

Note also that Google Workspace accounts are not supported for administering enterprises. If a Google Workspace user is invited, they will receive an invite only to be informed "G Suite users are not supported":

Perhaps this will be addressed in future, or at the very least engineering will update the message to reflect the Google Workspace branding.

One final point to mention, a Google account can only administer one enterprise. If an invited account is already administering another enterprise, they will see an error:

Not all Android devices come with GMS, or Google Mobile Services, certification.

What is GMS?

GMS certified devices, or more recently rebranded by Google as Play Protect certified devices, are Android devices that have undergone the 60+ hour testing and approval process with Google or a 3PL lab on Google's behalf. This testing, which consists of various security & compatibility validations, ensure the Android device under test behaves, looks, and feels consistent with the rest of the Android ecosystem. It ensures an OEM doesn't preload harmful (as in malware, but also as in privacy) applications, it ensures the OEM builds are up-to-date on vulnerability management and have patched all known CVEs over 60 days old, and it ensures apps install properly, work consistently, and all ecosystem-wide behaviours and implementations meet Google's strict requirements.

Most of the requirements for an Android device heading to GMS certification can be found through the CDD, or Compatibility Definition Document. This is a public document that outlines every requirement for Android under MUST, SHOULD, and MAY.

If you come across references to CTS, VTS, BTS, STS, GTS, or less generally grouped as "XTS", these are the individual tests that make up the validation & certification process for GMS.

Before putting an Android device through these tests, the OEM must sign an agreement with Google; the GMS - Google Mobile Services - agreement is an additional contract that defines requirements for bundling Google applications on the Android device. Requirements include mandatory and optional Google apps (Google core and Google optional, respectively), home screen layouts, app icon positioning and much more. These requirements are further broken up into regional and usecase agreements, such as MADA for most of the world, eMADA for Europe, EDLA for enterprise or non-standard form factors, and others. Each agreement also comes with requirements for longevity, transparency (ie period of support for software on a device lifecycle published publicly, etc).

Understandably a lot of this is NDA, so it's not easy to be overly transparent about Google's requirements and processes for certification.

How do I validate a device is GMS certified?

This is surprisingly not that easy to discern for the general public, as Google doesn't explicitly maintain a list of certified devices under the heading of certified devices.

Instead, there are three indirect means of validating devices are certified:

1. Check the OEM/ODM has an agreement with Google - https://www.android.com/certified/partners/
2. View Google Play's Compatibility document, as any certified device will show up here - https://support.google.com/googleplay/answer/1727131
3. On the device itself, head to Google Play > Settings > About > Play Protect certification. Your device should show "Device is certified"

If the OEM/ODM is listed in link 1, there's a reasonable assumption the hardware they provide has certification, since Google leans on OEMs to certify the hardware they make once they're granted an agreement.

But if the device is listed in link 2, you know for sure it's certified. These lists aren't updated daily, so the absence of a device doesn't immediately indicate a device isn't certified.

The caveat for 3 is a device may be whitelisted with Google before getting formal approval, so may not have passed GMS testing just yet. This can be cross-checked with the above links to form a reliable opinion.

AER is Google’s validation programme for devices, EMMs, Carriers and MSPs.

Each of the above will have a list of requirements to meet in order to validate, and will re-validate on an annual basis.

More details: What is Android Enterprise Recommended?

There is no path to convert a MADA device (GMS/Play Protect certified) to EDLA.

While Google offered a grace period during the introduction of the EDLA licence, this has long since closed. To convert a MADA device to EDLA, it must undergo new EDLA certification, and both SKUs (if >1000 are in market) must be supported for the licence period.

No.

An Android Enterprise ID is associated 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.

No.

Unless you are already a Google Workspace customer, you can use your EMM console to register a new Android Enterprise organisation with any existing Google (managed or unmanaged) account, or soon, a Microsoft 365 account, and your EMM will create unique and generic managed Google Play service accounts on each Android device that allow you to sign in to 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.

Officially no, these devices are not supported for Android Enterprise. 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, or a custom DPC that directly interfaces the Device Policy Manager (DPM) APIs on the Android device. Your mileage may vary on what is possible, but assume that account and application based functionality that leans on Google Play services, Google Play, or any other aspect of the GMS suite of applications will not work.

Furthermore, standard provisioning methods will not work, as these are provided by Google's Set Up Wizard (SUW) flow. The only option, unless the AOSP device OEM implements a different solution, is to set an application as a Device Owner (DO) through ADB.

No.

It is not possible to deploy applications into the parent profile (or, the device outside of the work profile) in a work profile deployment. This is covered, as well as other aspects of this use case, with considerations when deploying MTD with Android Enterprise

As of Android 11 this answer also applies to COPE, work profiles on company owned devices.

Yes, however this process needs to be supported by the EMM. Few EMMs support this today, so it’s important to ask your vendor (or prospective vendor) if this is something you’d like to do.

The process itself will vary, but it may range from a checkbox in a profile to assigning a specific configuration, or simply a change at the folder/org/group level settings the devices sit within.

Once the process begins, affected devices will be prompted by the DPC to begin work profile setup. In this process the DPC will migrate from the parent profile (device) to a work profile. Understandably many legacy profiles/configs/policies will cease to function and so equivalent Android Enterprise policies should be in place.

When a device is deployed as a company owned work profile (COPE) or personally owned work profile (BYOD) device, a secondary profile is created on the device known as a work profile. This is where all corporate apps and data reside on the device, and is fully isolated and separately encrypted on the device.

Unless explicitly set, the work profile doesn't have any additional authentication required, allowing an end-user to open work applications on the device as desired.

A work challenge is what Google call the passcode applied to the work profile that shares most of the same policies associated with a device passcode policy. It can be applied in the following ways:

• For devices with no device passcode set, as the only passcode required on the device, and only prompted when work apps are opened.
• For devices with a passcode set, to share the device passcode between the device and the work profile (when unlocking the device, the work profile also unlocks).
• For devices with a passcode set, to require a unique passcode for the work profile, requiring additional authentication when work apps are opened.

Here's an example of a work challenge policy requiring a unique passcode on a device:

No.

User applications and app data residing outside of the work profile are not visible to the DPC within a work profile. System applications are, however once again the data associated with the apps is separately stored, meaning personal account details associated with Gmail would not show up alongside a corporate exchange account within the EMM.

There have been isolated instances where during enrolment the DPC could collect a list of personal applications installed before migrating into the work profile, however by the time enrolment completes this will have been rectified to display only the applications in the work profile.

As of Android 11 this answer also applies to COPE, work profiles on company owned devices.

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.

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).

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.

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.

There are a few options available:

Reboot the device and re-enrol as sometimes all it takes is a reboot, and the EMM will prompt it’s deletion as it provisions the profile once again.

Manually delete the work profile by heading to Settings > Accounts. The work profile will be listed and should be removable here.

Connect the device to ADB if the profile still won’t delete. This requires enabling ADB debugging on the device via Developer options and a working ADB setup on a computer. A Google search will assist in getting this setup if necessary. Once the computer can detect the device over ADB, run the following:

adb shell pm list users

This should return a list of active users where user 0 is the parent (device/default) user, and any other number (10, 12, 200 etc) should be the work profile.

Users:
  UserInfo{0:Owner:4c13} running
  UserInfo{12:Work profile:1030} running
  UserInfo{150:Secure Folder:10061030} running

To remove the work profile run:

adb shell pm remove-user 12

Making sure of course the number reflects the returned value in the previous command.

This should remove the work profile.

Normally this would suggest either the respective Android Enterprise configurations aren’t assigned to the device, or there’s an issue with the binding between the EMM and Google.

Ensure the user of the device is in the correct Active Directory group (if relevant) or EMM group to receive the correct profiles, otherwise check the binding.

Occasionally and with some EMMs this may also happen if more than one device is enrolled with the same Device Identifier, eg: Serial Number or IMEI. Validate all Device Identifiers are unique (at least within an OEM/model) as it's not uncommon to see duplicates in the wild.

Not normally by default, though do validate with your EMM vendor. If confirmed disabled however FRP kicks in after a reset, log a ticket with EMM support.

If so desired, whitelisted Factory Reset Protection is available and offers a simple, albeit caveated means of ensuring devices can’t simply be wiped and re-setup without Android Enterprise provisioning taking place. For zero-touch devices there’s no need to leverage it.

More: Feature spotlight: Factory Reset Protection.

Yes, however EMM support on both EMM solutions is required, and I’m not aware of any today who support this except for the Android Management API.

There are several options for provisioning into any fully managed deployment scenario (COBO, COPE, COSU):

• NFC (5.0+): With the use of a provisioning app provided by your EMM of choice on a spare device, simply input basic environment details and bump NFC radios with a freshly factory reset (or brand new out of box) device to begin provisioning.
• Managed Google account (6.0+): Begin setting up a device as normal (including connecting to a network) and at the Google account prompt, enter the managed Google account (G Suite, Google Cloud Identity) address and authenticate as normal.
• DPC identifier (6.0+): Begin setting up a device as normal (including connecting to a network), but at the prompt to enter a Google account opt instead to input the DPC identifier of your EMM, plenty of examples are available here.
• QR code (8.0+): With a QR code provided by either the EMM solution or a counterpart provisioning app (the same potentially used to provision via NFC), simply tap 6 times on the welcome screen to be download the QR reader (8.0) or switch to it automatically (9.0). WiFi details are required unless provided within the QR for 9.0 devices.
• Zero-touch (8.0+): Devices purchased through an authorised reseller may be assigned to a zero-touch customer account, and with a configuration created and assigned the device with automatically begin zero-touch provisioning as soon as network connectivity is established.
• KME (Knox 2.8+): Samsung devices running Knox 2.8 or above are compatible with Android Enterprise provisioning via KME. Devices added to the KME portal with a profile assigned will begin KME provisioning from a factory reset state.
• Other: Your device OEM may support other methods of provisioning. Reach out to them to request details.

More details:

• Did you know? Android Enterprise fully managed provisioning methods
• Android Enterprise provisioning guides

No, both an enterprise wipe/retire/delete from the EMM and a full wipe on a fully managed device do the same thing, they reset the device back to factory settings.

Android Enterprise requires a DPC actively enrolled to provide management policies, without this, the device will reset.

Wherever possible, zero-touch offers the best experience both for organisations and users. For organisations, it provides not only the decreased overhead of not having to explain how to manually start provisioning a device (and the support required when users still don’t get it), but also the confidence of knowing should a device be factory reset accidentally or with intent, the device will jump back into zero-touch provisioning as soon as it’s connected to a network. This extends to Samsung’s KME equally for the same reasons. That doesn’t mean zero-touch is the fastest and most efficient provisioning method, in fact it’s probably comparable in speed to DPC identifier, however speed is but one consideration.

If zero-touch isn’t available, my personal preference is QR code provisioning as QR codes are persistent (normally), can be hosted anywhere or freely shared between employees, don’t need a dedicated provisioning device, and support DPC extras.

EMMs leveraging the Android Management API (AMAPI) are subject to the default policy requirements Google sets. In February 2024 Google adjusted the default, unset behaviour for UsbDataAccess from ALLOW_USB_DATA_TRANSFER to DISALLOW_USB_DATA_TRANSFER. If your policies did not previously explicitly allow USB data transfer, this function will be blocked on your managed devices.

To reverse this, please set USB data transfer explicitly to allow, and redeploy your policies.

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.

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.

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 omitted, but it should still be used for Wi-Fi-only devices.

No.

I’d recommend taking a look at Hypergate.

There is however a project which was initiated (but not wholly supported) by Google to bring Kerberos support to Android through an application. Take a look at the respective Github repo to learn more.

Related: Setup Kerberos Authentication on MobileIron Core for Android Enterprise

No.

App shortcuts supported with device admin are not available for Android Enterprise. Instead, it’s possible to deploy shortcuts for Android Enterprise devices as web applications through the Google Play iFrame.

Instead of a bookmark/shortcut that opens in the default browser, web apps are legitimate applications that open with Google Chrome.

More information: Create and manage web apps for Android Enterprise

When deploying the iFrame, a UEM vendor decides what they wish to support. On that basis, the iFrame may lack private app upload, web app creation or bundle support.

It’s possible for a UEM to implement multiple iFrames with these features separated out, so is worth checking this functionality isn’t placed elsewhere on the console.

Should additional features not be available anywhere, please get in touch with your UEM provider to discuss this.

For all EMMs that support it, the Google Play iFrame now supports the simple, few-step process of uploading an APK for distribution to your Enterprise.

Unlike adding an APK directly into the UEM console, uploading to Google Play is safer, easier to manage and less likely to lead to issues compared with pushing APKs directly.

More information: Create and manage private apps for Android Enterprise

Where the Play iFrame isn’t supported, it’s possible to upload and distribute through the Google Play Console but keep in mind there’s a $25 fee to set up a developer account.

Note: Google Play will only permit one package name (com.app.name) for an application across the whole Google Play estate, meaning if you wish to upload an app privately today, and make it available publicly later, you must use unique package names for each upload.

Yes this is possible, however not concurrently. Android supports only profile-wide VPN (or always-on VPN) natively, and the per-app VPN functionality often alluded to when multiple VPNs are brought up would have to be supported in-app.

When one VPN is running profile-wide and another is initiated, it will disconnect the first. Should these VPNs have failure protection and automatic reconnect (or leverage always-on VPN for this) the two VPN solutions will repeatedly disconnect one another.

To permit or block a selection of URLs in Chrome managed config, you need to add the URLs to the relevant list. The format for this is as follows:

[scheme://][.]host[:port][/path][@query]

Setting multiple URLs in succession would look like this:

["http://www.example.com", "https://www.example.com", "http://*", "https://example.com?sda"]

More format examples can be found here, but in a nutshell:

• * targets everything. This is useful for preventing access to everything via a blocklist, then explicitly allowlisting certain domains or URLs
• 192.0.2.1 targets this specific IP
• .domain.com explicitly blocks the root domain, but not its subdomains
• domain.com blocks everything in that domain

It's important to note that some EMMs require brackets for this to work properly, which is why I used them in the multiple URLs example. Google's documentation doesn't mention this, but it's a crucial step.

If you're looking to configure the bookmarks available in managed Chrome, you can use the below format. More examples can be found via Google's documentation.

[
  {
    "toplevel_name": "Company bookmarks"
  },
  {
    "name": "Homepage",
    "url": "mydomain.com"
  },
  {
    "children": [
      {
        "name": "HR",
        "url": "mydomain.com/hr"
      },
      {
        "name": "Submit a ticket",
        "url": "mydomain.com/it-support"
      }
    ],
    "name": "Internal URLs"
  },
  {
    "name": "Android resources",
    "url": "bayton.org/android"
  }
]

Be aware on managed Android devices, bookmarks can't be placed on the home screen. For that use case, you should consider web apps instead.

Other things to consider -

• The order you input the subfolders and URLs reflects directly in Chrome
• If you input a child folder (eg: "children"), ensure you list the name (eg: "name":"Internal URLs")
• All normal json rules apply. You can use a json validator to be sure it's valid before committing it
• If Chrome doesn't show the bookmarks, though other configs (eg homepage) change, the syntax is invalid