Android Device Admin deprecation: how to migrate legacy fleets to Android Enterprise
Android introduced Device Admin as Android’s original management interface in Android 2.2. Google deprecated it for enterprise use in Android 9 and removed its core security policies for management apps targeting Android 10 (Google for Developers). Devices still enrolled through Device Admin keep running, but whether IT can still enforce passcode, camera, and lock screen rules depends on three things: the device’s Android version, the API level the management app targets, and whether the MDM provider still supports Device Admin. On Android 10 and later, a management app that targets API level 29 or higher can no longer use those policies; an older app on an older device may still apply them.
The replacement is Android Enterprise, with its work profile, fully managed, and dedicated device modes. This guide covers what the deprecation changed, which mode fits each device in a legacy fleet, when a factory reset is unavoidable, and how to plan the move.
What Device Admin deprecation means
Device Admin lets an app request administrator rights and apply a limited set of policies. Google’s current guidance is direct: “we recommend customers and partners adopt managed device and work profile modes to manage their devices from now on” (Google for Developers).
In practice, deprecation does not switch devices off. It means a management app built for current Android versions cannot use the deprecated policies, and every new Android release widens the gap between what Device Admin can do and what your security policy requires. Jason Bayton, an Android Enterprise specialist who has tracked the change since 2017, writes that for organizations with any Device Admin devices left, migration “is no longer optional” and “is overdue” (Bayton).
The deprecation timeline
| Android version | What changed for Device Admin |
|---|---|
| Android 2.2 | Device Admin API introduced |
| Android 5.0 | Device owner (fully managed) and profile owner (work profile) modes introduced |
| Android 7.0 | Admin-removal protection and admin-set passcode resets removed for security reasons |
| Android 9 | Device Admin deprecated for enterprise use; existing functions still work but are discouraged |
| Android 10 | Camera, lock screen feature, password expiry, and password quality policies throw a security error for management apps targeting API level 29 |
| Android 11 | The reset password policy stops functioning for Device Admin |
Source: Google for Developers, Device admin deprecation.
What breaks on a Device Admin fleet
These are the policies Google lists as deprecated, and what losing each one means for IT:
| Deprecated policy | What IT loses |
|---|---|
| Disable camera | Blocking the camera on devices in secure areas |
| Disable keyguard features | Control over lock screen features such as notifications and trust agents |
| Expire password | Forced passcode rotation |
| Limit password | Minimum passcode length and complexity |
| Reset password | Setting a new passcode remotely for a locked-out user |
Two policies remain for consumer use: remote wipe and force lock. Neither is enough to meet a passcode or data protection requirement on its own. For Android 10 and later, Google points developers to a screen lock quality check that reports whether a device meets a standard, rather than enforcing one.
Choose an Android Enterprise mode for each device
Migration isn’t a one-size-fits-all decision for the whole fleet. Each device group needs the mode that matches who owns it and how it is used. The Android Enterprise guide explains each mode in depth; this flow shows where legacy devices land.
| Device group | Android Enterprise mode | Factory reset? |
|---|---|---|
| Personally owned (BYOD) | Work profile | No, on supported MDMs |
| Company-owned, one user | Fully managed | Yes |
| Company-owned with personal use | Work profile on a company-owned device (Android 8.0 or later) | Yes |
| Kiosk, single app, or shared | Dedicated device (see kiosk mode) | Yes |
| Below Android 6.0 or not GMS-certified | None; replace | Not applicable |
Sources: Google Android Enterprise feature list; Bayton.
Two migration paths
Work profile migration: no reset
For personally owned devices, a work profile migration can run over the air. On MDMs that support it, the change creates a work profile, removes the Device Admin, disables the agent on the personal side, and resumes management inside the work profile (Bayton). The user keeps their phone and their personal data, and IT gains a managed container with current policies.
Google also allows the slower route: leave existing devices alone and enroll replacements with a work profile as old devices age out (Google for Developers).
Fully managed and dedicated migration: reset required
Google states that “Migrating a device from device admin to managed device requires a factory reset.” Plan for users to back up anything stored on the device, and decide how each device will be provisioned after the reset. The method depends on the Android version:
| Provisioning method | Minimum Android version | Fits |
|---|---|---|
| DPC identifier (afw# code in setup) | Android 6.0 | Small batches, typed by hand |
| NFC | Android 6.0 (optional for MDMs) | Staging benches with a programmer device |
| QR code | Android 7.0 | Small to mid-size batches |
| Android zero-touch enrollment | Android 8.0 (Pixel 7.1) | Devices bought through a zero-touch reseller |
Source: Google Android Enterprise feature list. More detail in the guide to MDM enrollment methods.
One change surprises users after a fully managed migration: many preinstalled system apps are removed by default (Bayton). If staff relied on the stock gallery, file viewer, or camera app, deploy and test replacements before the rollout.
Big bang or phased rollout
Google describes two strategies and notes that some organizations combine them (Google for Developers):
- Big bang: migrate the fleet in planned waves, resetting company-owned devices group by group. Faster, but every wave needs downtime, staging capacity, and user support.
- Phased adoption: enroll every new device in Android Enterprise and retire Device Admin devices through normal replacement. Lower disruption, but legacy devices stay on weaker policies until they leave the fleet.
A common hybrid is to migrate BYOD over the air now, reset high-risk company-owned devices in waves, and let low-risk devices that are close to replacement age out. Tie that last group to your device lifecycle plan so “age out” has a date.
Pre-migration checklist
- Inventory the fleet. Record Android version, manufacturer, GMS certification, ownership, and use case for every Device Admin device.
- Set up the Android Enterprise binding. Connect your MDM to Google. Bayton notes that new organizations now get a managed Google domain by default and that Managed Google Play Accounts are deprecated, so check which binding type your MDM uses.
- Rebuild policies, not copies. Create new Android Enterprise policies and app configurations rather than porting Device Admin settings, and keep them separate from legacy policies so troubleshooting stays clear.
- Scope carefully. Assign Android Enterprise policies to a pilot group first. Bayton warns that a misconfigured hybrid setup can trigger a mass work profile rollout across every eligible device.
- Replace removed apps. For fully managed devices, add the apps users need for photos, files, and attachments through managed Google Play.
- Plan the reset. Schedule backups, staging time, and provisioning method for each company-owned group.
- Set a cutoff. Pick the date after which no device may remain on Device Admin, and report against it.
If you are changing MDM vendors at the same time, the MDM migration guide covers moving device records and re-enrollment.
Devices that cannot move
Android Enterprise requires Android 6.0 or later on GMS-certified hardware (Bayton). Devices below that line cannot be migrated. Google recommends keeping older devices in Device Admin until you replace them. Treat them as a known risk: limit them to low-sensitivity work, keep them off systems that hold regulated data, and move them to the front of the replacement queue.
Migrating with Bento MDM
Bento MDM supports the Android Enterprise modes a migration lands on: work profile for BYOD, device owner (fully managed), company-owned devices with a work profile, and single-app or kiosk use. Enrollment options include QR code, Android zero-touch enrollment, and Samsung Knox Mobile Enrollment. See Android device management for the full feature set.
Frequently asked questions
Devices already on Device Admin keep working, but Google deprecated it for enterprise use in Android 9, and management apps targeting Android 10 or later cannot use its camera, lock screen, or password policies. Google recommends work profile and managed device modes instead.
For company-owned devices moving to fully managed or dedicated mode, yes. Personally owned devices can move to a work profile without a reset on MDMs that support over-the-air work profile migration.
Google lets older devices stay on Device Admin until you replace them. Whether they still enforce passcode and camera policies depends on the Android version, the API level your management app targets, and whether your MDM provider still supports Device Admin. Where those policies no longer apply, limit what the devices can access and schedule their replacement.
Passcode rules move into Android Enterprise policies your MDM applies to the work profile or the whole device. For apps that only need to know whether a device meets a standard, Google provides a screen lock quality check from Android 10.
Set a date, not a project
The deprecation began years ago, so a Device Admin fleet today is a policy gap, not a pending decision. Sort devices into the four outcomes above, move eligible BYOD devices without a reset where the MDM supports it, plan resets as maintenance windows, and set a date for devices that will be replaced. The remaining fleet will be one your security policy can actually enforce.
Related Articles
