Android management in China – what are your options?

After I published the article regarding the enrollment of Android devices in closed networks, the hottest question was how to apply it for China. The answer is as usual “it depends”. If you want to know more – read on!

  1. What’s the problem?
  2. What options are available?
  3. What is the optimal approach?

What’s the problem?

Problem is that Google services are banned in China. As such most of the popular international brands sell their devices there w/o GMS (Google Mobile Services), and even those with GMS cannot really use them. This results in the following limitations:

  • No Play Store
  • No Work Profile
  • No Zero-Touch or KNOX Mobile Enrollment (!) either.
  • No GMS initial setup wizard, which typically facilitates the Device Owner (Fully Managed mode) enrollment. This is important, since if the device vendor did not provide an alternative to enroll DO – you are stuck!
  • No GMS libraries often used by the applications

So, what can we do?

Application Management

First of all, since the Play Store is not available (neither public nor managed), all your apps must be deployed via MDM.

This is generally, not a problem. However, since Android 8 the OS native package installer performs a check for Internet based on accessing, which may lead to failed installs. The workaround for Workspace ONE UEM is to use Product Provisioning, which uses our own installer. For other EMMs – talk to the developer.

Of course, if the apps rely on GMS APIs, and you have non-GMS devices – you are stuck. It is thus important to carefully select your apps, and if you must have apps that require GMS – consider how you will add those libraries onto the devices:

  • Procure only the devices that have alternative GMS-enabled firmwares and reflash them.
  • Leverage projects such as (I’ll leave the legality questions aside) to add GMS to existing devices.

In both cases you end up with a manual solution (which can be partially automated with a bit of scripting though). If you know a better way – feel free to suggest in comments.

Device Enrollment, Management, Security

The following options are available, with the following pros and cons.

1.      Android Legacy (Device Administrator) management

It’s the same stuff that had been around for years. It works, for now. Problem is, ever since Android 8 it has less and less functionality / stability, and with Android 11+ it won’t work at all. Also, most EMMs are deprecating the Legacy DA management. It also provides limited security compared to Android Enterprise.

Overall I’d recommend it as a last resort option.

2.      Android Enterprise Fully Managed (Device Owner) management.

As mentioned before, it is indeed possible when the following three prerequisites are met:

  • MDM supports closed network enrollment. Not everyone does.
  • Device vendor did not hardcode any GMS functionality in their initial setup wizard (precedents exist).
  • Device vendor had implemented means to enroll DO.

The pros of this approach are quite obvious: it is standards-compliant, future-proof, you get full AE functionality and broadest security options possible. The cons are no privacy (device should not be used for personal purposes), the resulting need to carry 2+ devices, and [currently] very limited vendor support.

While Device Owner functionality is part of AOSP, the enrollment code is not (on GMS devices it is a part of Google’s own Initial Setup Wizard). AOSP assumes, since each device vendor would want to write their own setup wizard, based on the device specifics. Seems logical.

Alas, very few device vendors have actually bothered to create one, offering their customers a scalable method to enroll non-GMS devices. The list is maintained in this post. Everybody else requires a very laborious and manual process that involves ADB, described in the same post.

If you are a sizable enterprise buyer – apply pressure to your vendor. If you are a smaller player – consider buying devices that offer GMS firmware options and reflashing them into GMS.

3.      Android Enterprise with VPN

I think the name says it all. If you enroll devices in a centralized fashion over a WLAN network hooked to a VPN you can get all the AE options: WP, DO, COPE. If you let users enroll devices (which means they have to get VPN app first), only Work Profile will be possible, since DO enrollment needs to be done before anything else is deployed to the device. Of course, device also must have a GMS firmware.

Pros and cons are quite obvious too: you get full spectrum of GMS services, Play Store etc., but they all may break any second.

4.      Registered / MAM only Mode

Many EMMs offer an option to “register” device without actually enrolling it into MDM. In Workspace ONE this is called “Hub Registered Mode” for example, and I covered it here to some extent.

The biggest advantage of this method is that it will always work (provided your EMM supports it). The disadvantage is that you get 0.00% security and control over the device. You might address this by deploying a 3rd party EDR/MTD solution such as Lookout, Zimperium, Pradeo etc (provided they work in China) and leveraging their API level integration with your EMM to exchange the security and policy enforcement data (provided such integration exists).

Another alternative is using applications developed with MDM SDKs, such as Workspace ONE SDK or MS App Protection SDK (now part of InTune SDK), which can talk to WS1 UEM / Azure AD back ends, pull policies from there and otherwise protect themselves (featuring in-app encryption, in-app authentication, offline compromise detection and wipes etc). For instance, all WS1 productivity apps (Boxer, Content, Notebook etc) have WS1 SDK. Similarly, all (or nearly all) MS O365 mobile apps have those built in and can be managed via Workspace ONE (or other EMM that supports MS Graph API integration). Below are a few pictures from Workspace ONE UEM SDK default security options. These can be further customized per application via the SDK Profiles.

Some of the Workspace ONE UEM SDK security options.

Overall, this may be a fairly good option if you are limited to BYOD or a small set of “enterprise-grade” apps than can protect themselves (WS1, O365 or your own in-house apps, where you can include the EMM SDKs). However, I would not deploy it without Conditional Access on the back end. I will talk about it later.

What is the optimal approach?

