Android Private Space: what it hides and what IT should control

Android Private Space gives users a locked, hideable second profile for sensitive apps, and the same features that protect a user's privacy can hide apps, data and network traffic from the people responsible for the device. Private Space arrived in Android 15 as a separate user profile with its own optional lock, its own accounts and its own app copies. This guide explains how it works at the platform level, what it does and does not protect, how it interacts with work profiles and the Android Management API, and what security teams should decide for company-owned, BYOD and kiosk fleets. It is written for mobile and endpoint engineers, MDM administrators and app developers whose apps handle work data or detect profiles.

Key takeaways

• It is a real profile, not an app vault. Private Space uses a separate user profile of type android.os.usertype.profile.PRIVATE; when locked, the profile is stopped and its apps cannot run, notify or sync.
• Admins control it only on company-owned work profile devices. Android 15 lets administrators block and remove Private Space on the personal side of a corporate-owned device (DISALLOW_ADD_PRIVATE_PROFILE, or privateSpacePolicy in the Android Management API); it is not available at all on fully managed devices.
• Private Space apps bypass the device VPN. Google's help centre says so plainly, which matters wherever a VPN or secure web gateway is part of the control set for the personal side of a device.
• Hidden does not mean undetectable. Google lists app installers, ADB or computer access, apps that detect Private Space and device logs as ways the space can still be found, so treat it as a privacy feature, not an anti-forensics or isolation boundary.
• Work-profile logic in apps can break. Google warns that apps must not assume that a copy of the app outside the main profile is the work profile, a mistake that can mislabel personal data as managed or the reverse.

How Private Space works

Android's developer documentation describes Private Space as a way for users to "keep sensitive apps away from prying eyes, under an additional layer of authentication". The Android Open Source Project (AOSP) documentation describes the mechanics: it is a profile built on the multi-user model, there can be only one per device, and it can exist only for the main user. It can coexist with a work profile and a clone profile.

• Lock state: "When the space is locked, the private profile user is stopped, and when the space is unlocked, the user is started." A stopped profile runs no foreground or background work and shows no notifications.
• Authentication: the user chooses the device screen lock or a separate PIN, pattern or password. Auto-lock options include every time the device locks, five minutes after screen timeout, or only after restart.
• Separate copies: apps are installed fresh into the space through whichever store the user prefers, and existing apps and their data cannot be moved in. Accounts are separate: the space does not read accounts from the main space.
• Visibility: while locked, the space's apps are hidden from the launcher, recents, notifications, Settings, sharing and search. With "Hide private space when it's locked", even the launcher entry point disappears.
• Crossing the boundary: the system sharesheet and photo picker can pass content between spaces only while the space is unlocked. Android 16 QPR2 adds an "Add files" shortcut that copies or moves files into the space's Downloads folder.
• Intents: telephony intents go to the main user; other intents stay inside the private profile.

What it protects and what it does not

For most users the honest description is a strong privacy screen with real process isolation when locked. It is not a security container in the sense of a managed work profile: the organisation has no policy channel into it, and it is not designed to resist someone with physical or debugging access.

Private Space in each Android Enterprise mode

Android's "What's new in enterprise" page for Android 15 sets out the management rules. The table maps them to the management modes covered in the Android Enterprise Security Guide.

• Custom DPCs: the Android 15 enterprise page says personal app allowlists inside the space were available for the Android Management API, with custom DPC support "in the future". Check your EMM before relying on blocklists.
• Removal is destructive: applying the restriction to a device that already has a space removes it. Because Private Space data is not included in device backup, warn users before enforcement or they may lose personal data the organisation has no right to delete without notice.
• Work profile cannot live inside it: Google's help centre states that a work profile cannot be set up from Private Space, so the space cannot be used to run a second, shadow work profile.

The enterprise risks worth acting on

• VPN and gateway bypass: Private Space apps bypass the device VPN. If your COPE design relies on an always-on VPN or a personal-side web filter for acceptable use, data loss prevention or threat protection, that control does not cover the space.
• Shadow app stores and sideloaded apps: the space's "Install apps" entry launches any app store that declares CATEGORY_APP_MARKET, and the user picks the store. A user who wants an unvetted store or sideloaded APK has a convenient hiding place. See the Mobile Malware Guide.
• Hidden copies of work-capable apps: a user can install a second copy of a collaboration or file-sharing app in the space and sign in with a personal account. Work data that reaches the personal side through copy and paste or sharing can then be moved somewhere invisible to casual review.
• Mobile threat defence blind spot: an MTD agent in the work profile or main space sees only its own profile. Confirm with your vendor what, if anything, it can observe about a private profile; do not assume coverage.
• Insider and investigation implications: on corporate devices, a hidden space may hold evidence relevant to an investigation, yet it can be deleted with one authentication. See the Mobile Forensics Guide.
• Critical apps going silent: Google warns that the space is unsuitable for apps that must notify, such as medical apps. The same applies to authenticator or on-call alerting apps: an MFA push app installed in a locked space will not receive prompts.

Where identity fits

