How to Inspect Cross-Profile Apps and Enterprise Interaction Grants on Android Using ADB dumpsys cross_profile_apps

Modern Android enterprise deployments use Work Profiles to isolate corporate data, email, and proprietary enterprise applications from a user’s personal apps. Under standard security models, data and communication cannot cross this profile boundary. However, specific enterprise workflows—such as unified calendars, contact syncing, integrated document scanners, and corporate single sign-on (SSO) authenticators—require controlled cross-profile interoperability.

Android manages these interactions through the CrossProfileApps service framework. To maintain compliance and security, both device policy controllers (DPCs) and end users must grant explicit consent before an application can bind services or launch activities across profile boundaries. Using the Android Debug Bridge (ADB), system administrators and security researchers can inspect active cross-profile grants, whitelisted packages, and consent status using dumpsys cross_profile_apps.

Understanding Android Cross-Profile Architecture

When an Android device enrols in an enterprise management platform (such as Microsoft Intune, VMware Workspace ONE, or Google Workspace), Android establishes two distinct Linux user spaces: User 0 (Personal) and User 10 (or higher, representing the Work Profile). The cross_profile_apps system service regulates cross-boundary interactions:

• Manifest Declarations: Applications must declare the INTERACT_ACROSS_PROFILES permission in their AndroidManifest.xml.
• Enterprise Whitelisting: The Device Policy Controller must add the application package to the allowed cross-profile interaction whitelist.
• User Consent: The end user must manually consent in device settings or accept a system prompt allowing data access between work and personal spaces.
• App-Op Enforcements: Android enforces the android:interact_across_profiles App-Op rule at the kernel and framework level.

Connecting to ADB and Inspecting Profile Users

Connect your Android device or test emulator with USB debugging enabled. Confirm device responsiveness:

adb devices

Inspect the existing user accounts on the device to confirm the User IDs corresponding to the Personal and Work profiles:

adb shell pm list users

A typical enterprise enrollment output appears as follows:

Users:
  UserInfo{0:Owner:13} running
  UserInfo{10:Work profile:30} running

Here, User 0 is the primary personal profile, and User 10 is the managed work profile.

Inspecting Cross-Profile Status with dumpsys cross_profile_apps

To inspect the global cross-profile configuration, whitelists, and installed application states across all profiles, run:

adb shell dumpsys cross_profile_apps

The diagnostic dump outputs the complete system service state:

CrossProfileApps:
  Enabled packages:
    Package: com.google.android.calendar
      Configured for users: 0, 10
      User 0 consent: GRANTED
      User 10 consent: GRANTED
      Admin whitelist status: ALLOWED
    Package: com.microsoft.office.outlook
      Configured for users: 0, 10
      User 0 consent: GRANTED
      User 10 consent: DENIED
      Admin whitelist status: ALLOWED

Interpreting Critical Diagnostic Fields

When auditing the output of dumpsys cross_profile_apps, evaluate the following parameters:

Field	Reported Value	Security and Operational Meaning
Admin whitelist status	ALLOWED or BLOCKED	Indicates whether the enterprise MDM policy allows the package to request cross-profile access
User consent	GRANTED or DENIED	Reflects whether the user approved the interactive permission prompt for that specific profile ID
Configured for users	List of User IDs (e.g. 0, 10)	Confirms that identical package binaries and signing keys exist on both sides of the profile barrier
InteractAcrossProfilesAppOp	MODE_ALLOWED or MODE_IGNORED	Underlying Android App-Op flag enforcing programmatic API call permissions

Verifying and Overriding App-Op Grants via ADB

If an enterprise application fails to communicate across profiles during staging, check whether the underlying App-Op is blocked for that specific user context:

adb shell cmd appops get --user 10 com.google.android.calendar INTERACT_ACROSS_PROFILES

If testing in an enterprise development lab where manual MDM policy enrollment is bypassed, administrators can manually grant the App-Op for debugging:

adb shell cmd appops set --user 10 com.google.android.calendar INTERACT_ACROSS_PROFILES allow
adb shell cmd appops set --user 0 com.google.android.calendar INTERACT_ACROSS_PROFILES allow

After granting the permission, rerun dumpsys cross_profile_apps to verify that both user profiles show active permissions:

adb shell dumpsys cross_profile_apps | grep -A 6 "com.google.android.calendar"

Revoking Cross-Profile Access and Auditing Logs

To revoke permissions and test how an application handles unexpected cross-profile boundary errors:

adb shell cmd appops set --user 10 com.google.android.calendar INTERACT_ACROSS_PROFILES ignore

Monitor system logcat streams to inspect security exceptions or cross-profile Intent handling:

adb logcat -s CrossProfileAppsService:* DevicePolicyManager:*

Using dumpsys cross_profile_apps gives systems administrators and security teams absolute visibility into enterprise data flow boundaries, preventing unintended corporate data leakage while ensuring necessary cross-profile workflows remain functional.