Android Enterprise build tracker

Track: QPR3 Beta | Predecessor: QPR3 Beta 2 | Milestone: March 2027 stable

QPR3 Beta 3 is the largest single-build enterprise surface delta this tracker has recorded. Three major subsystems land simultaneously: Data Leak Prevention with a complete rules and enforcement stack, Advanced Security Telemetry with XDR-style monitoring, and Policy Streamlining V2 with a generic API and 43 per-policy sub-flags. Seven flags flip to true, including the policy streamlining master gate.

The policyStreamlining flag flips to true, activating the top-level gate for the AMAPI-aligned typed policy namespace. 43 per-policy sub-flags are added covering Bluetooth, camera, printing, Wi-Fi, ADB, USB, MTE, security logging, developer options, nearby streaming, and more. A new server-side StreamlinedPolicies class (~210 lines) implements the generic setPolicy(), getPolicy(), getResolvedPerUserPolicy(), and subscribeToResolvedPerUserPolicy() API backbone. All 43 per-policy sub-flags remain gated (return false), but the infrastructure is now live.

Six other flags also flip to true: dpmSecurityLevelWpaOnly, enforcingAdminExtraEnabled, enforcingAdminGetComponentNameEnabled, managedEsimOutgoingTransferPolicy, secureAdbRoleBypassing, and setTimeCoexistence.

A complete DLP stack lands across two packages (~38 classes total):

• API layer (android.app.admin.dataleakprevention) - DataLeakPreventionManager as a @SystemApi system service with content URI access checking, batch operations, and screen capture pre-checks. Rules defined via DataLeakPreventionRules with app-based and storage-based source/destination matchers. Verdict hierarchy: allow, block, or redact. New DPM operation OPERATION_SET_DATA_LEAK_PREVENTION_RULES (43) and policy identifier DATA_LEAK_PREVENTION_RULES_POLICY
• Reporting layer (android.app.admin.reporting.dataleakprevention) - 23-class reporting subsystem with 16 transfer action types covering copy-paste, screen capture (image and video), intent sharing, file operations (read, write, create, close, copy, move, zip), URI permission grants and checks, and printing

27 new XDR-style classes under android.app.admin.reporting.securitytelemetry covering:

• Process lifecycle - ProcessExecEvent and ProcessTerminateEvent with parent process attribution, image file hashes, and TCB (Trusted Computing Base) attributes
• Network monitoring - NetworkFlow with community ID, local/remote endpoints, protocol, direction (incoming/outgoing), and byte counters; NetworkSocketListenEvent for socket monitoring
• Agent monitoring - AgentStartEvent and AgentHeartbeatEvent for security agent health tracking

Gated behind advancedSecurityTelemetryEnabled (false) and xdrReportingEnabled (false).

• setMtePolicy(int) / setMtePolicy(String, int) - Memory Tagging Extension policy control
• setContentProtectionPolicy(ComponentName, int) / getContentProtectionPolicy(ComponentName) - content protection toggle per admin
• setAppFunctionsPolicy(int) - app functions policy control
• isOutgoingEsimTransferAllowed(int) - eSIM outgoing transfer check
• POLICY_SCOPE_LOGIN_SCREEN (4) - new policy scope for login screen
• LOGIN_ATTEMPT_STATUS_FAILED / LOGIN_ATTEMPT_STATUS_SUCCESS - login attempt tracking constants
• STATUS_SINGLE_USER_DEVICE_MANAGEMENT_NOT_SUPPORTED (25) - new provisioning status

New engine-level constructs formalise policy targeting and propagation:

• Resource - DeviceWide (singleton) or PerUser (cached per userId)
• Scope - Device (singleton) or User (cached per userId)
• PolicyPropagationRule - six values: SELF, LOGIN_TO_DEVICE, DEVICE_TO_DEVICE, DEVICE_TO_USER, INHERITABLE_PROFILE, SESSION_ACTIVE

Legacy handlers (EnumStoredAsBooleanPolicyHandler, EnumStoredAsGlobalAndLocalBooleanPolicyHandler, ListOfPackageIdentifierPolicyHandler) are deleted, their functionality absorbed into a new SimplePolicyHandler base class.

The PermissionController gains 28+ feature-flagged MANAGE_DEVICE_POLICY_* permissions including advanced security telemetry, bugreport, DLP, developer options, ethernet, MTE, nearby streaming, physical media, reboot, user removal, USB access, Wi-Fi, and more. Notable additions: MANAGE_DEVICE_POLICY_DATA_LEAK_PREVENTION, MANAGE_DEVICE_POLICY_ADVANCED_SECURITY_TELEMETRY, MANAGE_DEVICE_POLICY_REBOOT, and MANAGE_DEVICE_POLICY_REMOVE_USERS.

• Flags.java structural overhaul - all FLAG_* string constants removed, replaced with direct boolean accessor methods. 52 new flags, 5 removed (4 graduated into unconditional behaviour, 1 renamed)
• Policy validator framework - new android.app.admin.validator package with type-safe validators for enum, integer, string, list, and complex policy values
• Policy metadata framework - 14 domain-organised metadata classes covering advanced security, application management, branding, cross-device, DLP, date/time, device connectivity, device radio, reporting, security, sensors, and system policies
• PolicyDefinitionFactory expansion (+336 lines) - 15+ new factory-built policy definitions wired to enforcement
• DevicePolicyPrebuilt removed - CloudDPC prebuilt no longer present in the factory image extraction, possibly indicating a delivery mechanism change
• deviceTheftImplEnabled graduated (removed, now unconditional)
• enableNullableAdminComponent renamed to enableNullableAdminForAffiliationIds

Track: QPR1 Stable | Predecessor: A17 Stable (CP2A.260605.012) | Next milestone: QPR2 stable (December 2026)

This is the first quarterly platform release for Android 17, shipping to Pixel devices with the October 2026 security patch. It represents four months of enterprise development from the initial June stable through the QPR1 beta programme. The headline additions are data leak prevention, Policy Engine V2 infrastructure, and a broad expansion of the policy streamlining initiative.

An entirely new data leak prevention (DLP) framework arrives, giving DPC apps the ability to define rules that control how data moves between apps. Rules match on source app, destination app, and transfer type (data transfer or screen capture), with enforcement actions including block, redact, and report. Nine new framework classes handle rule definition, matching, and enforcement.

This mirrors the DLP capability that Chrome Enterprise already offers on ChromeOS devices, where DataLeakPreventionRulesList restricts clipboard, screenshot, printing, and file transfers by URL pattern. The Android implementation works by app rather than by URL, but the enforcement model is the same.

All DLP classes are shipped. The DPC-facing setDataLeakPreventionRules() API for writing rules and the MANAGE_DEVICE_POLICY_DATA_LEAK_PREVENTION permission are present in the beta track and expected in QPR2 stable.

Over 20 new feature flags land the infrastructure for migrating individual policy enforcement areas into a redesigned Policy Engine V2. Each flag gates one policy area - when enabled, that policy switches from legacy enforcement to the new typed resolution mechanism. The master switch is policyEngineV2.

Policy areas covered include account management, application visibility, application restrictions, audit logging, common criteria mode, content protection, keyguard features, lock task, password complexity, permission grants, screen capture, security logging, USB data signalling, and user restrictions, among others.

All V2 migration flags are provisional (still false). The infrastructure is in place but no individual policy has been switched over yet.

The typed PolicyIdentifier system continues its expansion. New policy categories now cover:

• Connectivity - physical SIM management, USB file transfer, USB data signalling, network reset, and Wi-Fi tethering minimum security level, each with typed allowed/disallowed values and minimum security level enforcement (WPA through WPA3)
• Security - safe boot, untrusted app installs, and app verification can now be managed through typed policies rather than legacy restriction APIs
• Application management - app install, app uninstall, and content safety app designation each get their own typed policy identifiers
• Branding - lock screen messages move to the typed policy system

