You finish setting up a phone and notice a gray briefcase called Work Profile. Inside it sits an unfamiliar app — Test DPC. No permissions prompt, no reason it should appear on a personal device.
At first, it feels misplaced, maybe even corporate. But this app isn’t malware or bloatware. Here’s what it really does, why it exists, and why it sometimes shows up on the wrong phone.
What Test DPC Actually Is
Test DPC (Device Policy Controller) is an official sample app from Google LLC, published under the package com.afwsamples.testdpc. It’s freely available on the Play Store and mirrored on GitHub under the repository googlesamples/android-testdpc, licensed under Apache 2.0. The Play listing confirms the essentials: current target SDK 35, around 500 000 downloads, and a data-safety declaration of ‘no data collected or shared.
The app was first introduced in 2015 and supports devices from Android 5.0 Lollipop upward, making it one of the longest-maintained development samples in Android history.
It’s a reference implementation that demonstrates how an enterprise controller interacts with Android’s management APIs. Every corporate phone enrolled through an MDM or EMM platform ultimately behaves according to the same Device Policy Controller model that Test DPC exposes in plain code.
Why Google Maintains It
Android Enterprise relies on consistency. Manufacturers, carriers, and software vendors all need a predictable baseline for enforcing policies—camera restrictions, certificate installation, app whitelisting, encryption requirements. Google’s answer was to publish an open DPC that anyone could study, compile, and verify.
- EMM vendors (like Intune or Workspace ONE) use it to confirm their policy commands match Android’s official API behavior.
- OEM partners run it to validate devices for enterprise certification.
- Independent developers test how their apps respond when enterprise restrictions are active.
Test DPC is released under an open license and remains the simplest way to replicate enterprise management without linking to real company servers or accounts.
How Test DPC Works Under Android
When Test DPC is installed, it can assume one of three controlled roles depending on provisioning: Profile Owner, Device Owner, or the modern Device Management Role Holder introduced in Android 14.
As Profile Owner, it creates a secure “Work Profile” separated from personal apps. That profile obeys enterprise rules—password length, disabled camera, blocked sideloading, and managed configurations.
As Device Owner, it represents a fully managed device. Every system setting can be locked down, and removal requires a factory reset.
The Role Holder mode, supported in version 9.0.5 and later, modernizes both concepts. Instead of owning the device, Test DPC temporarily holds the android.app.role.DEVICE_POLICY_MANAGEMENT role. The role expires at reboot, giving developers a safer way to test management flows on production firmware.
How Developers Provision It
Google’s documentation and the project’s GitHub page describe multiple legitimate enrollment methods, each matching a real-world deployment flow.
Developers choose one depending on the Android version and testing goal.
AFW code: During Setup Wizard, tapping the welcome screen six times reveals a hidden sign-in field. Typing afw#testdpc signals the device to download the app from the Play Store and start enterprise provisioning.
QR code provisioning (N +): A JSON payload defines the admin component, signature checksum, and APK download location. Example fields include:
"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "com.afwsamples.testdpc/com.afwsamples.testdpc.DeviceAdminReceiver"A checksum verifying authenticity. The default download link (https://testdpc-latest-apk.appspot.com) can fail on networks that block appspot.com; in that case, developers host the APK on their own server and update the JSON URL.
ADB Device-Owner mode, on a factory-reset device only:
adb shell dpm set-device-owner "com.afwsamples.testdpc/.DeviceAdminReceiver"This grants device-owner control instantly.
COPE / Profile-Owner on Organization-Owned Device, The command:
adb shell dpm mark-profile-owner-on-organization-owned-device --user 10 com.afwsamples.testdpc/.DeviceAdminReceiverIt marks a managed profile for dual-use testing.
Role Holder commands (Android 14 +):
adb shell cmd role set-bypassing-role-qualification true
adb shell cmd role add-role-holder android.app.role.DEVICE_POLICY_MANAGEMENT com.afwsamples.testdpcThese simulate temporary device-management privileges and reset automatically after reboot.
Inside Test DPC’s Open-Source Build
Test DPC is maintained with Bazel, not Gradle, mirroring Google’s internal build system. The repository’s build.sh script dynamically patches the setup-design library using the Unix ed utility, and Bazel requires the environment variable ANDROID_HOME pointing to the local SDK. Continuous-integration workflows verify that the sample compiles against current Android API levels.
Because the code is public, anyone can audit the app’s permissions or modify it for private testing. The main activity class (DeviceAdminReceiver) exposes every enterprise callback that a commercial DPC would implement, giving developers direct insight into Android’s administrative framework. The open design is why researchers treat Test DPC as both a security reference and a diagnostic template.
Safety Model and Limitations
Installing Test DPC from Play Store is safe; activating its management roles is what changes behavior. When set as Device Owner, Android treats it as a corporate controller. Uninstalling is disabled by policy, and the only clean removal path is a factory reset.
That design isn’t a flaw—it’s a security guarantee. Device-owner apps can enforce encryption, reset passwords, or wipe data remotely, so the OS prevents silent revocation.
Google’s data-safety declaration confirms that Test DPC collects no telemetry, stores no personal information, and shares nothing externally. Its purpose is isolation, not monitoring. Still, anyone testing on a primary phone risks losing personal data if policies mis-apply.
Always use secondary hardware or an emulator for provisioning experiments.
How to Remove Work Profile or Reset Test DPC
- If Test DPC only created a Work Profile, open Settings › Accounts › Work Profile, remove the profile, then uninstall the app normally.
- If it became Device Owner, back up data and perform a factory reset—that’s the only supported way to revoke administrative control.
- If a device freezes on “Configuring device” during QR provisioning, host the APK locally and replace the appspot.com link in the JSON payload.
- For Role Holder tests, remember that permissions reset automatically after reboot; rerun the role commands if you need another session.
Enterprise Debugging and Log Access
From Android 7.0 onward, Device Owner DPCs can request full bug reports using DevicePolicyManager.requestBugReport(). Test DPC implements this call so developers can collect dumpsys, dumpstate, and logcat output for enterprise processes. Security logs record key events—application launches, keyguard actions, issued ADB commands—inside a protected buffer unreadable by normal apps.
To persist those logs across warm reboots, OEM kernels enable pstore/pmsg and the system flag config_supportPreRebootSecurityLogs. These technical hooks are what make Test DPC valuable to QA teams certifying enterprise-ready builds.
Why You Might Find Test DPC Pre-Installed
Occasionally a consumer discovers Test DPC on a phone out of the box. That doesn’t imply spying; it usually means the device originated from an OEM testing batch or was previously enrolled in a developer program. The sample may remain in /system/priv-app for internal validation. After a standard retail flash or factory reset, it disappears.
Final Insight
Test DPC isn’t another mysterious Android background process—it’s the open manual for Android Enterprise itself. Google keeps it public so every manufacturer and developer can test the same management rules before they reach business fleets. On a lab phone, it’s the safest way to explore policy APIs. On a personal device, it’s simply out of place.
Its existence is proof that Android’s enterprise layer is transparent down to the code—controlled, auditable, and built to be tested, not feared.
Related articles
