Project 13: Managed-Device Policy Lab

Build a disposable-emulator device policy controller lab that proves owner mode, converges a tiny allowlisted policy set, audits every change, and restores normal device behavior through verified rollback.

Quick Reference

Attribute	Value
Difficulty	Level 4 - Expert
Time Estimate	26-38 hours
Language	Kotlin (alternative: Java)
Prerequisites	Projects 1, 3, 4, 5, and 10; Android components; desired-state reconciliation; security administration; emulator snapshots
Key Topics	DevicePolicyManager, DeviceAdminReceiver, device owner, profile owner, provisioning, lock task, kiosk, policy convergence, audit, rollback

1. Learning Objectives

By completing this project, you will:

Distinguish normal application authority, legacy device-admin activation, profile owner, device owner, and privileged/system application authority.
Explain why owner authority is created through provisioning rather than a runtime permission dialog.
Build a capability matrix by owner mode, Android version, affiliation, user/profile, and policy support.
Keep consumer automation features technically and visibly separate from managed-device functions.
Model device policy as desired state that is read, compared, applied, verified, and reconciled.
Implement rollback before adding policy breadth.
Demonstrate lock task mode only for DPC-allowlisted packages and contrast it with user-exitable screen pinning.
Persist an administrative audit record containing actor, intent, prior state, desired state, result, verification, and rollback.
Test partial failure, reboot, app update, lost owner state, unsupported policy, and destructive lab reset.
Document the difference between a learning DPC, an approved enterprise management product, and Android Management API-based deployment.

2. Theoretical Foundation

2.1 Core Concepts

Administrative authority is provisioned. A normal Android install runs under its application UID and may request only permissions and special accesses exposed to ordinary apps. Device-owner and profile-owner roles are different: the platform records that a Device Policy Controller (DPC) was provisioned to manage a fully managed device or managed profile. The app cannot silently promote itself. Provisioning occurs through legitimate setup or development flows and often requires a factory-reset or otherwise unprovisioned test environment.

Owner modes have different scope. A device owner manages a fully managed device and can apply policies at device scope when the platform permits. A profile owner manages a work profile and generally controls work-side applications/data while preserving the personal side. Some policies exist only for one mode, some depend on Android version, some require organization-owned or affiliated scenarios, and some have deprecations or changed semantics. The DPC must query current authority and policy support rather than infer it from installation.

DeviceAdminReceiver is an entry contract, not the policy engine. The receiver participates in administrative lifecycle callbacks, but domain decisions belong in a testable policy layer. DevicePolicyManager is an adapter with privileged side effects. A robust DPC translates an administrator-authored desired state into a plan, checks preconditions, applies the narrowest change, reads the resulting platform state, and records evidence.

Policy is convergence, not a button press. Administrative systems are long-lived and state can drift after reboot, app update, another controller action, OS upgrade, or failed sequence. Desired state says “these packages are allowlisted for lock task” or “this safe restriction should be enabled.” Reconciliation compares observed and desired values and applies only the delta. Repeating reconciliation should be idempotent. One-shot “set and forget” UI calls hide drift and make support difficult.

Rollback is a first-class policy. Every supported change needs a reversal or an explicit statement that reversal requires deprovisioning/reset. The lab starts with reversible policies and maintains last-known observed state. Rollback is not blindly restoring a stale snapshot if another administrator legitimately changed the device; it is a checked transition with preconditions, verification, and conflict handling.

Lock task and screen pinning are not equivalent. Screen pinning is user-controlled and user-exitable. Lock task mode restricts the device to DPC-allowlisted packages and is intended for dedicated-device/kiosk scenarios. Misconfiguration can trap a test device outside normal navigation. The lab therefore uses a disposable emulator, allowlists an explicit escape/admin surface where appropriate, implements stop/rollback first, and rehearses snapshot restore.

Product modes are security boundaries. A consumer automation app should not display owner-only actions as if a permission could unlock them. A managed build or mode has a different onboarding, distribution, support, threat model, and data policy. Shared domain contracts are reasonable, but administrative components, manifests, UI navigation, and release gates should remain isolated enough that consumer builds cannot accidentally expose enterprise control surfaces.

Audit answers administrative questions. A useful audit record identifies the administrative actor or enrollment context, policy descriptor/version, previous observed state, desired state, precondition evidence, API result, post-read verification, correlation ID, and rollback relationship. It excludes secrets and minimizes device/user data. A log line saying “policy set true” is insufficient for incident review.

Enterprise distribution has external constraints. Learning how DevicePolicyManager works does not make a lab DPC a supported commercial EMM. Official Android Enterprise guidance currently notes that new registrations for custom DPCs to the Google Play EMM API are no longer accepted through the old path and points developers toward current approval/management options. The project remains a controlled lab; any production plan must re-evaluate Android Enterprise partner, Android Management API, Play distribution, support, and privacy requirements.

2.2 Why This Matters

Many desired automations—kiosk lockdown, managed app configuration, work-profile separation, corporate restrictions, certificate deployment, or dedicated-device operation—are intentionally unavailable to consumer apps. Understanding DPC authority prevents wasted attempts to bypass Android security and teaches how enterprise mobility legitimately obtains greater control.

The desired-state and rollback practices also apply to cloud configuration, infrastructure-as-code, feature flags, fleet management, and database migrations. The learner confronts capability negotiation, administrative safety, irreversible operations, auditability, and compatibility.

2.3 Historical Context / Background

Android’s older device-admin model offered a smaller set of administrative controls. Android Enterprise introduced richer managed-profile, fully managed, and dedicated-device scenarios with DevicePolicyManager and provisioning flows. Over time, some legacy device-admin policies were deprecated for ordinary use while modern management moved toward owner modes and platform/enterprise management services.

Dedicated devices commonly use lock task mode and managed home experiences. Work profiles isolate enterprise applications and data from the personal profile. Modern enterprise deployment often uses Android Management API or approved EMM solutions rather than every organization shipping a custom public DPC.

2.4 Common Misconceptions

“Device owner is just another permission.” It is a provisioned platform role.
“Installing the APK with ADB makes it managed.” Installation and owner provisioning are separate operations.
“Device owner and profile owner can call the same APIs.” Scope and available policies differ.
“Lock task is immersive mode.” It is a DPC-managed allowlist restriction, not merely hiding system bars.
“Screen pinning proves kiosk behavior.” Users can normally exit screen pinning; managed lock task has different authority.
“A successful setter means the policy is active.” Read-back verification and observed device behavior are required.
“Rollback can be added later.” Administrative power without rehearsed reversal is unsafe.
“A custom lab DPC is ready for Play or enterprise production.” Approval, management architecture, policy, support, and privacy work remain.

3. Project Specification

3.1 What You Will Build

Build a separate Managed Policy Lab application/mode for disposable Android emulators. It presents:

Authority Dashboard: Normal, active admin, profile owner, device owner, or unsupported state.
Capability Matrix: Per-policy support, required owner mode, API range, current value, desired value, and rollback support.
Policy Catalog: Exactly two initial reversible policies—one lock-task allowlist scenario and one safe lab restriction chosen from current supported APIs.
Change Preview: Preconditions, expected device effect, rollback path, and destructive-risk warning.
Reconciliation Run: Read, diff, apply, verify, and typed result.
Audit Timeline: Administrator intent, prior/desired/observed states, verification, and rollback link.
Emergency Recovery: Stop lock task, revert lab policies, and instructions for snapshot/reset if owner removal requires it.

The normal-install experience must prove that administrative calls are unavailable and must never encourage privilege bypass.

3.2 Functional Requirements

Authority detection: Determine active admin, profile owner, device owner, user/profile, and managed state at runtime.
Per-policy capability: Encode minimum role, API constraints, reversible status, and validation method.
Mode separation: Consumer/normal mode cannot navigate to executable admin actions.
Disposable provisioning: Document an emulator-only development setup and snapshot/reset plan.
Desired-state model: Persist versioned desired policy independent of transient Android components.
Read-before-write: Capture observed state immediately before planning.
Preflight: Refuse unsupported role, API, package, or unsafe device conditions before side effects.
Convergence: Apply only differences and make repeated reconciliation idempotent.
Verification: Read back policy state and demonstrate a user-visible effect when applicable.
Rollback: Revert each supported policy through a previewed, verified operation.
Partial-failure handling: Record which steps succeeded and do not claim atomicity across unrelated platform calls.
Audit: Persist redacted intent, observed/desired/result state, actor context, timestamps, and correlation IDs.
Recovery: Provide a tested route out of lock task and a documented emulator reset path.
Policy boundary: Explicitly exclude passwords, credential capture, hidden surveillance, disabling protections, and real personal devices.

3.3 Non-Functional Requirements

Safety: All destructive experiments occur only on disposable emulators with snapshots.
Reliability: Reconciliation survives process death and is safe to repeat.
Reversibility: Every enabled lab policy has a verified reversal or documented reset requirement.
Auditability: Every effect is tied to an explicit administrator action and verification record.
Usability: Owner mode, blast radius, and rollback are visible before application.
Compatibility: Matrix records Android API, role, provisioning scenario, and policy result.
Security: Normal installs refuse before invoking privileged APIs; no attempt is made to self-elevate.

3.4 Example Usage / Output

Managed Policy Lab
Device: Disposable_Emulator_API_35
Authority: DEVICE_OWNER
Controller: com.example.flowforge.dpc/.AdminReceiver
Provisioning: development lab

Policy: kiosk.allowlist.v1
Observed: [launcher, settings]
Desired:  [flowforge-lab, recovery-console]
Plan: UPDATE_ALLOWLIST -> VERIFY -> ENTER_LOCK_TASK
Rollback: EXIT_LOCK_TASK -> RESTORE_ALLOWLIST
Result: APPLIED_AND_VERIFIED

Policy: lab.safe-restriction.v1
Observed: disabled
Desired:  enabled
Result: APPLIED_AND_VERIFIED

Audit correlation: policy-run-00047
[Preview Rollback] [Run Reconciliation]

3.5 Real World Outcome

Create two emulator instances from the same clean image. Install the lab APK normally on the first. Its dashboard reads Not managed, explains that owner authority cannot be requested in-app, and disables every policy action before any DevicePolicyManager call.

On the second factory-reset emulator, follow the official development provisioning path and record the resulting owner evidence. The dashboard reads Device owner, while its capability matrix shows exactly which two lab policies are supported. Preview and apply the safe restriction; observe the system behavior change, rerun reconciliation, and confirm the second run is a no-op.

Preview the lock-task policy. The preview lists allowlisted packages and the recovery route. Apply it and enter lock task only with the owned sandbox/kiosk app. Demonstrate that normal navigation is restricted and that your planned recovery control exits lock task. Reboot, reconcile, verify expected state, then run rollback and prove normal launcher behavior returns.

Simulate a partial failure between two policy steps. The audit timeline must show the successful step, failed step, current observed state, and safe next action rather than “all failed.” Finally, restore the emulator snapshot or wipe it, proving the lab leaves no personal device in a managed state.

4. Solution Architecture

4.1 High-Level Design

 Provisioning outside normal app UX
              |
              v
+----------------------------+
| Android owner/profile state|
+-------------+--------------+
              |
              v
+----------------------------+       +-------------------------+
| Authority & Capability     | ----> | Policy Catalog          |
| role/API/scope evidence    |       | requirements + rollback |
+-------------+--------------+       +------------+------------+
              |                                    |
              +----------------+-------------------+
                               v
                    +-----------------------+
 admin preview ---> | Desired-State Planner |
                    | observed vs desired   |
                    +-----------+-----------+
                                |
                          explicit plan
                                |
                                v
                    +-----------------------+
                    | DevicePolicy Adapter  |
                    | apply one step        |
                    +-----------+-----------+
                                |
                         read-back verify
                                |
                +---------------+---------------+
                v                               v
       +------------------+            +------------------+
       | Audit Timeline   |            | Recovery Console |
       | immutable facts  |            | rollback/reset   |
       +------------------+            +------------------+

4.2 Key Components

Component	Responsibility	Key Decisions
Admin receiver	Receive platform administrative lifecycle callbacks	Thin adapter; no policy decisions
Authority probe	Read current admin/owner/profile evidence	Never infers authority from installation
Policy catalog	Describe supported policy, role, API, risk, verify, rollback	Tiny allowlist, versioned descriptors
Desired-state store	Persist administrator-selected target state	Independent from transient receiver/service
Reconciliation planner	Diff observed and desired state	Pure, deterministic, idempotent plan
Device policy adapter	Execute one typed platform operation	Checks authority again immediately before call
Verification adapter	Read back and optionally observe behavior	Setter return is not sufficient
Audit repository	Store intent, steps, observations, and rollback links	Redacted, correlation-based records
Recovery console	Exit lock task and reverse supported policies	Implemented and tested before expansion
Mode router	Separate normal and managed UX/build contracts	Consumer path has no executable admin surface

4.3 Data Structures

AuthoritySnapshot
  installed: true
  active_admin: boolean
  owner_mode: none | profile_owner | device_owner
  user_scope
  api_level
  captured_at

PolicyDescriptor
  policy_id
  schema_version
  minimum_owner_mode
  api_support
  risk_class
  reversible: boolean
  verification_strategy
  rollback_strategy

PolicyIntent
  intent_id
  policy_id
  desired_value
  administrator_actor
  reason
  created_at

PolicyRun
  correlation_id
  authority_snapshot
  observed_before
  desired
  planned_steps
  step_results
  observed_after
  outcome
  rollback_of: optional correlation_id

4.4 Algorithm Overview

Key Algorithm: Verified Policy Convergence

Read a fresh authority snapshot.
Load the versioned policy descriptor and desired intent.
Reject if role, user scope, API, or safety preconditions are not satisfied.
Read current observed policy state.
Produce a minimal ordered delta plan.
Preview effects and rollback to the administrator.
On explicit confirmation, recheck authority and execute one step.
Read back the relevant state after the step.
Record step result and stop safely on mismatch or failure.
Re-read complete observed state and classify converged, partial, drifted, or unsupported.
Schedule no hidden retries for risky policy changes; require explicit recovery where appropriate.

Complexity Analysis:

With P supported policies, catalog evaluation and reconciliation are O(P).
Per-policy diff is usually O(1) or O(A) for an allowlist of A packages.
Audit storage is O(policy runs x steps), bounded by lab retention.
Platform call cost dominates computation and must be treated as fallible side effects.

5. Implementation Guide

5.1 Development Environment Setup

Use only disposable Android Virtual Devices created for this lab. Record image/API version, create a clean snapshot, and rehearse wipe/reset before provisioning. Never point this exercise at a personal phone, production kiosk, employer-managed device, or any device containing real accounts.

Lab preflight
- clean emulator has no personal account or data
- snapshot/restore procedure has been tested
- lab APK package and receiver identity are final for the exercise
- official provisioning documentation is open and current
- recovery console is designed before lock task is enabled
- second emulator is reserved for normal-install refusal tests
- all policies are synthetic and reversible

Provisioning commands and UI steps change across platform/tool versions. Follow current official Android Enterprise development guidance rather than copying stale setup commands into the project implementation.

5.2 Project Structure

