Employing Work Profiles

A work profile is an Android user with additional special properties around management and visual aesthetic. The primary goal of a work profile is to create a segregated and secure space for managed data (such as corporate data) to reside. The administrator of the profile has full control over the scope, ingress, egress, and lifetime of data. These policies offer great powers and therefore fall upon the work profile instead of the device administrator.

  • Creation. Any app in the primary user can create a work profile. The user is notified of work profile behaviors and policy enforcement before creation.

  • Management. Apps known as profile owners can programmatically invoke APIs in the DevicePolicyManager class to restrict use. Profile owners are defined at initial profile setup. Policies unique to work profiles involve app restrictions, updatability, and intent behaviors.

  • Visual treatment. Apps, notifications, and widgets from the work profile are badged and typically made available inline with user interface (UI) elements from the primary user.

Data segregation

Work profiles use the following data segregation rules.


When the same app exists in the primary user and work profile, apps are scoped with their own segregated data. Generally, apps act independently and can't communicate directly with each another across the profile-user boundary.


Accounts in the work profile are unique from the primary user and credentials can't be accessed across the profile-user boundary. Only apps in their respective context are able to access their respective accounts.


The administrator controls whether intents are resolved in or out of the work profile. By default, apps from the work profile are scoped to stay within the work profile exception of the Device Policy API.

Device identifiers

On personal devices with a work profile, Android 12 or higher removes access to device hardware identifiers (IMEI, MEID, serial number) and provides a unique, enrollment-specific ID that identifies the work profile enrollment for a specific organization. The enrollment ID is guaranteed to remain stable across factory resets, enabling reliable inventory tracking of devices with work profiles.

Personally owned devices with a work profile must use the enrollment-specific ID; company-owned devices, including both work profile and fully managed devices, can opt-in to using the ID as well. To use, EMMs must set the Organization ID for each device they manage, after which they can read the enrollment-specific ID on that device and handle it as a serial number. For more details, refer to Security and privacy enhancements for work profile.


Settings enforcement is scoped to the work profile, with exceptions for lockscreen and encryption settings that are scoped to the device and shared between the primary user and work profile. Other than these exceptions, a profile owner doesn't have device administrator privileges outside the work profile.

Work profiles are implemented as a secondary user, such that uid = 100000 \* userid + appid. These profiles have separate app data (/data/user/userid), similar to regular users. The userid is calculated for all system requests using Binder.getCallingUid(), and all system state and responses are separated by the userid value.

The AccountManagerService maintains a separate list of accounts for each user. Account differences between a work profile user and a regular secondary user include the following:

  • The work profile is associated with its parent user and is started with the primary user at boot time.

  • Notifications for work profiles are enabled by ActivityManagerService, allowing the work profile to share the activity stack with the primary user.

  • Additional shared system services include IME, A11Y services, Wi-Fi, and NFC.

  • Launcher APIs enable launchers to display badged apps and allowlisted widgets from the work profile next to apps in the primary profile without switching users.

Device management

Android enterprise device management includes the following owners:

  • Profile owner. Designed for bring your own device (BYOD) environments.
  • Device Owner. Designed for corp-liable environments.

Some device management APIs are used for consumers (for example, find my device APIs), while other APIs are available only to profile or device owners.

Profile owners

A Device Policy Client (DPC) app functions as the profile owner and is typically provided by an enterprise mobility management (EMM) partner such as Google Apps Device Policy. The profile owner app creates a work profile on the device by sending the ACTION_PROVISION_MANAGED_PROFILE intent. The work profile has badged instances of apps that are visually distinct from personal instances of apps; the badge identifies an app as a work app. The EMM has control only over the work profile and not the personal space (with some exceptions, such as enforcing the lock screen).

Device owners