Each policy category arrives as a new class under android.app.admin.policy with strongly typed values and constants.

All policy streamlining flags are provisional.

The provisionMultiuserManagedUser() API for provisioning managed users on multi-user devices is confirmed shipped. A new STATUS_INCOMPATIBLE_OS_BUILD error code (19) handles the case where the OS build does not support multi-user provisioning.

The framework-side API is ready, but neither ManagedProvisioning nor DevicePolicyPrebuilt (CloudDPC) currently expose MUM-specific activities or intent filters. The provisioning entry point exists in framework code but is not yet wired through the app layer.

A new kiosk user type (USER_TYPE_FULL_KIOSK) and admin status change broadcast (ACTION_USER_ADMIN_STATUS_CHANGED) also ship, supporting the multi-user device model.

Certificate key pair operations - removeKeyPair, hasKeyPair, and generateKeyPair - all gain a scope parameter, enabling DPC apps to manage certificates at either device-wide or profile scope. This is gated by the enableDeviceCertificates flag (provisional).

DPC apps can now subscribe to resolved policy state changes via addResolvedDeviceWidePolicyCallback(). When the effective policy value changes - whether because of a new admin, a policy update, or a conflict resolution - the callback fires with both the old and new values. The backing flag policyTransparencyRefactorEnabled has graduated to true (shipped).

Five flags have graduated from false to true, confirming these features are now live:

• policyTransparencyRefactorEnabled - the policy transparency callback system is active
• addUserInfoInProfileOffDeadlineAlarm - user info included in work profile off-deadline alarms
• checkPersonalSuspensionForAllProfiles - personal app suspension checks all profiles
• introduceGenericProvisioningError - generic provisioning error codes (including STATUS_INCOMPATIBLE_OS_BUILD)
• useHardenedFrpActiveCheck - hardened factory reset protection verification

These were all rolled back to false in the initial A17 stable release (June) but are now confirmed true in QPR1 stable.

The provisioning app receives security improvements:

• Backups explicitly disabled (allowBackup="false")
• Cleartext HTTP traffic no longer permitted (removed usesCleartextTraffic="true")
• Explicit network security configuration added (networkSecurityConfig)

Eight flags have been removed entirely, confirming their features are now unconditional or abandoned:

• associateDisallowGrantAdminWithPermission, removeDeviceAdminFeatureChecks, unsuspendNotSuspended, usePolicyIntersectionForPermittedInputMethods, userControlDisabledPackagesSettingsFix - all previously true, now graduated out
• enterpriseEsimUsingCarrierPrivileges - replaced by esimManagementEnabled/esimManagementUxEnabled
• policyStreamliningTests - test-only flag, removed
• wipeDeviceWhenWipedUserIsLastAdmin - replaced by the broader wipeDeviceWhenUserCannotBeRemoved

Android 17 base source is available in AOSP (android17-release branch). QPR1 source has not yet been published - Google's 2026 AOSP schedule targets Q2 and Q4, so the Q4 drop is expected to include QPR1 source.

Track: QPR3 Beta | Predecessor: QPR3 Beta 1 | Milestone: March 2027 stable

QPR3 Beta 2 expands the policy streamlining initiative with five new flags and six new permissions, adds a standalone provisioning manager for multi-user setups, and wires the advanced security telemetry subsystem into the network logging pipeline.

Five new policyStreamlining* flags extend the Engine V2 migration to additional policy domains:

• Incoming ADB - end-to-end policy chain from flag (policyStreamliningIncomingAdb) through INCOMING_ADB policy definition, enforcer callback, and MANAGE_DEVICE_POLICY_INCOMING_ADB permission. DPCs will be able to manage ADB access via typed policy rather than legacy restriction APIs
• Managed Wi-Fi credential sharing - gates MANAGE_DEVICE_POLICY_MANAGED_WIFI_CREDENTIALS_SHARING permission for Wi-Fi credential sharing policy
• Modes synchronisation - gates MANAGE_DEVICE_POLICY_MODES_SYNC for cross-device mode sync policy
• Printing - printing restrictions via the typed policy engine
• In total, six new feature-flagged permissions land in the PermissionController manifest this build, including MANAGE_DEVICE_POLICY_REMOVE_USERS for device controller user removal

All five flags are provisional (return false).

A new ProvisioningManager class provides a standalone orchestrator for multi-user managed user setup. It validates provisioning preconditions via ProvisioningPreconditionChecker, then delegates to DPMS to set the active admin and profile owner on the target user. The provisioning action android.app.admin.action.PROVISION_MULTIUSER_MANAGED_USER is the entry point. This builds on the createManagedUser() API introduced in QPR3 Beta 1.

The NetworkLoggingHandler gains an AdvancedSecurityTelemetrySource interface, connecting the advanced security telemetry subsystem (first introduced in Canary 7) to the network logging pipeline. When the DPC is not actively streaming logs, the handler schedules telemetry polling at 60-second intervals. This is the first concrete integration point between the new XDR-style telemetry system and the existing enterprise logging infrastructure.

A new SimplePolicyHandler base class extracts the common store/get/resolve pattern from PolicyHandler. Several existing handlers - including WifiStatePolicyHandler, TetheringPolicyHandler, CameraAccessPolicyHandler, and EnumStoredAsBooleanPolicyHandler - now extend SimplePolicyHandler instead of PolicyHandler directly. This simplifies adding new typed policy handlers going forward.

• allowDeviceControllerRemoveUser (provisional) - new flag gating device controller user removal, paired with MANAGE_DEVICE_POLICY_REMOVE_USERS permission
• Support message migration hooks - Owners gains test methods for short and long support message migration, supporting the policy streamlining effort for branding messages
• Removed flags - suspendPackagesCoexistence (was true) and useHardenedFrpActiveCheck (was true) have been removed entirely, confirming these features are now unconditional behaviour
• advancedSecurityLoggingEnabled renamed - now advancedSecurityTelemetryEnabled (this rename first appeared in QPR3 Beta 1)
• No new public DPM methods or DISALLOW_ restrictions* - the API surface is unchanged from QPR3 Beta 1

All new flags return false - none have graduated yet.

Track: QPR3 Beta (new track) | Branch point: QPR2 Beta 7.1 (CP41.260831.019) | Milestone: March 2027 stable

The first QPR3 Beta brings the most enterprise-significant changes since QPR2 Beta 1, with new APIs, deeper policy engine infrastructure, and 17 new feature flags (14 provisional, all currently false).

Managed user creation - A new @SystemApi method createManagedUser() enables programmatic creation of managed users via CreateManagedUserParams, with async callbacks for success (UserHandle) or failure (ManagedUserCreationException). This is a key building block for multi-user management (MUM) scenarios. Gated by createManagedUserApi (provisionally false).

Scoped certificate installation - installKeyPairWithScope() adds an explicit scope parameter to certificate installation, and a new installKeyPair overload takes Collection<Certificate> with a scope integer. These complement the scoped certificate APIs (remove, has, generate, grant, revoke) introduced in QPR1/QPR2. Gated by enableDeviceCertificatesPhase2 (provisionally false).

The Engine V1-to-V2 migration trigger (triggerDevicePolicyEngineMigration) has been removed entirely, confirming V2 is now the sole engine path. Seven new policyStreamlining* flags gate additional policies being migrated to the typed engine model:

• Bluetooth, camera access (with new CameraAccessPolicyHandler), complex-type policies, long support message, nearby app streaming, nearby notification streaming, time zone, Wi-Fi state (with new WifiStatePolicyHandler)

The internal transport layer switched from string-based policy IDs to typed PolicyIdentifierTransport objects across all policy setter/getter methods. New engine/Resource and engine/Scope types provide structured device-wide vs per-user targeting.

• advancedSecurityLoggingEnabled renamed to advancedSecurityTelemetryEnabled - reflects the broader scope of the security telemetry subsystem
• securityLogStreamingEnabled (provisional) - real-time streaming delivery of security log events
• requestBugreportForMum (provisional) - bug report collection on multi-user managed devices
• forceResetAdbProvisionedDo (provisional) - force-reset of ADB-provisioned device owners
• canAdminGrantSensorsPermissions now takes a user ID (per-user sensor permission granting)
• canAddPrivateProfile() deprecated - throws UnsupportedOperationException in "Android D" (QPR3); replaced by isUserTypeSupported()
• Provisioning logic refactored - precondition checks moved to a dedicated ProvisioningPreconditionChecker with delegate pattern
• GooglePermissionController ships as platform build (version 330000000) rather than the Mainline module (373040300)

All 14 new flags return false - none have graduated yet.

Track: QPR2 Beta | Predecessor: QPR2 Beta 6 | Milestone: December 2026 stable

No enterprise-surface changes in this build. CP41.260831.016 is the October security patch for the QPR2 beta track, released on October 7. The framework and server-side device policy code are functionally identical to the previous build - all differences are decompilation artefacts (lambda renumbering, resource ID shifts) and updated localisation strings.

Track: Canary | Predecessor: Canary 6 | Note: canary builds are forward-looking and may not ship in the next stable release

A major canary update introducing an advanced security telemetry subsystem (51 new classes for process and network monitoring), a full Data Leak Prevention system service, managed user creation, three new policy engine handlers, and a wave of 21 new flags covering policy streamlining, security telemetry, and multi-user management.

DPC capabilities

• Advanced security telemetry (provisional) - a new subsystem of 51 classes gated by advancedSecurityTelemetryEnabled. Provides enterprise threat detection via process lifecycle events (ProcessExecEvent, ProcessTerminateEvent), network flow monitoring (NetworkFlowEvent, NetworkSocketListenEvent), and security agent health checks (AgentStartEvent, AgentHeartbeatEvent). This is kernel-level security telemetry for enterprise devices - a significant new capability with no predecessor on any track
• Data Leak Prevention Manager (provisional) - new @SystemApi system service (DataLeakPreventionManager) for content URI access checks, batch DLP operations, and print/screen capture enforcement. Methods include checkContentUriAccess(), batchCheckContentUriAccess(), checkPrintingAction(), and precheckScreenCaptureAction(). Supports three UI handling modes: SILENT, SYSTEM_OWNED, and CALLER_OWNED. Not present in the previous canary - this is the first appearance of a standalone DLP system service
• Managed user creation API (provisional) - new createManagedUser(CreateManagedUserParams, Executor, OutcomeReceiver) on DevicePolicyManager. Asynchronous creation of dedicated-task users for multi-user managed device deployments. Gated by createManagedUserApi (false). Only accepts USER_TYPE_FULL_DEDICATED_TASK
• Device certificates phase 2 (provisional) - new installKeyPair overload with Collection<Certificate> and explicit scope parameter. Gated by enableDeviceCertificatesPhase2. Enables certificate scoping to specific contexts
• 21 new policy flags (provisional) - all gated at false. The largest single-build flag batch to date, covering 13 policy streamlining domains (Bluetooth, camera access, content capture, long support message, nearby app/notification streaming, Wi-Fi state/Direct, set time zone, complex types, application policy), plus advanced security telemetry, security log streaming, managed user creation, per-user sensor permissions, bug reports for multi-user management, and several bug fix and refactoring gates
• Camera, tethering, and Wi-Fi state policy handlers (provisional) - three new PolicyHandler subclasses landed. CameraAccessPolicyHandler maps USER_CHOICE/ENABLED/DISABLED to camera restrictions. TetheringPolicyHandler enforces tethering and Wi-Fi tethering restrictions. WifiStatePolicyHandler enforces the Wi-Fi state restriction. Each integrates with the typed policy engine V2
• PolicyIdentifier transport migration - systematic migration from policyIdentifier.getId() to policyIdentifier.toTransport() across setPolicy, getPolicy, getResolvedDeviceWidePolicy, getResolvedPerUserPolicy, and getEnforcingAdminsForPolicyIdentifier. The new PolicyIdentifierTransport Parcelable enables richer typed policy identification across process boundaries
• Kiosk to dedicated-task rename - USER_TYPE_FULL_KIOSK renamed to USER_TYPE_FULL_DEDICATED_TASK and isUserTypeKiosk() to isUserTypeDedicatedTask(). Canary now aligns with the beta track naming (beta adopted this in QPR2 Beta 5). The scope broadens from kiosk-only to general dedicated-task user types
• Security log streaming flag - securityLogStreamingEnabled signals future real-time security event delivery. Currently canary has both the telemetry subsystem and streaming flag - together they represent a step-change in enterprise security monitoring capability
• Per-user sensor permission grants - canAdminGrantSensorsPermissionsPerUser flag and corresponding per-user userId parameter on canAdminGrantSensorsPermissions(). Sensor permissions can now be granted per-user rather than device-wide

Other enterprise changes

• Policy engine V2 plumbing expanded - CONTENT_PROTECTION and MEMORY_TAGGING_EXTENSION now conditionally handled by Engine V2 via setIsHandledByEngineV2Supplier(). New buildOrThrow() method on PolicyDefinition for safer construction. Resource and Scope interfaces added for formalised policy resource targeting
• Legacy permission centralised - new LegacyPermissionRegistry extracts DO/PO/financed DO permission lists from inline DPMS code into a single registry class
• Visible background users API rename - isVisibleBackgroundUsersSupported() deprecated in favour of isVisibleBackgroundFullUsersSupported(). The "Full" qualifier disambiguates from profile-type background users
• triggerDevicePolicyEngineMigration removed - the policy engine migration trigger is no longer exposed as public API
• GooglePermissionController - ConfirmationActivity removed from manifest, layout renames, and localisation string updates across all locales. No new enterprise permissions or components

Cross-track note: a notable convergence - canary now uses USER_TYPE_FULL_DEDICATED_TASK, matching QPR2 Beta's independent rename from USER_TYPE_FULL_KIOSK. The remaining cross-track divergences persist: canary carries crossUserSuspensionEnabledRo and isRecursiveRequiredAppMergingEnabled at true, the beta track still has streaming network log infrastructure that canary lacks, and several beta-track flags (advancedSecurityLoggingEnabled, permissionManageAffiliationIds) are not present on canary. The new security telemetry and DLP Manager subsystems are canary-first - not yet present on the beta track.

Track: QPR2 Beta | Predecessor: QPR2 Beta 5 | Milestone: December 2026 stable

The policy type system becomes extensible, managed device detection narrows its scope, and device controllers gain the ability to manage affiliation IDs.

DPC capabilities

• Policy identifier extensibility - the policy type system has been refactored to support richer, typed policy identifiers beyond simple string-keyed entries. This is the architectural groundwork for compound policies that group related app management operations. One policy - content capture - was deliberately left on the old type, suggesting it will receive a specialised identifier
• Application policy streamlining (provisional) - a new flag extends the policy streamlining effort into a broader "application policy" scope, likely covering install, uninstall, and related app management operations as a compound policy rather than individual entries
• Device admin race condition fix (provisional) - a new flag addresses a race condition when enabling a device admin, fixing a correctness issue with concurrent admin enablement paths
• ADB role bypass relocation (provisional) - a new flag suggests the ADB role-bypassing security check is being relocated, tightening the security boundary around ADB access in managed environments
• Affiliation ID management for device controllers (provisional) - device controllers can now manage affiliation IDs, which determine whether a work profile and device owner belong to the same organisation. Previously only available to the device owner directly