Overall, I would build my strategy for Android in China as follows:

  1. Wherever possible use AE Fully Managed devices (up to the point of buying ether GMS devices or devices for which GMS firmware exists and reflashing them if I can’t enroll DO otherwise) with closed network enrollment:
    • Security, scalability, stability, full management options
    • Since Play Store is not available, all applications deployed via EMM
    • Users will have to have a separate phone for personal needs, but actually this is OK since I am NOT planning to allow any 3rd party app stores on my company’s devices anyway!
    • Conditional access for device compliance checks
    • If your deployment is small and you have a local tech, even a laborious ADB method may be OK.
  2. For devices that can’t enroll DO and for BYOD – use Registered Mode:
    • All sensitive data (emails, company IP/files/etc) goes via MAM-enabled apps
      • WS1 Boxer, WS1 Content for mail/contacts/documents/photos
      • O365 apps with Graph integration where feasible
      • SDK profiles deployed for strong on-device security (in-app auth, compromise detection, wipes etc)
    • Restrict access to “company sensitive apps”
      • Since all company apps are installed via the EMM, use smart groups based on the enrollment type to prevent the Registered devices from ever seeing the “sensitive” apps
      • On the back end, use Conditional Access with compliance – registered mode devices will not pass compliance check
    • If access to “sensitive apps” is nevertheless desired – deploy additional MTD/EDR security solution and integrate with EMM on the API level. Typically, if will result in generating some sort of compliance records, so the devices will be able to pass the conditional access checks
      • Compliance policies that check for presence and status of the security tools and blacklist the device if those are not present are essential then (since we can’t deploy any corrective actions on non-MDM devices).
  3. Last resort – Legacy (while it works) and/or VPN (while it works)
  4. Final, most important, note – try before you buy! You need to test everything end to end before committing!

My hope is that in the nearer future we will see more devices offering DO enrollment in non-GMS scenario, or more security options in the Registered mode, since Legacy and VPN cannot be relied upon.

What are your thoughts? Do you know better options? Care to share?

Source photo from Wikipedia

12 thoughts on “Android management in China – what are your options?

Add yours

  1. Hi, my thoughts are exactly the same. We run with Intune, but basically we have the exact same difficulties and options that you mention. My question is have you tried or heard about the NationSky and the NQSky EMM? Any thoughts on that?


    1. There are too few docs, but they would have the very same issues, unless chinese device manufacturers are building their agent right into the firmware.. And if they do – I would stay away from those devices! 🙂


  2. Hi. Does it mean that Zebra and Honeywell are the only non GMS devices to support QR code scanning for DO enrollment?

    Liked by 1 person

      1. Hi. Is there a possibility to use WS1 as MAM to assign the Boxer App (including cert auth ) and own company apps to other devices?
        We need support in China and we would appreciate for any help


  3. Hi, when the devices are enrolled via closed network enrollment, will the devices have network connectivity to connect to local networks in china / wifi? Trying to understand what ‘Android Enterprise mode that can function without Internet Access!’ means?

    Liked by 1 person

    1. Hi. Have you checked my article on AOSP/Closed Network Enrollment? The devices will have all the connectivity allowed by firewalls/etc. They just won’t require connection to Google services to function. I cover it in detail in that article.

      Basically, the devices will be enrolled in Android Enterprise Work Managed mode w/o creating the [Managed] Google Play account. Thus (unless it is hardcoded by the device vendor), they will not try to talk to Google APIs during enrollment or operation. This is possible because Workspace ONE has an on-device agent (vs many MDMs using Google’s AMAPI implementation) as well as own AWCM push messaging mechanism that replaces Google’s FCM (vs MDMs that don’t). We have customers managing mobile devices in fully walled networks (warehouses, ships in open ocean, etc) using this model.

      Hope this helps.

      Liked by 1 person

  4. Hi, thanks for your very helpful articles. 🙂
    In my setup process for Chinese devices, I activate the USB debugging and I script these commands in batch:
    “adb shell dpm set-device-owner com.airwatch.androidagent / com.airwatch.agent.DeviceAdministratorReceiver”
    and “adb shell am broadcast -a com.airwatch.agent.action.AUTO_ENROLL”.
    With the correct configuration of the organization group, it works very well for full managed devices.
    I would like to use “adb shell am broadcast -a com.airwatch.agent.action.IMPORT_CREDENTIAL_XML” to autofill credentials. Do you know the format of this xml for the agent?

    Liked by 1 person

    1. Good question! If you want learn more about this – generate a Sideload Staging package in the UEM console Devices -> Lifecycle -> Staging.
      It will create a ZIP file that will contain an encrypted credentials.bin file as well as the script with ADB commands such as

      adb shell am broadcast -a com.airwatch.agent.action.IMPORT_CREDENTIAL_XML -e file /sdcard/credentials.bin

      This will give you a hint.

      I’ve never tried it with Android Enterprise, so when you come to a working solution – please post here!!!

      Liked by 1 person

      1. Thank for reply. I’ve test with the credential.bin and it works fine. But for automate credential’s creation, it’s heavier. I think with API i can create sideload and download it but i’ve some issues doing it this way. If you have an hint for this part, i’ll take it 🙂 .

        Liked by 1 person

      2. But why would you want to create many sideload packages?
        You can use staging flow(s) instead – stage all devices with the same staging user (or a few staging users if you really need them different by location / etc), and then have them re-assigned to the actual end users later. Look up the staging flows we offer in the docs.

        Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at

Up ↑

%d bloggers like this: