Android Without Google: Managing Devices for a Foreign Company's China Staff

Short answer: Android devices sold in mainland China ship without Google Mobile Services, and the standard Android Enterprise enrolment flow most global MDM standards are built on depends on it. So a group device-management policy that works everywhere else does not complete in China. The fix is a China-specific enrolment path designed into the global standard — not a setting somebody forgot to tick.

Why a global device-management standard stops working at the China border

Most multinational IT teams arrive at device management the same way. A platform is chosen — Microsoft Intune in a Microsoft-centric organisation, Jamf Pro where the fleet is Apple-heavy, VMware Workspace ONE in mixed enterprise environments. Policies are written once. Enrolment is automated. New starters receive a device that configures itself, and the standard is rolled out country by country without much drama.

Then it reaches mainland China, and the process simply does not finish.

The reason is specific and structural rather than mysterious. Android devices sold in mainland China ship without Google Mobile Services — the Google Play Services layer that, outside China, is present on essentially every Android handset. The modern Android Enterprise management model that most global MDM standards are built on depends on that layer. Work profile provisioning, managed app distribution through Managed Google Play, and much of the policy enforcement chain all assume it is there.

Remove it, and the enrolment flow does not have a component it requires. It is not a permissions problem, a network glitch, or a policy that needs adjusting. The path that works in twelve other countries does not exist on that device.

What makes this expensive is not the technical constraint itself, which is well understood by people who work in China. It is that global IT teams routinely encounter it for the first time in production, weeks into a China office rollout, with devices already in people's hands.

The scenario: a group standard, a new China office, and an enrolment that never completes

Consider an illustrative composite — not a named client, but a pattern that recurs across foreign-invested companies opening or growing in China.

A European industrial group has run the same device-management standard across its European and North American operations for three years. Intune, Android Enterprise work profiles on Android, automated enrolment on iOS, a documented policy set covering encryption, PIN complexity, screen-lock timeout and conditional access. It works. Nobody has needed to think about it in a long time.

The group's China entity has grown to about seventy people — a Shanghai office covering sales, technical service and finance, plus a small Beijing team. Devices have been bought locally, because buying laptops and phones locally is the obvious thing to do.

The rollout plan is one line in a project schedule: extend the group MDM standard to the China office.

What actually happens:

• Android enrolments do not complete. The devices are current-generation handsets from major manufacturers, bought from ordinary local retail channels, and they behave nothing like the identical-looking devices in the European fleet.
• The group IT team, three time zones away, starts debugging. They check licences, conditional access rules, network paths, and the device policy itself. All of it is configured correctly, which makes the problem harder to see rather than easier.
• Someone eventually establishes that these devices have no Google Mobile Services, and that this is normal for the China market rather than a fault. That reframes the problem entirely — and it arrives a fortnight in.
• iPhone enrolments mostly work, which initially muddies the diagnosis: half the fleet enrols, half does not, and the pattern is not obvious until you know what to look for.
• Meanwhile the China office is running unmanaged. Nobody planned for that state; it is just what is true while the problem is being understood. Corporate mail is on personal-configuration devices with no enforced encryption, no PIN policy, no remote wipe capability and no inventory.
• The local office manager, who has been handling IT informally, is not in a position to escalate this usefully, because from where he sits the devices work fine.

The China office is not resisting the standard. The standard just does not reach it.

What this actually costs, beyond the delay

The visible cost is engineering time — a couple of weeks of a global IT team debugging a problem it has never seen. That is annoying but recoverable.

Three other costs matter more.

A security gap that nobody decided to accept. Between rollout and resolution, the China fleet is unmanaged. If a phone is lost in that window, there is no remote wipe, no way to establish what was on it, and no record that it existed. This is the same exposure the policy was written to prevent, sitting open in the one market where it was never explicitly approved.

A blind spot in the asset picture. Devices bought locally by a local office, outside the group procurement process, frequently never make it into the central inventory. Even after enrolment is eventually fixed, the "which devices exist" question stays partially unanswered — and it is very hard to enrol a device you do not know about.

A precedent that persists. The most common resolution we see is not a resolution. It is an exception: China is quietly marked as out of scope for the device standard, on the reasoning that it is difficult and the office is small. That exception then survives every subsequent policy review, because nobody wants to reopen it. Two years later the China office has a hundred and twenty people, an unmanaged fleet, and a compliance answer that consists of not being asked the question.

