Work profile (BYOD) ✅
Fully managed (COBO) ✅
Fully managed with work profile (COPE) ✅
Dedicated (COSU) ✅
NFC provisioning ✅
AFW# provisioning ✅
QR provisioning ✅
Zero-touch enrolment ✅
How to read this report. This device has been tested against the public validation process, in which all provisioning methods and deployment scenarios have been tested across at least two EMM platforms.
Where a feature works with one EMM, but does not with another (consider Enforce max failed attempts in the report below) this is considered a pass (green) as it’s likely an EMM issue. Where it does not work, partly or fully, across two or more EMMs this will be flagged as a warn (yellow), or a fail (red).
Some features aren’t supported or set up across EMMs, or don’t work with the device (consider KME below), where this is the case the feature will be marked as untested (purple).
Despite being set across two EMMs, Disallow work widgets on the personal home screen is not enforced by either EMM, allowing work widgets to be freely placed.
This is a device issue (or an API has changed in Pie).
Despite the single setting and multiple settings applied in MobileIron and VMware respectively, when plugged into multiple power sources the screen ultimately turned off.
As passcode policies were applied including mandated timeout, these could have clashed however this hasn’t been the case with other devices.
This can be replicated. This may be a device issue.
Not unique to the Pixel, at the moment when deployed as a COPE device (fully managed device with work profile) and a personal account is added to the parent profile, should the device be reset in an unauthorised manner, for example:
The device will lock to the personal Google account residing in the parent profile. This is irrespective of any FRP bypass in place, though it hasn’t been tested as to whether FRP whitelist would override this behaviour.
Replicated across two EMMs. This is a device issue, but appears to be more OS-level as it affects other devices also.
The following weren’t replicated issues, but were flagged as the device didn’t behave as expected when tested. They are described below to offer context for why a warn or fail was registered during testing.
Under COPE in VMware, max failed attempts incorrectly enforces against the work profile rather than the device in the device passcode policy. As such, once a maximum has been reached, VMware removes the work profile instead of resetting the device, leaving it in a partially broken state.
This is a VMware issue.
Despite being set, the work profile location can be toggled on & off by the user at will.
The two settings:
In MobileIron there are no explicit options to prevent this and is therefore on by default.
In VMware the options are present, and while disallow personal apps to share documents with work apps is enforced with COPE, it was not with a work profile only deployment (BYOD).
There are numerous issues with the MobileIron kiosk, these are not limited to the Pixel 3a. The affected policies:
Despite the relevant configurations in place, it is effortless to escape the MobileIron kiosk if any access to settings has been granted. For example should WiFi settings be available:
This is a MobileIron issue, and it affects many devices including recent Nokia and Sony examples.
Of the points listed above, most aren’t considered a device issue. On that basis aside from making note of where the individual restrictions failed on the tested EMMs for those customers affected (as it’s highly likely other devices will be affected also), there’s little reason not to consider the Pixel 3a in the enterprise.