Private Space is an identity boundary as much as an app boundary. It has its own Google account (or none), its own sign-ins and its own authenticator state. Three identity issues follow. First, tokens and sessions for corporate SaaS created inside the space are invisible to device management even though they authenticate as the user; conditional access that requires a compliant managed device is what prevents work sign-ins from an unmanaged profile. Second, an authenticator or passkey provider installed only inside a locked space is unavailable when the space is locked, which produces help desk MFA resets, a known social engineering path. Third, any app that stores API keys or OAuth refresh tokens on the device stores a separate set in each copy, so revocation after a device loss must cover both. See the OAuth for Native and Mobile Apps Guide and the Okta Security Hardening Guide for help desk reset controls.

Guidance for app developers

• Do not infer the work profile: Android 15 behaviour changes warn that apps "shouldn't assume that any installed copies of their app that aren't in the main profile are in the work profile". Identify a managed profile through the device policy and managed configuration APIs, not by counting profiles.
• Do not try to detect and refuse: Google notes apps "can't determine whether or not they're being used in the private space". Medical and safety apps should tell users not to install them there.
• Launchers: must hold ROLE_HOME and declare ACCESS_HIDDEN_PROFILES, keep a separate container, support lock and unlock through requestQuietModeEnabled(), hide the space from search while locked, and react to ACTION_PROFILE_AVAILABLE and ACTION_PROFILE_UNAVAILABLE.
• App stores: declare CATEGORY_APP_MARKET to receive the space's install intent.
• Background work: scheduled jobs, alarms and push handling stop when the space locks. Design server-side retries and do not treat missed heartbeats from a private copy as device loss.

The Android App Security Guide and Kotlin and Android Secure Coding Guide cover the wider app-side controls.

Deciding and rolling out a Private Space policy

Decision guidance

Rollout steps

1. Inventory: list devices by management mode and Android version. Only Android 15 and later devices are affected.
2. Decide per device group: agree allow or disallow with HR, legal and the data protection officer, and update the acceptable use and BYOD Policy Template wording.
3. Notify users first: where you will disallow, give users time to move data out, because enforcement removes an existing space and its data is not backed up.
4. Pilot: apply the policy to an IT ring of COPE devices, confirm creation is blocked and an existing test space is removed, and check the EMM reports the policy as compliant.
5. Test the VPN gap: on an allowed device, create a space, install a browser, and confirm what your network controls see. Record the result in the risk register.
6. Roll out by ring: widen in stages, watching help desk tickets for lost authenticator apps and data.
7. Roll back: setting the policy back to allowed lets users create a space again; removed spaces and their data cannot be restored, which is why notice comes first.

Detection and measurement

Organisations cannot and should not inspect the contents of a user's Private Space. Measurement is about policy state and outcomes.

• Policy coverage: share of Android 15+ COPE devices with the intended privateSpacePolicy applied and reported compliant.
• Mode correctness: share of kiosk and high-risk devices actually enrolled as fully managed.
• Conditional access enforcement: share of work sign-ins from Android that come from a compliant managed profile; unmanaged sign-ins trend down.
• MFA reset tickets citing a "hidden" or locked authenticator: should stay near zero after user guidance.
• App test coverage: for in-house apps with work profile logic, share tested on Android 15 with a private profile present.

Common failure patterns

• Assuming the VPN covers the personal side: traffic from Private Space apps does not use the device VPN, so a personal-side filtering control has a silent gap.
• Enforcing removal without warning: applying the restriction deletes users' spaces and data that cannot be recovered, creating complaints and possible employment disputes.
• Counting profiles to find the work profile: in-house apps that treat "the other copy" as managed may apply work policies to personal data or leave work data unprotected.
• Authenticator in the space: MFA prompts never arrive while the space is locked, users call the help desk, and a weak reset process becomes the attack path.
• Treating hidden as secure: sensitive users told that Private Space protects them against a forensic examiner or spyware are given false assurance.

Framework mapping

Practitioner checklist

• Record the management mode and Android version of every device; Private Space applies to Android 15 and later.
• Confirm kiosk and high-risk devices are fully managed, where Private Space is unavailable.
• Make an explicit allow or disallow decision for company-owned work profile devices and set privateSpacePolicy or DISALLOW_ADD_PRIVATE_PROFILE accordingly.
• Notify users before disallowing, since removal deletes the space and its data cannot be restored.
• Document that Private Space apps bypass the device VPN and adjust any personal-side network controls in the risk register.
• Require a compliant managed profile for work sign-ins through conditional access.
• Tell users not to install authenticators, alerting or medical apps inside Private Space.
• Test in-house apps with a private profile present and remove any "other profile equals work profile" logic.
• Brief legal, HR and investigators on how the feature affects evidence on corporate devices.

Standards and references

• Android Developers: What's new in Android 15 for enterprise
• Android Open Source Project: Private space
• Android Developers: Android 15 features, private space
• Android Developers: Android 15 behaviour changes, private space
• Google Android Help: Hide sensitive apps with private space
• Google for Developers: Android Management API release notes
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Hide Artifacts (Mobile)

Related NHI Mgmt Group resources: Android Enterprise Security Guide · Mobile Device Management Security Guide · Mobile Device Security Guide · BYOD Policy Template