Android build

Both Android Enterprise enrolment paths — corporate fully-managed and personally-owned work profile — plus Managed Google Play, enforced patching, and the operational fixes Android estates usually learn the hard way. Built in your own Intune tenant, from a written plan you approve first.

Why this matters

Android is where otherwise tidy Intune estates quietly fall apart. iOS gets the attention; Android gets a half-configured Managed Google Play connection and a single enrolment profile someone set up in a hurry. The platform punishes that. Android Enterprise has two distinct ownership models — fully-managed for corporate devices and a personally-owned work profile for BYOD — and picking the wrong one has real consequences: full-wipe authority over someone's personal handset in one direction, an effectively unmanaged corporate device in the other.

Patching is worse. Unlike iOS, Android updates are fragmented across OEMs, and without an explicit update policy devices patch when the user feels like tapping the prompt — which, in practice, means some never do. And an estate that only ever built the corporate path carries a silent gap: the first genuine BYOD request is simply unbuildable until someone stops and does the groundwork.

What a good build does

Decolla's Android section follows the same journey order as the rest of the catalogue: enrol, secure, configure.

• Enrol — both enrolment paths ship as first-class items: fully-managed for corporate devices and the personally-owned work profile for BYOD, alongside the Managed Google Play connector everything downstream depends on. That pairing is deliberate: an earlier catalogue was fully-managed-only, which left BYOD unbuildable, so the gap was closed at the catalogue level rather than left for each customer to discover.
• Secure — an Android Enterprise system update policy, so patching becomes a policy decision rather than a user preference.
• Configure — the operational fixes that keep the platform liveable, such as exempting Microsoft Authenticator from Android's battery optimisation so MFA push notifications actually arrive, and hardening the Samsung fleets most organisations really run.

The scope is honestly drawn: device compliance rules live in Compliance & enforcement, and BYOD data controls live in BYOD & app protection, so nothing here pretends to be something it is not. Every item appears in the written plan — delivery method and reversibility class stated per item — before anything runs, and Decolla's own changes can be rolled back item by item.

Where it bites people

Two failures come up again and again. The first is the Managed Google Play binding itself. It is a tenant-wide, one-time connection, and organisations routinely bind it with whatever Google account was to hand — sometimes a personal Gmail. Unpicking that later means unbinding, which takes Android Enterprise enrolment and Play app assignments down with it. It deserves to be done deliberately, once, with a proper account, before any device enrols.

The second is quieter: battery optimisation putting Authenticator to sleep. Users report MFA prompts that never arrive, the ticket gets blamed on Entra or "the network", and the actual cause is a power-management default on the handset. The exemption is a small policy — but only if you know to look there, which is exactly why it sits in the catalogue rather than in tribal knowledge.

What's in this section (11 items)

Reversibility: auto reverses when unassigned · reverse reversible with a documented step · irreversible flagged before you approve the plan.