There is also a data-protection dimension that a foreign-invested company should engage with deliberately rather than by default. Device management involves collecting information about devices — and, depending on configuration, about their use — belonging to employees in China. How PIPL applies to that, what employee notice and consent should look like, and whether any management data leaves the mainland are real questions with real answers, and they are legal questions rather than technical ones. Our position is that they should be settled with your own counsel at design time, not discovered at audit. What we can say operationally is that the enrolment architecture materially affects what data is collected and where it goes, which is exactly why it is worth designing rather than inheriting.

Brocent's perspective: this is an architecture decision, not a bug to be fixed once

We have run IT for foreign-invested companies in mainland China since 2007, and the framing we would push hardest is this: the GMS constraint is not an obstacle on the way to the global standard. It is a permanent property of the environment, and the global standard has to have a China branch designed into it.

The distinction matters because it changes who owns the problem and when.

Treated as a bug, this gets handed to whoever is on the ticket, solved once for the devices currently in the building, and forgotten. Six months later a new hire in Shanghai gets a locally-bought handset, the same thing happens, and nobody remembers what was done last time. The knowledge lived in a resolved ticket.

Treated as an architecture decision, it produces three durable things: a defined enrolment path for China devices, a deliberate answer to where China devices are sourced from, and a runbook the global IT team can follow without needing to rediscover the constraint. That is a day of design work that stops recurring.

The second thing we would press is that the sourcing question deserves an explicit decision rather than a default. There are broadly two directions, and both are legitimate:

Devices can be sourced locally and managed on a path that does not require GMS. Microsoft's Intune, for example, provides an Android Open Source Project management path intended for exactly this situation — devices without Google Mobile Services. This is the honest, sustainable answer for a China office, because it works with the devices your staff will actually buy and your local procurement will actually source. The trade-off to go in with your eyes open about: the capability set is not identical to Android Enterprise. Managed Google Play does not exist without GMS, so app distribution works differently, and some policy controls behave differently or are unavailable. Which of your existing policy requirements survive that translation is a scoping question with a checkable answer, and it should be answered before devices are bought, not after.

Or devices can be sourced with GMS from outside mainland China so the global path applies unchanged. This preserves policy parity, and for a small fleet of executives or frequent travellers it can be the right call. But it makes every device a cross-border procurement item with its own warranty, support and replacement problem, and it does not scale gracefully to seventy local staff.

Most companies we work with end up with a deliberate mix, and the important word is deliberate. The failure mode is not choosing either one — it is having the choice made implicitly by whoever happened to buy the phones.

The third point is about the parts of this that are not about Android at all. Apple's enrolment path is generally less exposed to this specific constraint, which is why the iPhones in the composite above mostly enrolled. But device management in a China office still depends on the office being able to reach your management service reliably, and cross-border network reliability from a China office is its own engineering topic that affects both platforms. A device-management design for China that has not considered network reachability has solved the enrolment problem and left an operational one.

What a China-specific device-management design actually looks like

The MDM and BYOD service we deliver is platform-agnostic by design — we select, deploy and configure Intune, Jamf Pro or Workspace ONE according to the environment rather than pushing one of them — and for a China office the design work runs roughly like this.

Establish what the fleet actually is. Before any enrolment design, a device inventory: what exists, who has it, where it came from, and which of it has GMS. In a China office that has been buying locally, this is usually the step that produces surprises, and it has to come first because everything downstream depends on it.

Decide sourcing explicitly, in writing. Local-with-AOSP-management, imported-with-GMS, or a defined mix with a rule for who gets which. This is a decision with cost, support and policy consequences, and it belongs to the business rather than to whoever is standing at the procurement desk.

Map the policy set against what each path can actually enforce. Encryption, PIN and password complexity, screen-lock timeout, jailbreak and root detection, conditional access, application allow-listing. Some of these translate cleanly to a GMS-free path and some do not. The output is an explicit, documented statement of which controls apply to which device class in China — not an assumption that the global policy applies uniformly.

Solve application distribution deliberately. This is the part most often underestimated. Without Managed Google Play, getting approved corporate applications onto managed devices — and keeping them on approved versions — needs a defined mechanism rather than the one the global standard assumes. It is solvable; it is not automatic.

Design BYOD containerisation under the same constraint. Work-profile containerisation, which separates corporate applications and data from personal content and allows a selective wipe that removes company data without touching personal photos and messages, is itself an Android Enterprise capability. In a GMS-free environment the separation approach has to be designed rather than assumed. This matters more in China than almost anywhere, because personal-device use for work communication is culturally normal there, and a BYOD answer that only works on paper is not an answer.

Verify the operational path, not just the enrolment. Remote wipe within minutes of a loss report, lost-device response, application version management and policy drift detection all need to work from where the devices actually are. Enrolment succeeding is the start of the test, not the end of it.

Write the runbook. A documented China enrolment procedure the group IT team can follow for the next hire without rediscovering any of this. In our experience this single artefact is worth more over two years than the initial fix.

Three ways foreign companies handle device management in China

Rolling out the global standard unchanged

• What it is: extending the group MDM policy to the China office as a line item, on the assumption that a country is a country.
• Where it genuinely wins: nowhere, in mainland China specifically — though the instinct behind it is correct everywhere else, and it is the reason the approach is so common.
• Where it breaks: Android enrolment does not complete on locally-bought devices, and the failure is opaque to a team that has not seen it before.
• The hidden cost: the debugging window. The fleet runs unmanaged while a global team investigates a constraint that a China-experienced engineer would identify in an hour.
• Honest verdict: not a strategy, but the default that most companies execute by not deciding anything.

Leaving China devices out of scope

• What it is: after hitting the wall, China is marked as an exception to the device standard. Often informally.
• Where it genuinely wins: it is fast, and it stops the immediate expenditure of engineering time on a small office.
• Where it breaks: it leaves a real, permanent security gap — no enforced encryption, no PIN policy, no remote wipe, no inventory — in a market that is very often growing.
• The hidden cost: the exception outlives its rationale. It was accepted when the office had twenty people and is still there at a hundred and twenty, and by then reopening it is a project rather than a decision.
• Honest verdict: the most common outcome, the least defensible one, and the one that reads worst in an audit or a client security questionnaire.

A China-specific enrolment path built into the global standard

• What it is: Brocent's model — one global standard with an explicitly designed China branch: a defined enrolment path for GMS-free devices, a deliberate sourcing decision, a documented mapping of which controls apply to which device class, a solved application-distribution mechanism, a containerisation approach that works under the constraint, and a runbook.
• Where it genuinely wins: it holds. New hires enrol, the policy position is documented and defensible, and the global team does not re-encounter the problem.
• What it costs: design effort up front, and honesty about capability differences between the paths. It is not free and it is not identical to the global standard, and anyone telling you otherwise has not done it.
• Where it needs care: the policy mapping. Assuming parity that does not exist is how you end up believing a control is enforced when it is not — which is worse than knowing it is absent.
• Honest verdict: the only one of the three that is a decision rather than a consequence.

Frequently asked questions

Why does standard MDM enrolment fail in China?

Because Android devices sold in mainland China ship without Google Mobile Services, and the Android Enterprise management model that most global MDM standards are built on depends on that layer being present. Work profile provisioning and managed application distribution both assume it. The enrolment flow is not misconfigured — it is missing a component it requires. This is a market characteristic, not a device fault or a policy error, which is why teams that have not seen it before spend so long looking in the wrong places.

Does this affect iPhone enrolment too, or only Android?

The GMS constraint is specific to Android, and Apple's enrolment path is generally less exposed to it — which is why, in a mixed fleet, the iPhones often enrol while the Android devices do not. That split is itself a useful diagnostic signal. What does affect both platforms is network reachability: device management depends on the office reliably reaching your management service, and cross-border network reliability from a China office is a separate engineering question that a complete design has to cover.

Can a global MDM policy still apply once devices are managed correctly?

Partly, and the honest answer matters more than a reassuring one. Core controls — device encryption, PIN and password complexity, screen-lock timeout, remote wipe — are generally achievable. Some capabilities that depend on the Google Play layer, most obviously managed application distribution through Managed Google Play, are not available and need a different mechanism. The right output is an explicit, documented mapping of which controls apply to which device class in China, rather than an assumption of parity. Believing a control is enforced when it is not is worse than knowing it is unavailable.

Is this a Brocent-specific fix, or a general China constraint?

It is a general constraint of the mainland China market, and any competent provider operating there will describe it the same way. What differs between providers is whether they have a designed path for it — a defined enrolment method, a sourcing position, a policy-mapping exercise, an application-distribution answer, and a runbook — or whether they solve it once per incident. We would encourage you to ask any provider, including us, to describe their China enrolment path specifically before signing anything.

How long does China-specific enrolment setup take?

The design work is measured in days rather than weeks once the fleet inventory exists — and the inventory is usually the long pole, particularly in an office that has been buying devices locally without central visibility. The sequence we would run is inventory first, then the sourcing decision, then the policy mapping, then a pilot enrolment on a small group of real devices before any fleet-wide rollout. The pilot is not optional. It is where you find out which of your policy assumptions survived the translation.

Does this affect application management, not just enrolment?

Yes, and this is the part most often underestimated. Pushing approved corporate applications to managed devices silently, blocking unapproved ones, and keeping everyone on approved versions is normally handled through the Google Play layer. Without it, application distribution needs a defined alternative mechanism. This is solvable, but it is separate work from getting the device enrolled, and a China rollout plan that budgets only for enrolment will discover it late.

What about BYOD personal devices in China?

BYOD deserves specific attention rather than being folded into the fleet question, because personal-device use for work communication is culturally normal in China. The containerisation model that makes BYOD acceptable elsewhere — a managed work profile separating corporate applications and data from personal content, with a selective wipe that removes company data without touching personal photos and messages — is itself an Android Enterprise capability. Under the GMS constraint, the separation approach has to be designed explicitly. It is also where the employee data-protection question is sharpest, and that part should be settled with your own counsel rather than assumed from your European or US policy.

Do we need to treat this as a compliance issue as well as a technical one?

Device management in China touches personal information belonging to employees in the mainland, so PIPL is a live consideration, and how it applies to your specific configuration — what device data is collected, what notice and consent employees receive, and whether any of it crosses the border — is a legal question for your own counsel rather than something we would answer for you. What we would insist on operationally is that the enrolment architecture directly determines what data is collected and where it goes, so the compliance conversation belongs at design time, alongside the technical decisions, rather than after the fleet is enrolled.

Where device management belongs: inside the plan, not beside it

Device management in China is a good example of something that looks like a product purchase and is actually a governance question.

The composite company above did not need to buy an MDM licence. It already had one. What it lacked was somebody whose job was to know that the China environment is structurally different, to have designed for that before devices were bought, and to keep the answer current as the office grew. The licence was never the missing piece.

That is the argument for device management sitting inside a managed IT plan rather than beside it as a standalone tool. A plan already carries the things a device-management design has to interlock with — 24/7 monitoring, patch management, endpoint protection, credential management, security governance, and a named vCIO whose job includes noticing that the China office has grown past the point where the original decision still fits. MDM sits as an add-on across every plan tier rather than being bundled into the base plan, and it is scoped rather than list-priced, precisely because a China fleet, a Hong Kong fleet and a Singapore fleet are genuinely different design problems rather than a per-seat quantity.

Brocent's managed IT plans are built that way: a per-user monthly plan carrying monitoring, patching, security and governance, with device management designed on top of it against your actual environment — including a China environment that does not behave like the rest of your estate. Per-market per-user pricing, including mainland China, is published on the pricing page.

If you are extending a global device standard into a China office — or if you hit this wall some time ago and quietly marked China as an exception — the useful first step is an inventory of what is actually in people's hands, followed by a design conversation about the enrolment path. Get in touch and we will start from your existing policy set and work out which parts of it survive the translation, rather than proposing a replacement for something that works fine everywhere else.

*The company described here is an illustrative composite of the foreign-invested China operations Brocent supports, not a named client. Platform capabilities described are current at the time of writing and are verified against your specific environment and policy requirements at scoping. Nothing in this article is legal advice; PIPL and employee data-protection questions should be settled with your own counsel. Brocent was founded in Beijing in 2007, opened its Hong Kong office in 2016, and has been headquartered in Singapore since 2021.*