Other enterprise changes

• Managed device detection narrowed - isDeviceManaged() no longer returns true for company-owned work profile (COPE) devices. The server-side implementation now checks only for a device owner. DPC apps or management tools relying on this method returning true for COPE deployments will see changed behaviour
• Binder cache consistency at ownership transitions - a new cache invalidation method is called at all four ownership state transition points (set device owner, clear management, set organisation-owned profile owner, provision multi-user managed device). This ensures cached managed device state stays consistent during provisioning and teardown
• Visible background users API renamed - the visible background users APIs have been renamed to include "Full" to distinguish full users from profile-type visible background users. The old methods are preserved as deprecated wrappers
• Private profile creation check removed - the deprecated canAddPrivateProfile() method has been removed from UserManager. Private Space creation checks are simplified elsewhere

Track: Canary | Predecessor: Canary 5 | Note: canary builds are forward-looking and may not ship in the next stable release

A policy expansion canary that adds nine new flags, lands task continuity handoff enforcement, and refactors the network logging handler for thread safety.

DPC capabilities

• Nine new policy flags (provisional) - all gated at false, covering device controller reboot (allowDeviceControllerReboot), security logging for login attempts and package failures, policy streamlining for support messages, first-use hints, and task continuity handoff, plus multi-user and network log streaming scaffolding. These are new on the canary track - several also appeared independently on QPR2 Beta
• Task continuity handoff enforcement (provisional) - the CrossDevice.TASK_CONTINUITY_HANDOFF handler landed in PolicyHandlerFactory, mapping the policyStreamliningTaskContinuityHandoff flag to the no_task_continuity_handoff user restriction. This completes the enforcement plumbing for controlling cross-device task handoff via the typed policy engine
• Certificate selection suppression rolled back - keychainSuppressCertificateSelections flipped from true back to false. This had been enabled on canary since canary 4; the rollback suggests the feature needs further work before graduation

Other enterprise changes

• Network logging handler thread-safety refactor - the entire NetworkLoggingHandler was rewritten from synchronized blocks to a handler-thread-only pattern with checkHandlerThread() assertions. All public methods now post to the handler thread. This improves batch collection reliability but is not a feature change - canary remains batch-only for network logging
• Management app abstraction broadened - notifyDeviceOwnerOrProfileOwner() renamed to notifyDeviceManagementApp(), reflecting the shift from device owner/profile owner to the broader device management app concept
• Delegation authorisation simplified - the event-logging authorisation wrapper was removed from the device policy manager service. Delegation scope checks are now cleaner direct authorisation calls without the intermediate audit layer
• Headless system user login screen detection (provisional) - new isHeadlessSystemUserLoginScreen() method for detecting HSU-as-login-screen configuration. Still behind a test flag
• MTE validation standardised - Memory Tagging Extension hardware checks now throw ServiceSpecificException instead of UnsupportedHardwareException, aligning with standard Android service error patterns
• RCS message restrictions now feature-flagged - restricted RCS message access in the permission controller moved from static SDK version gating to a runtime feature flag, allowing the restriction to ship independently of the platform version
• Recursive overlay app list resolution unchanged - isRecursiveRequiredAppMergingEnabled remains enabled on canary, carrying forward from canary 5

Cross-track note: the canary and QPR2 Beta tracks continue to diverge in several areas. The beta track has streaming network log scaffolding, content capture and Wi-Fi Direct typed policies, and an affiliation ID permission gate that are not present on canary. Conversely, canary carries crossUserSuspensionEnabledRo and isRecursiveRequiredAppMergingEnabled at true whilst the beta track still has them gated. The kiosk user type naming also differs - canary uses USER_TYPE_FULL_KIOSK, beta uses USER_TYPE_FULL_DEDICATED_TASK. These are independent branch choices, not directional changes.

Track: QPR2 Beta | Predecessor: QPR2 Beta 4 | Milestone: December 2026 stable

The kiosk user type gets a rename with broader semantics, three new typed policies extend the streamlining effort, and device controllers gain scaffolding for programmatic reboots.

DPC capabilities

• Content capture restriction (provisional) - a new DLP policy controls whether content capture (screen recording, accessibility-based capture) is permitted on managed devices. This sits alongside existing screen capture and assist content restrictions in the data leak prevention namespace
• Wi-Fi Direct control (provisional) - administrators will be able to allow or block Wi-Fi Direct connections through the typed policy engine. Wi-Fi Direct was previously unmanaged
• First-use hints (provisional) - already flagged in Beta 4, the backing policy identifier and constants are now in place for controlling first-use hints via the policy engine
• Device controller reboot (provisional) - a new permission is registered for the device controller role. When enabled, device controllers will be able to programmatically reboot managed devices

Other enterprise changes

• Kiosk renamed to dedicated task - the kiosk user type is now called "dedicated task", signalling a semantic broadening from single-app kiosk mode to a more general-purpose dedicated task user type. Worth watching for how this surfaces in AMAPI kiosk provisioning
• Session-scoped policy propagation - a new session-active propagation rule appeared in the policy engine alongside the existing device-wide, user-scoped, and inheritable profile rules. This likely supports login screen and kiosk session policy enforcement, building on the login screen policy scope introduced in Beta 1
• Multi-user provisioning hardened - a standalone precondition checker now validates multi-user managed device provisioning with explicit error codes covering setup completion, incompatible accounts, OS build requirements, and device management role holder status
• Headless system user login screen - a new method detects whether the device is configured to use the headless system user as a login screen, advancing shared device UX. Still behind a test flag
• Security log improvements - security events gained a method for efficient duplication and an enhanced redaction overload that supports flexible per-user event filtering
• App interaction access management - the manage access activity in PermissionController is now exported with an intent filter for managing interactor target access, completing the agent-to-interactor terminology rename and enabling external apps to manage app interaction permissions

Track: QPR2 Beta | Predecessor: QPR2 Beta 3 | Milestone: December 2026 stable

Platform stability reached. The enterprise API surface is frozen. What ships in this build ships in the December 2026 stable QPR2 release.

DPC capabilities

• Streaming network logs (provisional) - DPC apps will be able to receive network log events in real time as they happen, rather than fetching them in batches after the fact. Still gated - not yet active
• Secure ADB role bypass enabled - ADB access can now bypass traditional device owner and profile owner requirements using the newer role-based permission model. This was previously only available in canary builds and is now confirmed for the stable track
• Query managed profiles - DPC apps can ask the system which profiles on a device are under policy management for a given user, useful for multi-profile management interfaces
• Track policy quota - DPC apps can check how much of the policy size budget a particular admin has consumed, enabling monitoring in multi-admin environments

Other enterprise changes

• DLP storage matchers (provisional) - the data leak prevention framework gained new matchers for portable storage (USB drives, SD cards) and shared storage, including affiliation-aware filtering. These extend the DLP rules introduced in Beta 3
• Cross-device task handoff policy (provisional) - a new policy namespace allows controlling whether task continuity handoff (handing a task from one device to another) is permitted, with proper multi-admin resolution where the most restrictive setting wins
• Package metadata class (provisional) - a new structured class for describing installed packages with installation source, version, display name, and signing certificates. Likely feeds into DLP and security logging decisions
• First-use hints policy (provisional) - a new permission and flag for controlling first-use hints via the typed policy engine
• Package failure security logging (provisional) - a new flag for logging app install, update, and uninstall failures to the security log
• Network logging delegation - network log access is now delegatable via the permission-based model, removing the need for traditional admin delegation

Track: QPR2 Beta | Predecessor: QPR2 Beta 2 | Milestone: December 2026 stable

Three enterprise flags graduated to enabled, and the DLP rules framework gained its set/get API.

