Android Enterprise build tracker

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