The device owner can be set only on an unprovisioned device, as the owner must be provisioned during the initial device setup. Quick settings must always display a disclosure. Device owners can perform some tasks that profile owners can't, such as:

  • Wiping device data.
  • Disabling Wi-Fi or Bluetooth.
  • Setting the value of setGlobalSetting.
  • Setting the value of setLockTaskPackages, which is the ability to allowlist packages that can pin themselves to the foreground.
  • Setting the value of DISALLOW_MOUNT_PHYSICAL_MEDIA, which is FALSE by default; when set to TRUE, portable and adoptable physical media can't be mounted).

DevicePolicyManager APIs

Android 5.0 or higher offers an improved DevicePolicyManager with APIs that support corporate-owned and bring your own device (BYOD) management use cases, including restricting apps, silently installating certificates, and controlling cross-profile sharing intent access. To get started, use the sample Device Policy Client (DPC) app BasicManagedProfile.apk. For details, refer to Build a device policy controller.

Work profile user experience

Android 9 or higher creates a tighter integration between work profiles and the Android platform, making it easier for users to keep their work and personal information separate on their devices. Work profile changes appear in the launcher and provide a consistent user experience across managed devices.

Devices with an app tray

In Android 9 or higher, the work profile UX changes for Launcher3 help users maintain separate personal and work profiles. The apps drawer provides a tabbed view to distinguish personal profile apps. When users first view the work profile tab, they are presented with an educational view to help them navigate the work profile. They can also turn the work profile on or off by using a toggle in the launcher's work tab.

Tabbed profile views

In Android 9 or higher, a work profile enables users to switch between personal and managed app lists in the apps drawer. App views are separated into two distinct RecyclerViews, managed by a ViewPager. Users can switch between the different profile views by using profile tabs at the top of the app drawer, as illustrated below:

Figure 1. Personal tab view

Figure 2. Work tab view, work profile toggle

The tabbed view is implemented as part of the AllAppsContainerView Launcher3 class. For a reference implementation of the tabbed profile indicator, refer to the PersonalWorkSlidingTabStrip class.

Educational view

Android 9 or higher supports an educational view that informs users of the purpose of the work tab and how they can make work apps easier to access. Using Launcher3, you can present an educational view at the bottom of the work tab screen when users first open the work tab, as shown below:

Educational view

Figure 3. Educational view

The educational view is defined by the BottomUserEducationView class with the layout controlled by work_tab_tottom_user_education_view.xml. Within BottomUserEducationView, the KEY_SHOWED_BOTTOM_USER_EDUCATION boolean is set to false by default. When the user dismisses the educational view, the boolean is set to true.

Toggle to enable or disable work profiles

In Android 9 or higher, managed device administrators can present a toggle in the work tab footer for users to enable or disable the work profile. Enabling and disabling the work profile is done asynchronously and applied to all valid user profiles; this process is controlled by theWorkModeSwitch class. For toggle source, refer to WorkFooterContainer.

Devices without an app tray

For launchers without an app tray, continue placing shortcuts to the work profile apps in the work folder. If the work folder doesn't populate correctly and newly installed apps aren't added to the folder, apply the following change in the onAllAppsLoaded method in the ManagedProfileHeuristic class:

for (LauncherActivityInfo app : apps) {
        // Queue all items which should go in the work folder.
        if (app.getFirstInstallTime() < Long.MAX\_VALUE) {
                InstallShortcutReceiver.queueActivityInfo(app, context);

Validating UX changes

To test the work profile UX implementation using the TestDPC app:

  1. On the device, install the TestDPC app from the Google Play Store.

  2. Open the launcher or app drawer and select Set up TestDPC.

  3. Follow the onscreen instructions to set up a work profile.

    Figure 4. Set up work profile

    Figure 5. Add accounts

    Figure 6. Setup complete

  4. Open the launcher or app drawer and verify that the work tab is present and contains a work profile footer.

  5. Verify that you can toggle the work profile on and off by confirming that the work profile is enabled and disabled as expected. The following figures show examples of enabled and disabled work profiles:

    Figure 7. Toggle on, work profile enabled

    Figure 8. Toggle off, work profile disabled

Work profile app badge

In Android 9 or higher, for accessibility reasons, the color of the work badge is blue (#1A73E8) instead of orange.