managed-policy-lab/
|-- domain/
|   |-- authority/        # role and capability models
|   |-- policy/           # descriptors and desired state
|   |-- reconcile/        # pure diff planner
|   `-- audit/            # run and rollback records
|-- dpc-app/
|   |-- admin/            # DeviceAdminReceiver adapter
|   |-- devicepolicy/     # DevicePolicyManager port implementation
|   |-- verification/     # read-back and behavior checks
|   |-- recovery/         # stop/revert/reset guidance
|   `-- ui/               # dashboard, preview, run, audit
|-- normal-install-test/
|   `-- refusal-cases/
`-- tests/
    |-- unit/
    |-- managed-device/
    `-- compatibility/

5.3 The Core Question You’re Answering

“Which automations are legitimate only because an organization provisioned this app as an administrator, and how do I keep that power separate from consumer features?”

Before adding a policy, explain which owner mode grants it, who is the legitimate administrator, what user/device scope is affected, how it is audited, and how control is removed.

5.4 Concepts You Must Understand First

Provisioned owner roles
- What preconditions allow profile-owner or device-owner provisioning?
- Why can an installed app not self-promote?
- Reference: Android Enterprise DPC and provisioning documentation.
Managed profiles and fully managed devices
- Which data and users does each role control?
- Reference: Android Enterprise deployment scenarios.
Policy convergence
- How does observed state differ from desired state and setter success?
- Book Reference: “Software Architecture in Practice, 4th Edition” — availability, security, and modifiability.
Lock task
- Why must a DPC allowlist packages?
- How does it differ from screen pinning?
- Reference: Android lock task mode guide.
Administrative audit
- Which evidence is needed to explain and reverse a change?
- Book Reference: “Security in Computing” — access control, administration, and audit.
Evolution and deprecation
- How will descriptors capture API/role changes without scattered version checks?
- Book Reference: “Building Evolutionary Architectures” — fitness functions.

5.5 Questions to Guide Your Design

Does the normal-install path fail before invoking DevicePolicyManager?
Which role and scope does each policy descriptor require?
How do you prove owner state instead of trusting cached UI state?
What state is read immediately before planning and immediately after execution?
Which policy operations are independently fallible?
What happens when step one succeeds and step two fails?
Can rollback distinguish your change from later administrator drift?
Which recovery control remains reachable during lock task?
What requires emulator wipe rather than API reversal?
How are app update, reboot, and OS upgrade reconciled?
Which components are excluded from the consumer build?
What production architecture would replace a custom lab DPC?

5.6 Thinking Exercise

Authority Placement Matrix

Create rows for ten proposed actions and columns for normal app, special app access, active legacy admin, profile owner, device owner, privileged/system app, and unsupported/prohibited. Place each action in the minimum legitimate mode and cite the current platform documentation.

Then trace this partial run:

Desired lock-task allowlist is saved.
Package allowlist update succeeds.
Entering lock task fails because the foreground package changed.
Process dies before final audit commit.
Device reboots.

Describe observed state, durable intent, recoverable evidence, the next reconciliation plan, and how the administrator regains normal navigation.

5.7 The Interview Questions They’ll Ask

“How does an Android app become device owner or profile owner?”
“What is the difference between a work profile and a fully managed device?”
“Why can’t a normal app request device-owner authority at runtime?”
“How do legacy device-admin APIs relate to modern Android Enterprise?”
“What is the difference between lock task mode and screen pinning?”
“How would you design policy reconciliation and drift detection?”
“How do you recover from a partially applied administrative sequence?”
“What should an administrative audit record contain?”
“How would you test a DPC safely?”
“When should a product use Android Management API rather than a custom DPC?”

5.8 Hints in Layers

Hint 1: Start with read-only truth

Build the authority dashboard and capability matrix on both normal and provisioned emulators before adding one setter.

Hint 2: Describe policy as data

Keep minimum role, API support, desired/observed types, verifier, and rollback in a versioned descriptor.

Hint 3: Apply one reversible policy

Prove read, diff, apply, verify, repeat, rollback, and verify before adding lock task.

Hint 4: Treat multi-step changes as a saga

Record each completed step and compensating action. Do not pretend unrelated DevicePolicyManager calls are one transaction.

Hint 5: Make reset boring

Practice snapshot restore and emulator wipe early. Recovery is part of the Definition of Done.

5.9 Books That Will Help

Topic	Book	Chapter/Section
Quality attributes	“Software Architecture in Practice, 4th Edition”	Availability, security, and modifiability
Administrative security	“Security in Computing”	Access control, administration, and audit
Evolution	“Building Evolutionary Architectures, 2nd Edition”	Fitness functions and incremental change
Stable boundaries	“Clean Architecture”	Component boundaries and policy
Recovery	“Release It!, 2nd Edition”	Stability, operations, and recovery

5.10 Implementation Phases

Phase 1: Authority Truth and Safe Lab (7-9 hours)

Goals:

Establish disposable provisioning and recovery.
Render truthful owner/capability state with zero policy writes.

Tasks:

Create clean and normal-install emulator tracks.
Rehearse snapshot restore and wipe.
Follow current official development provisioning.
Build authority and scope snapshots.
Define two policy descriptors and prohibited actions.

Checkpoint: Normal and managed installs produce distinct evidence, and recovery/reset is proven before any policy application.

Phase 2: Reversible Desired-State Policy (8-12 hours)

Goals:

Converge one safe policy with verification and audit.
Prove idempotent repeat and rollback.

Tasks:

Add versioned desired-state persistence.
Implement pure diff planning.
Add preview and explicit administrator confirmation.
Apply one platform step and read it back.
Build audit and rollback relationship.
Inject failure before and after apply.

Checkpoint: Apply, repeat, reboot/reconcile, rollback, and repeat rollback all yield explicit safe outcomes.

Phase 3: Lock Task and Compatibility Evidence (11-17 hours)

Goals:

Demonstrate a recoverable dedicated-device restriction.
Record mode/API compatibility and production boundaries.

Tasks:

Design allowlist and recovery package policy.
Implement lock-task preflight and change preview.
Enter, verify, exit, and roll back lock task.
Test process death, reboot, partial failure, and lost capability.
Compare device-owner and normal-install results.
Write the Android Management API/custom-DPC decision record.

Checkpoint: The emulator enters the intended restricted experience and reliably returns to normal launcher operation through the documented recovery path.

5.11 Key Implementation Decisions

Decision	Options	Recommendation	Rationale
Test device	Personal phone, spare real phone, disposable emulator	Disposable emulator	Provisioning and recovery can be destructive
Policy breadth	Many setters, one reversible policy, two reversible policies	Two after one is proven	Depth and recovery matter more than surface area
State model	Button actions, cached flags, desired/observed convergence	Desired/observed convergence	Supports drift and safe repeat
Multi-step failure	Pretend transaction, best effort, recorded saga	Recorded saga with compensation	Platform calls are independently fallible
Product packaging	One undifferentiated app, visual mode only, separated managed track	Separated managed track	Prevents capability confusion and accidental exposure
Kiosk recovery	Rely on emulator UI, hidden command, designed recovery console	Designed recovery plus snapshot reset	Makes lock task safe to learn

6. Testing Strategy

6.1 Test Categories

Category	Purpose	Examples
Pure unit	Verify descriptors and diff plans	Unsupported role, no-op, rollback conflict
Normal install	Prove safe refusal	Every admin action disabled before API call
Provisioned integration	Verify actual policy effects	Apply/read-back/revert on device owner emulator
Lifecycle	Prove durable intent and reconciliation	Process death, reboot, app update
Recovery	Prevent trapped devices	Exit lock task, restore allowlist, reset snapshot
Compatibility	Map role/API differences	Multiple system images and owner modes
Audit/privacy	Verify administrative evidence	Partial result, correlation, redaction, retention

6.2 Critical Test Cases

Normal install refusal: No privileged call occurs and UI explains provisioning.
Owner proof: Dashboard role matches current platform state, not cached setup.
Unsupported descriptor: Policy is refused before planning on wrong role/API.
No-op reconciliation: Desired equals observed; no setter is called.
Apply and verify: Read-back matches desired after one safe change.
Setter success/read-back mismatch: Outcome is verification failure, not success.
Repeated reconciliation: Second run is idempotent.
Process death before apply: Durable intent remains pending with no false result.
Process death after apply: Next run reads observed state and converges safely.
Partial sequence: Audit identifies completed and failed steps.
Rollback conflict: Later drift prevents blind stale restoration.
Lock-task entry: Only allowlisted owned package enters managed restriction.
Recovery control: Exit restores expected navigation.
Reboot: Desired and observed state reconcile as documented.
Emulator reset: Clean snapshot removes managed lab state.

6.3 Test Data

Policy fixture: kiosk.allowlist.v1
required_mode: device_owner
desired_packages:
  - com.example.flowforge.lab
  - com.example.flowforge.recovery
verification: read current lock-task packages + behavior check
rollback: stop task, restore prior allowlist after conflict check

Policy fixture: lab.safe-restriction.v1
required_mode: profile_owner_or_device_owner (verify current API)
desired: enabled
verification: read policy state and observe documented behavior
rollback: disabled

Failure points:
- authority lost before plan
- process death after intent commit
- exception during first platform call
- read-back mismatch
- reboot before final audit
- rollback sees unexpected third-party drift

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall	Symptom	Solution
Treating owner as permission	Normal install throws SecurityException	Probe role and refuse before policy API
Stale provisioning command	Setup fails or creates wrong scenario	Use current official development documentation
Setter-only success	Dashboard says applied but device disagrees	Read back and verify observable behavior
No recovery package/path	Emulator appears trapped in kiosk	Design and test exit/rollback before entry
Broad policy experiment	Failure cause and rollback are unclear	Add one descriptor at a time
Blind rollback	Legitimate later state is overwritten	Compare current state and detect conflicts
Consumer/managed mixing	Normal users see impossible controls	Separate managed mode/components/builds
Personal-device testing	Real data or access can be lost	Use disposable emulators only

7.2 Debugging Strategies

Authority snapshot first: Record active admin, owner role, user/profile, package, API, and current policy support.
Read-call-write-call-read trace: Separate every observation and side effect.
Plan preview: Inspect exact delta before touching DevicePolicyManager.
Step-level audit: Preserve partial progress rather than one generic exception.
Normal-install mirror: Reproduce the same navigation without owner state to prove refusal quality.
Snapshot checkpoints: Save clean, provisioned, applied, and rolled-back emulator states during development.

7.3 Performance Traps

Policy control is not a high-throughput workload. The main risks are excessive polling, repeated writes, and expensive package queries. Reconcile on explicit administrative action and relevant lifecycle signals rather than tight loops. Cache static descriptor metadata, not authority or observed policy truth. Debounce duplicate callbacks and serialize administrative runs. Optimize for explainability and safe recovery, not setter speed.

8. Extensions & Challenges

8.1 Beginner Extensions

Add a read-only managed-state inventory export with redaction preview.
Add an API/role explainer for every unavailable policy.
Add a visual comparison of screen pinning and DPC lock task.

8.2 Intermediate Extensions

Provision a managed-profile emulator and compare descriptor support.
Add managed configurations for an owned test application.
Add policy fitness tests that fail when a new target SDK changes support assumptions.

8.3 Advanced Extensions

Compare a custom DPC lab architecture with Android Management API.
Design affiliation and multi-user tests without using a real fleet.
Add a signed administrative intent workflow and independent audit sink.
Build a dedicated-device launcher prototype with a formally reviewed escape/recovery path.

9. Real-World Connections

9.1 Industry Applications

Retail and hospitality kiosks: Dedicated-device allowlists and recoverable lock task.
Field service fleets: Managed applications, restrictions, and remote support evidence.
Corporate BYOD: Work-profile separation and scoped enterprise policy.
Education devices: Managed app/configuration experiences with administrative audit.
Infrastructure management: Desired state, reconciliation, drift, and rollback patterns.

Test DPC: https://github.com/googlesamples/android-testdpc - Google’s sample for exploring Android Enterprise APIs in test environments.
AOSP ManagedProvisioning: https://android.googlesource.com/platform/packages/apps/ManagedProvisioning/ - Platform provisioning implementation context.
AOSP DevicePolicyManagerService: https://android.googlesource.com/platform/frameworks/base/ - Platform source for deeper policy behavior investigation.

9.3 Interview Relevance

Android Enterprise role and provisioning questions.
Security architecture around administrative authority and product-mode separation.
Distributed/configuration systems thinking about desired state and reconciliation.
Failure-handling questions about partial application and compensation.
Operational questions about audit, drift, compatibility, and deprovisioning.

10. Resources

10.1 Essential Reading

Build a DPC: https://developer.android.com/work/dpc/build-dpc - Current DPC architecture and enterprise-registration caution.
Provision devices: https://developer.android.com/work/dpc/provision-device - Supported provisioning concepts and scenarios.
Device management overview: https://developer.android.com/work/guide - Android Enterprise development entry point.
Dedicated devices: https://developer.android.com/work/dpc/dedicated-devices - Dedicated-device architecture.
Lock task mode: https://developer.android.com/work/dpc/dedicated-devices/lock-task-mode - DPC allowlisting and behavior.
Android Management API: https://developers.google.com/android/management - Current cloud management alternative for production fleets.

10.2 Video Resources

Android Enterprise official channel/resources: https://www.youtube.com/@AndroidDevelopers - Search for current dedicated-device and management sessions.
Android Enterprise help and training: https://support.google.com/work/android - Operational background for managed deployments.

10.3 Tools & Documentation

DevicePolicyManager API: https://developer.android.com/reference/android/app/admin/DevicePolicyManager
DeviceAdminReceiver API: https://developer.android.com/reference/android/app/admin/DeviceAdminReceiver
Test DPC: https://github.com/googlesamples/android-testdpc
Android Enterprise deployment scenarios: https://developers.google.com/android/work/requirements
Security best practices: https://developer.android.com/privacy-and-security/security-best-practices
Google Play Developer Program Policy: https://support.google.com/googleplay/android-developer/topic/9858052
User Data policy: https://support.google.com/googleplay/android-developer/answer/10144311

Project 1: Capability Navigator provides capability-state vocabulary.
Project 4: Durable Automation Library provides versioned desired state and migrations.
Project 10: Plugin SDK and IPC Host provides trust and compatibility contracts.
Project 12: Secure Webhook and Termux Bridge supplies bounded remote proposals.
Project 14: Automation Observatory adds fault injection and support evidence.
Project 15: FlowForge Automation Studio separates managed capabilities from consumer mode.

11. Self-Assessment Checklist

Before considering this project complete, verify:

11.1 Understanding

I can distinguish active admin, profile owner, device owner, and privileged app authority.
I can explain why owner authority is provisioned rather than requested at runtime.
I can explain lock task versus screen pinning.
I can describe desired, observed, applied, verified, and rolled-back policy states.
I can explain partial policy application without claiming transactionality.
I understand why this lab is not automatically a production EMM product.

11.2 Implementation

The normal install refuses all owner-only actions safely.
Current owner mode and policy support are proven before every run.
Two safe policies converge, verify, repeat idempotently, and reverse.
Lock task has a tested recovery route.
Reboot, process death, and partial failure scenarios produce truthful audit.
Rollback detects conflicting drift.
Emulator reset removes the managed lab state.

11.3 Growth

I documented one automation idea that belongs only in a managed-device product.
I can defend the consumer/managed module boundary.
I can explain the project in an Android Enterprise architecture interview.
I can compare custom DPC and Android Management API approaches at a high level.

12. Submission / Completion Criteria

Minimum Viable Completion:

Disposable-emulator provisioning and reset procedure.
Truthful authority/capability dashboard on normal and managed installs.
One reversible policy with read/diff/apply/verify/repeat/rollback evidence.
Step-level administrative audit.
Written consumer-versus-managed authority boundary.

Full Completion:

All minimum criteria plus a second policy, recoverable lock-task demonstration, partial-failure saga, reboot reconciliation, compatibility matrix, and rollback-conflict test.
Audit export with privacy classification and deletion controls.
Architecture decision record comparing lab DPC with production management alternatives.

Excellence (Going Above & Beyond):

Device-owner and profile-owner comparison across multiple API levels.
Automated fitness checks for descriptor/API compatibility and rollback availability.
A reviewed dedicated-device recovery playbook that another learner can execute safely.

This guide was generated from ANDROID_AUTOMATION_APPS_MASTERY.md. For the complete learning path, see the expanded project index.

Project 13: Managed-Device Policy Lab

Quick Reference

1. Learning Objectives

2. Theoretical Foundation

2.1 Core Concepts

2.2 Why This Matters

2.3 Historical Context / Background

2.4 Common Misconceptions

3. Project Specification

3.1 What You Will Build

3.2 Functional Requirements

3.3 Non-Functional Requirements

3.4 Example Usage / Output

3.5 Real World Outcome

4. Solution Architecture

4.1 High-Level Design

4.2 Key Components

4.3 Data Structures

4.4 Algorithm Overview

5. Implementation Guide

5.1 Development Environment Setup

5.2 Project Structure

5.3 The Core Question You’re Answering

5.4 Concepts You Must Understand First

5.5 Questions to Guide Your Design

5.6 Thinking Exercise

Authority Placement Matrix

5.7 The Interview Questions They’ll Ask

5.8 Hints in Layers

5.9 Books That Will Help

5.10 Implementation Phases

Phase 1: Authority Truth and Safe Lab (7-9 hours)

Phase 2: Reversible Desired-State Policy (8-12 hours)

Phase 3: Lock Task and Compatibility Evidence (11-17 hours)

5.11 Key Implementation Decisions

6. Testing Strategy

6.1 Test Categories

6.2 Critical Test Cases

6.3 Test Data

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

7.2 Debugging Strategies

7.3 Performance Traps

8. Extensions & Challenges

8.1 Beginner Extensions

8.2 Intermediate Extensions

8.3 Advanced Extensions

9. Real-World Connections

9.1 Industry Applications

9.2 Related Open Source Projects

9.3 Interview Relevance

10. Resources

10.1 Essential Reading

10.2 Video Resources

10.3 Tools & Documentation

10.4 Related Projects in This Series

11. Self-Assessment Checklist

11.1 Understanding

11.2 Implementation

11.3 Growth

12. Submission / Completion Criteria