Flag graduations

Three flags moved from provisional to enabled in this build:

• Typed policy engine (policyStreamlining) - the master switch for the new type-safe policy interface is now on. DPC apps will be able to use setPolicy and getPolicy with proper typed identifiers and built-in multi-admin conflict resolution
• eSIM transfer control (managedEsimOutgoingTransferPolicy) - DPC apps can now query whether an eSIM profile is allowed to be transferred off a managed device
• WPA-only Wi-Fi (dpmSecurityLevelWpaOnly) - administrators can enforce WPA as the minimum Wi-Fi security standard, blocking connections to open or WEP networks

DPC capabilities

• Data leak prevention rules - DPC apps can now set and retrieve DLP rules directly, mirroring the approach used on ChromeOS. This is the enforcement side of the DLP framework introduced in QPR1 Beta 5
• Login attempt logging (provisional) - DPC apps can report user login attempts (success or failure) to the security log, enabling audit trails for shared and multi-user devices
• Per-user policy callbacks - DPC apps can now register for real-time notifications when a per-user policy value changes, complementing the device-wide callbacks added in QPR1 Beta 6
• Stricter sideloading control - a new user restriction blocks all non-Play app installation including from registered app stores (Samsung Galaxy Store, Amazon Appstore, etc.). Paired with a new registered app store role

Other enterprise changes

• Task continuity handoff policy (provisional) - a new cross-device policy namespace controls whether task handoff between devices is permitted
• Short support message policy (provisional) - the customisable short support message shown to users is now available through the typed policy engine
• Play Protect verification policy (provisional) - Play Protect's verify apps setting can now be controlled through the typed policy engine
• Wi-Fi policy restructured - the Wi-Fi tethering, network selection, and local-only hotspot policies moved into a dedicated inner namespace, improving organisation
• Five new permissions (provisional) - registered for DLP rules, subscription management, task continuity, device identifiers, and support messages - several still gated behind false flags
• XDR telemetry source registration (provisional) - extended detection and reporting source registration appeared, though the backing flag is still off
• Content restriction enforcement landed in the QPR2 track, having previously been canary-only

Track: Canary | Predecessor: Canary 4 | Note: canary builds are forward-looking and may not ship in the next stable release

Introduces the registered app store role and content restriction enforcement.

DPC capabilities

• Registered app store role (provisional) - a new non-exclusive, invisible role allows qualifying app stores to install packages as a registered source. This is paired with the new DISALLOW_INSTALL_UNKNOWN_SOURCES_INCLUDING_REGISTERED_APP_STORES restriction (landed in QPR2 Beta 3), giving administrators a stricter sideloading option that also blocks registered stores
• Content restriction enforcement - the content safety apps policy gained its enforcement path, actually pushing content safety app lists to the restriction manager. This was canary-only here but landed in the QPR2 track in Beta 3
• Secure ADB role bypass (enabled) in the canary track (later graduated to QPR2 Beta 4)

Other enterprise changes

• Policy handler refactoring - new PolicyHandler, PolicyValidator, and PolicyHandlerFactory classes replace inline policy logic, moving toward a cleaner typed handler lifecycle
• Permission checking decoupled - a new interface for permission checks decouples enforcement from the device policy manager service, improving testability
• Login screen policy stub - a stub for setting login screen policies appeared, confirming this scope is under active development (the constant POLICY_SCOPE_LOGIN_SCREEN = 4 landed in QPR2 Beta 1)

Track: QPR2 Beta | Predecessor: QPR2 Beta 1 | Milestone: December 2026 stable

Security logging decomposition, scoped certificate management, and policy engine expansion.

DPC capabilities

• Scoped certificate management (provisional) - seven new methods let DPC apps manage certificates with explicit scope (user or device). Admins can grant, revoke, and query certificate access for both apps and Wi-Fi authentication, scoped to either the individual user or the whole device. Previously, certificate operations applied globally
• Granular security logging (provisional) - security logging splits from a single device-wide toggle into separate device-level and user-level policies. DPC apps will be able to enable security logging per user rather than all-or-nothing
• User logout tracking (provisional) - a new security log event captures when users log out, supporting audit requirements on shared devices

Other enterprise changes

• Network logging is now user-aware - network logging moves from tracking a single user to maintaining a set of active users, preparing for proper multi-user network audit
• DLP verdict types expanded - the data leak prevention verdict system gained a polymorphic structure with distinct allow, block, and redact outcomes, enabling more nuanced content-level DLP decisions
• Policy engine expansion (provisional) - eleven new policy identifiers registered across content protection, eSIM transfer, factory reset, Easter eggs, device security logging, user security logging, Bluetooth sharing, Wi-Fi local-only hotspot, and more - all still gated
• Connectivity policies restructured - the device connectivity management namespace gained inner classes for USB, mobile networks, VPN, and Wi-Fi, grouping related policies by domain
• Policy default values - the policy metadata system now supports explicit default values per policy, simplifying migration and resolution
• Kiosk user type helper - a new utility method identifies kiosk user types, replacing a deprecated approach
• Eight new flags (provisional) - covering content protection, security logging, Wi-Fi hotspot policy, user logout logging, XDR reporting, and more - all still gated

Track: QPR2 Beta | Predecessor: Android 17 QPR1 stable | Milestone: December 2026 stable

The first QPR2 build, with a notable architectural change to the policy engine and several new policy areas.

DPC capabilities

• eSIM transfer query renamed - the method for checking whether an eSIM can be transferred off-device was renamed to isOutgoingEsimTransferAllowed, clarifying its purpose
• Policy enforcement attribution - DPC apps can now query which admins are enforcing a given typed policy on a specific user, useful in multi-admin environments where understanding who set a policy matters
• Developer options policy (provisional) - a new typed policy for controlling developer options access, with allowed and disallowed states
• Login screen policy scope (provisional) - a new policy scope targets the login and lock screen context specifically, enabling policies that apply only before a user signs in

Other enterprise changes

• Policy metadata decentralised - the monolithic policy definitions file was deleted and replaced by eight per-namespace supplier classes that load lazily. This modular approach scales to the volume of policies needed for platform convergence with ChromeOS
• Three flags graduated in this build: enforcingAdminExtraEnabled, enforcingAdminGetComponentNameEnabled, and setTimeCoexistence
• Memory tagging policy (provisional) - a new typed policy for controlling ARM Memory Tagging Extension (MTE) with enabled, disabled, and user choice states
• Ethernet policy (provisional) - a new permission for managing Ethernet state through the policy engine
• Extended serial numbers (provisional) - the enterprise-specific ID calculator now supports serial numbers longer than 16 characters
• Lock screen message permission renamed for consistency (from LOCKSCREEN to LOCK_SCREEN)
• Pre-created users blocked - creating users in advance now throws an exception when the feature is disabled, preventing unexpected user states
• Policy type validation - policy values are now validated for correct types before size checks, catching malformed policy data earlier

Track: QPR1 Beta | Predecessor: QPR1 Beta 6 | Milestone: September 2026 stable

The final QPR1 beta before stable, focusing on physical media, tethering policies, and certificate management improvements.

DPC capabilities

• Physical media access control (provisional) - DPC apps will be able to restrict access to USB drives and SD cards through the typed policy engine, mapping to the existing no_physical_media restriction with proper multi-admin resolution
• Tethering settings policy (provisional) - DPC apps will be able to control tethering (hotspot) settings through the policy engine, with a dedicated permission
• Wi-Fi hotspot security level (provisional) - administrators will be able to set a minimum security level for Wi-Fi hotspots, with an ordering from any security through WPA2, WPA2/WPA3, to WPA3-only

Other enterprise changes

• Branding policy namespace - the lock screen message policy moved into a dedicated Branding namespace, improving organisation for branding-related policies
• Safe boot policy namespace move - safe boot control moved into AdvancedSecurityOverrides with proper typed allowed/disallowed constants
• Certificate management simplified - the separate permission checks for certificate installation were consolidated into a single gate that handles both permission-based and credential-management-app access, reducing complexity for certificate operations
• Policy engine resilience - if a single policy fails during reapplication (for example after a reboot), it no longer cascades and breaks other policies. Each policy is now handled independently

Track: QPR1 Beta | Predecessor: QPR1 Beta 5 | Milestone: September 2026 stable

Introduces real-time policy change callbacks and scoped key generation.

DPC capabilities

• Real-time policy change callbacks - DPC apps can now register to be notified whenever a device-wide policy value changes, enabling reactive monitoring rather than polling. When multiple admins set conflicting policies, the callback reports the resolved (winning) value
• Scoped key generation (provisional) - building on the scoped certificate framework from Beta 5, DPC apps can now generate key pairs scoped to either the user or device level

Other enterprise changes

• Subscription policy streamlining (provisional) - a new flag and permission for managing eSIM subscriptions through the typed policy engine
• Network logging policy (provisional) - network logging is being migrated to the typed policy engine, with metadata registered
• Network reset policy (provisional) - network reset restrictions are being migrated to the typed policy engine
• Supervision sync rolled back - the supervision service sync feature was rolled back to disabled in this build after being enabled in earlier betas
• Provisioning backup blocked - the provisioning app now explicitly disables backup, preventing provisioning state from being restored from a backup onto a different device
• Headless system user permission string - a new localised string across 60+ languages explains to non-admin users on headless system user devices that their permissions are managed by an admin
• App interaction rename - the app functions framework began its rename to app interaction, with activities and strings updated in this build. Intent actions and the permission rename were finalised in Beta 7

Track: QPR1 Beta | Predecessor: QPR1 Beta 4 | Milestone: September 2026 stable

One of the largest enterprise builds tracked so far. Introduces the data leak prevention framework, policy namespace classes, scoped certificate management, and the foundation for policy engine V2.

DPC capabilities

• Data leak prevention framework (provisional) - nine new classes landed for defining DLP rules at the app level. This mirrors the DLP approach used on ChromeOS, where administrators define rules that allow, block, or redact content based on the source and destination. The Android version works with package names rather than URLs. The enforcement path landed later in QPR2 Beta 3
• Scoped certificate removal and query (provisional) - DPC apps can now remove and query certificates scoped to either the user or the device, rather than operating globally. This is the start of the scoped key pair management feature
• Cross-profile widget providers - the policy for controlling which apps can provide widgets across the work/personal boundary graduated to the public API. The older per-package methods are now deprecated in favour of a set-based approach

Other enterprise changes

• Policy namespace classes - new namespace classes for AdvancedSecurityOverrides, DeviceConnectivityManagement, and DateTime group related policies together, rather than keeping them all in a flat list. This is a structural improvement that scales to the volume of policies expected as Android and ChromeOS management converge
• Policy engine V2 foundation (provisional) - a master policyEngineV2 flag and 27 per-policy migration flags appeared, all still off. These gate the next generation of the policy engine that will handle routing policies through either the V1 or V2 path
• Untrusted apps policy (provisional) - a new typed policy for controlling untrusted app installation
• Play Protect verification policy (provisional) - a new typed policy for controlling Play Protect's verify apps setting
• Physical SIM management (provisional) - a new permission for managing physical SIM policies, granted to the supervision role
• Common criteria mode (provisional) - a new typed policy definition for Common Criteria mode with proper multi-admin resolution
• OS build compatibility check - the STATUS_HEADLESS_SYSTEM_USER_MODE_REQUIRED constant was renamed to STATUS_INCOMPATIBLE_OS_BUILD, broadening its meaning beyond headless mode
• Three new permissions (provisional) - registered for assist content, cellular data usage, and physical SIM management - each gated behind a still-false flag
• Content safety role behaviour - the content safety role gained a dedicated behaviour class
• Permitted input methods graduated - the permitted input methods intersection policy graduated and was removed (flag and method both deleted), meaning it is now the default behaviour

Track: Stable | Predecessor: Android 16 Stable (April)

The first stable Android 17 release. This is a cross-version comparison against Android 16 - every difference is a genuine version change, not a beta progression. The headline story is the typed policy engine and multi-user device provisioning, both of which ship in this release with their API surfaces live.

Multi-admin typed policy engine

• Typed policy API shipped - DPC apps can now use setPolicy, getPolicy, getResolvedDeviceWidePolicy, and getResolvedPerUserPolicy with typed PolicyIdentifier<T> parameters. The engine mediates policy conflicts between multiple admins automatically. Eleven typed policies are defined: screen capture, auto-time, auto-timezone, eSIM outgoing transfer, lockscreen message, content restriction apps, app install, app uninstall, easter eggs, factory reset, and Bluetooth sharing. The API surface is live, but individual policy-streamlining flags remain gated at false - expect enablement in QPR releases
• Cross-profile widget providers (enabled) - setCrossProfileWidgetProviders(Set) is now live. DPCs can set all cross-profile widget providers in a single bulk call rather than adding and removing packages individually
• Lock now coexistence (enabled) - multiple admins can coexist when triggering device lock. The policy engine now mediates lock-now calls instead of the most restrictive admin winning silently
• Permitted input methods intersection (enabled) - when multiple admins set permitted input methods, the intersection is enforced. This is tighter than the previous union behaviour and improves security for multi-admin deployments
• 22 new policy streamlining flags (provisional) - individual migration flags for app install, app uninstall, auto-time, auto-timezone, Bluetooth sharing, factory reset, easter eggs, keyguard status, lockscreen message, maximum time to lock, and screen capture API - all at false. These will progressively activate as the legacy DPM methods migrate to the typed engine

Multi-user device management

• Multi-user provisioning API shipped - a complete provisioning flow with state machine (unmanaged, started, completed), typed provisioning parameters, and async callbacks. EMMs can call provisionMultiuserManagedDevice() and provisionMultiuserManagedUser() to set up shared-device scenarios - kiosks, frontline workers, education labs
• Device controller role (provisional) - a new DEVICE_CONTROLLER role, lighter than device owner, purpose-built for shared-device controllers. It grants permissions for content protection, debugging features, input methods, lockscreen messages, organisation identity, safe boot, and time setting. Gated by multiUserManagementDeviceProvisioning
• Provisioning naming normalised - all multi-user provisioning actions and methods moved from MultiUser to Multiuser casing. DPCs referencing the old action strings (ACTION_PROVISION_MULTI_USER_DEVICE) should update to ACTION_PROVISION_MULTIUSER_MANAGED_DEVICE

User restrictions

• Guest user restriction (shipped) - the new DISALLOW_ADD_GUEST restriction lets DPCs explicitly block guest user creation without the broader DISALLOW_ADD_USER
• Task continuity handoff (shipped) - DISALLOW_TASK_CONTINUITY_HANDOFF replaces the A16 DISALLOW_HANDOFF with a clearer name. DPCs should migrate - the old restriction string is removed
• Headless system user badge support - hasBadge() now returns true for user 0 in headless system user mode, improving app management UX on HSU devices

DPM role holder changes

• Account management permissions - the device policy management role holder gains COPY_ACCOUNTS and REMOVE_ACCOUNTS (gated by splitCreateManagedProfileEnabled), supporting managed profile creation workflows
• Biometric strength query - ACCESS_BIOMETRIC_SENSOR_STRENGTHS added to DPM, system activity, and wallet roles
• App function permissions - DISCOVER_APP_FUNCTIONS and EXECUTE_APP_FUNCTIONS_SYSTEM added to the system activity and DPM roles
• Show power menu - SHOW_POWER_MENU permission added to the assistant and DPM roles (gated by statusbarApiShowPowerMenu)

Other enterprise changes

• Feature flags baked into build - the FeatureFlags/FeatureFlagsImpl runtime delegation layer was removed. All admin flags are now hardcoded static methods in the stable image - no runtime override possible
• Nullable admin component (enabled) - enableNullableAdminComponent shipped true, replacing the A16 dontWriteIsSystemAuthority flag. Allows admin components to be null in policy engine records, supporting role-based management without a concrete DeviceAdminReceiver
• User-control-disabled-packages settings fix (enabled) - the fix for user-control-disabled packages in Settings shipped enabled
• Private profile creation simplified - canAddPrivateProfile() now uses a simpler check, removing multiple legacy flag guards
• Legacy multi-user methods removed - canAddMoreUsersLegacy() deleted from UserManager; the consistentMaxUsers flag is now assumed true
• Policy handler framework - a new PolicyHandler/PolicyHandlerFactory/PolicyValidator framework landed in the device policy service. This is the typed handler lifecycle that replaces inline DPMS logic and will scale as more policies migrate
• ManagedProvisioning onboarding unconditional - the onboarding task service's feature flag gate was removed; it now exports unconditionally
• App streaming role expanded - companion device app streaming gained storage permissions, sensitive notifications access, and restricted RCS message reading (all gated by expandAppStreamingRolePermissions)
• Home role gains app lock - the home (launcher) role gained LOCK_APPS permission, gated by appLockApis, enabling launcher-level app locking
• Supervision permissions broadened - both supervision roles gained MANAGE_SUPERVISION (gated by enableSupervisionManagerPolicyApis)
• RCS restrictions feature-flagged - restricted RCS message access across companion and system roles moved from SDK version gating to a runtime feature flag

Track: QPR1 Beta | Predecessor: QPR1 Beta 3 | Milestone: September 2026 stable

Introduces the device controller concept, content safety apps rename, and WPA enforcement constant.

DPC capabilities

• Device controller package - a new concept of a "device controller" separate from the traditional device owner or profile owner. The controller package is set during multi-user provisioning, persisted in the device's ownership data, and cleared when management is torn down. This is a lighter-weight management entity designed for shared and multi-user devices
• Content safety apps - the content restriction apps policy was renamed to content safety apps, settling on its final name after several iterations. The associated permission was also renamed
• Parent-profile-aware streaming policy (provisional) - the nearby app streaming policy gained parent-profile awareness, allowing it to be set and queried with profile context
• WPA Wi-Fi security constant (provisional) - a new constant value allows enforcing WPA as the minimum Wi-Fi security level

Other enterprise changes

• Sideloading control permission - a new permission for controlling unknown sources installation, distinct from the existing sideloading restriction
• Display management permission - a new role-gated permission for managing displays appeared, relevant for devices connected to external screens
• Three flags graduated in this build: addUserInfoInProfileOffDeadlineAlarm, checkPersonalSuspensionForAllProfiles, and wipeDeviceWhenUserCannotBeRemoved
• Two flags removed (graduated out): associateDisallowGrantAdminWithPermission and unsuspendNotSuspended
• Device state cache replaced - the abstract device state cache was replaced by a concrete implementation with methods moved to internal interfaces
• Provisioning pre-condition fix - a fix ensured provisioning pre-conditions pass the correct user ID

Track: Canary | Predecessor: Canary 3 | Note: canary builds are forward-looking and may not ship in the next stable release

Significant build that introduces scaffolding for device admin deprecation and expands the policy metadata system.

DPC capabilities

• Device admin deprecation scaffolding - over 30 methods gained an isDeviceAdminFeatureDisabled() check, all returning false for now. This is preparation for eventually disabling the legacy device admin API
• Role-based device ownership - the device ownership system now accepts a RoleManager reference, adding role-based management alongside traditional owner-based management

Other enterprise changes

• Several flags graduated (enabled) in this build: addUserInfoInProfileOffDeadlineAlarm, checkPersonalSuspensionForAllProfiles, crossUserSuspensionEnabledRo, and others moved to enabled in the canary track
• Full enum policy metadata - 13 policies gained complete metadata registration including eSIM transfer, universal clipboard, screen capture, Bluetooth sharing, and lockscreen message
• Personal apps suspension fix (enabled) - the multi-profile fix for personal apps suspension is now the default behaviour
• Device state methods moved - hasAffiliationWithDevice and isDeviceProvisioned moved to an internal interface, cleaning up the public API surface
• Test flag removed - the policyStreamliningTests flag used for internal validation was removed

Track: A17 Beta | Predecessor: A17 Beta 4 | Milestone: June 2026 stable

A patch release that rolled back several flags to their safer defaults on the stable track.

What changed

• Three flags rolled back - increaseWatchStrongAuthTimeout, introduceGenericProvisioningError, and useHardenedFrpActiveCheck were all set back to disabled on the stable track. These remained enabled in the canary and QPR1 tracks, meaning the stable Android 17 release shipped without them while they continue development in quarterly releases
• eSIM carrier privileges restored - the enterpriseEsimUsingCarrierPrivileges flag was re-added as enabled after being removed in earlier builds
• User wipe scope narrowed - the broader "user that cannot be removed" wipe behaviour was narrowed back to "last admin user" on the stable track, keeping the more conservative behaviour for the June release

This build illustrates how the stable, QPR, and canary tracks can diverge: features that are enabled in QPR and canary builds get rolled back on the stable track when they need more baking time.

Track: QPR1 Beta | Predecessor: QPR1 Beta 2 | Milestone: September 2026 stable

Adds typed policy engine flags for several common restrictions and restores features that had been removed in the canary track.

DPC capabilities

• VPN configuration policy (provisional) - a new flag for migrating the VPN configuration restriction to the typed policy engine
• Safe boot restriction (provisional) - a new flag for migrating the safe boot restriction to the typed policy engine
• Cellular data usage policy (provisional) - a new flag for migrating cellular data usage control to the typed policy engine
• Wi-Fi network selection policy (provisional) - a new flag for migrating Wi-Fi network selection restrictions to the typed policy engine

Other enterprise changes

• Visible background users - a new system API method lets apps check whether the device supports visible background users (multiple users active on screen simultaneously), relevant for shared device deployments
• Kiosk user type restored - the dedicated kiosk user type that was removed in the canary track was restored in the QPR1 beta track
• Admin status broadcast restored - the broadcast notifying apps of admin status changes was also restored after being removed in canary
• Private DNS flag restored (provisional) - the profile-owner-aware private DNS flag was restored (as disabled) after being removed in the canary track. This back-and-forth reflects an ongoing design discussion about whether profile owners should be able to set device-wide DNS
• Time coexistence (provisional) - a new flag for migrating manual time-setting policies to the typed coexistence model

Track: Canary | Predecessor: Canary 2 | Note: canary builds are forward-looking and may not ship in the next stable release

A lighter build focused on private DNS refactoring and overlay resource improvements.

DPC capabilities

• Private DNS restricted to device owners - the private DNS policy was tightened so that only device owners can set it, with proper input validation that throws on invalid values. The profile owner path was collapsed (the backing flag removed), confirming private DNS remains a device-wide-only setting

Other enterprise changes

• Recursive resource resolution - overlay package lists now support #import: directives, allowing one list to reference another. This enables cleaner configuration management for OEMs and enterprise deployments with complex overlay hierarchies
• Generic provisioning error (enabled) - graduated in the canary track
• Assistant settings removed - the assistant settings activity was removed in this canary build (later restored in QPR1 Beta 6), reflecting ongoing iteration on the app interaction framework

Track: QPR1 Beta | Predecessor: QPR1 Beta 1 | Milestone: September 2026 stable

Introduces the kiosk user type, device controller role permissions, and assist content policy.

DPC capabilities

• Device controller role expanded - the device controller role gained permissions for device locking and runtime permission management, giving the controller more capability on shared devices
• Assist content policy (provisional) - a new flag for migrating the assist content restriction (controlling what data is shared with assistant apps) to the typed policy engine

Other enterprise changes

• Kiosk user type - a dedicated USER_TYPE_FULL_KIOSK user type appeared, designed specifically for kiosk device management. This mirrors the kiosk app mode available on ChromeOS
• Backup service security log - a new security log tag records when the backup service is toggled on or off, improving audit trails
• Private DNS for profile owners (provisional) - a new flag for allowing profile owners to set global private DNS, though this feature has had a volatile lifecycle across tracks
• Retail demo force-remove (provisional) - a new flag for allowing admin force-removal to skip feature checks in retail demo mode
• Admin-aware permission summaries - the permission controller gained strings for showing when a permission is enforced by an admin, improving transparency in the Settings UI
• Package policy handler refactored - the per-package policy serialisation was replaced by a more robust typed handler, settling the implementation after changes in Beta 1
• Watch strong auth timeout graduated to enabled in this build
• Legacy provisioning params removed - the older multi-user provisioning parameter classes and wrapper methods were cleaned up

Track: QPR1 Beta | Predecessor: Android 17 stable | Milestone: September 2026 stable

The first QPR1 build, laying groundwork for clipboard policy, factory reset protection improvements, and the policy serialisation framework.

DPC capabilities

• Universal clipboard policy (provisional) - new constants and a permission for controlling clipboard sharing across devices. The policy defines allowed and disallowed states, though no DPM API or enforcement path is wired up yet - this is scaffolding
• Key generation failure constant - a new constant for key generation failures provides clearer error reporting when certificate key pair generation fails

Other enterprise changes

• Factory reset protection hardening (provisional) - a new flag for hardening the active FRP check, aiming to strengthen post-wipe management continuity on managed devices
• User wipe broadened (provisional) - the flag controlling device wipes when a user cannot be removed was renamed from a narrow "last admin" scope to a broader "user that cannot be removed" scope, covering more edge cases on shared devices
• Policy serialisation framework - initial serialisers for package-level policies landed, establishing the plumbing for typed policy persistence. These were later replaced by a more robust handler in Beta 2
• DPM role qualification tightened - the device policy management role holder qualification bypass was tightened to only apply during multi-user management, rather than a generic "device managed" check
• Watch strong auth timeout (provisional) - a new flag for increasing the strong authentication timeout on watches, relevant for wearable enterprise deployments

Track: Canary | Predecessor: A16 QPR3 Canary 1 | Note: canary builds are forward-looking and may not ship in the next stable release

Establishes the multi-user provisioning state machine and moves supervision APIs to a dedicated manager.

DPC capabilities

• Multi-user device provisioning - a complete provisioning flow for shared and multi-user devices: start provisioning, provision a managed user, and query the provisioning state (unmanaged, provisioning, or provisioned). This is the foundation for shared device management
• DPM role qualification - a new method lets DPC apps check whether a package is qualified for the device policy management role, enabling self-checks during setup

Other enterprise changes

• Provisioning state machine - provisioning state is now persisted as an XML element, surviving reboots. Three defined states: unmanaged, provisioning in progress, and provisioned
• Supervision moved - supervision-related methods moved from DevicePolicyManager to a dedicated SupervisionManager, with feature flags controlling the migration. This cleans up the DPM API surface
• Permission controller extracted - the Google permission controller was extracted from its APEX module, enabling more frequent enterprise-related updates
• Policy metadata framework - PolicyDefinitionFactory.buildAll() landed for metadata-driven policy registration, alongside EnumStoredAsBooleanPolicyHandler for handling enum policies backed by boolean storage. These are foundational policy engine components
• Least recent resolution - a new policy resolution mechanism picks the least recently set value, adding to the existing most-restrictive and union-based approaches
• Several policy streamlining flags (provisional) - flags appeared for app install/uninstall, auto-timezone, keyguard status, lockscreen message, Easter eggs, and screen capture - all still gated

Track: A17 Beta | Milestone: June 2026 stable

The near-final Android 17 beta, carrying the typed policy engine (present since earlier betas) and cleaning up legacy APIs.

DPC capabilities

• Typed policy interface - setPolicy, getPolicy, getResolvedDeviceWidePolicy, and getResolvedPerUserPolicy are present with typed PolicyIdentifier parameters and built-in multi-admin resolution. These carry @FlaggedApi at API 10000 (provisional) and will ship when the backing flags graduate
• DPM role bypass check - a new method lets apps check whether a package is allowed to bypass device policy management role qualification requirements
• Async provisioning callback - multi-user device provisioning gained an async callback interface for reporting provisioning results without blocking

Other enterprise changes

• Typed package policy framework - PackageIdentifier and PackagePolicyValue landed, providing strongly typed infrastructure for policies that operate on specific packages
• Policy streamlining flags (provisional) - flags appeared for auto-time, Bluetooth sharing, factory reset, lockscreen message, maximum time to lock, screen capture, app install, and app uninstall - all still gated
• Several legacy flags removed (graduated out): deviceOwnerForAll, fixDisabledByAdminShortMessageNotShown, fixUsbDataSignalingRestrictionAfterReboot
• Common criteria coexistence (provisional) - a new flag for migrating Common Criteria mode to the policy coexistence model
• Lockscreen info coexistence (provisional) - a new flag for migrating lockscreen information display to the policy engine
• Managed device definition (provisional) - a flag for broadening what qualifies as a "managed device" beyond strict device owner or profile owner

Track: Android 16 stable | Note: this is the baseline build used for comparison when tracking Android 17 changes

The Android 16 April stable release serves as the comparison baseline for this tracker. Enterprise-relevant items here represent the stable production state against which Android 17 beta changes are measured.

Key enterprise state at this baseline

• 42 flags graduated - a large batch of feature flags moved from runtime delegation to hardcoded enabled, including app restriction coexistence, password reset with token coexistence, onboarding bug report storage fixes, and managed profile removal
• Dedicated device control API shipped enabled
• Policy size tracking shipped enabled, letting administrators monitor policy quota usage
• Device admin feature checks removed - the flag for removing legacy device admin feature checks shipped enabled, simplifying the admin API surface
• String-keyed policy API - an A16-only generic policy API using string keys (clearPolicy, getIntegerPolicy) was present. This approach was superseded by the typed PolicyIdentifier approach in Android 17
• Handoff restriction - the DISALLOW_HANDOFF user restriction (A16 naming) was present, later renamed to DISALLOW_TASK_CONTINUITY_HANDOFF in Android 17
• Policy transparency v2 (provisional) - a flag for the next generation of the policy transparency engine
• Package as admin ID (provisional) - a flag for using package names as admin identifiers
• Multi-user provisioning (provisional) - a flag for user-level multi-user provisioning

Track: A16 QPR3 Canary | Note: canary builds are forward-looking and may not ship in the next stable release

The earliest build tracked, running on the Pixel 7 before the tracker switched to the Pixel 10. This canary sits on the Android 16 QPR3 branch and contains forward-looking enterprise plumbing.

What appeared

• Cross-user suspension (provisional) - a new flag for suspending apps across user profiles, relevant for shared device scenarios where an admin needs to disable an app for all users simultaneously
• Managed device definition extended (provisional) - a flag for broadening what counts as a "managed device" beyond traditional device owner or profile owner
• Enforcing admin extras (provisional) - two flags for exposing additional information about which admin is enforcing a policy, later graduated in QPR2 Beta 1
• Several flags removed from the canary track that had previously been present in the Beta 3 baseline