Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
A java.lang.SecurityException naming android.permission.INTERACT_ACROSS_USERS means Android rejected an operation that crossed a user or profile boundary. Adding the permission to AndroidManifest.xml usually does not fix it: a manifest declaration is only a request, and the framework also checks the caller, target user, API-specific rules, and device policy. For a typical third-party app, the right fix is often to avoid crossing users or use Android’s supported cross-profile flow—not to request this permission at runtime.
What Android means by “across users”
Android can have a primary user, secondary users, and profiles such as a managed work profile. These are operating-system security contexts, not merely multiple accounts inside one app. Android separates app data and processes by user, and checks which user the caller and target belong to.
A profile belongs to a profile group, but an unrelated secondary user does not become part of that group just because it is on the same device. Likewise, an app installed for two users has separate per-user instances and data contexts. The fact that both installations have the same package name does not grant one instance free access to the other.
The denial is raised when a framework service checks the calling identity and rejects an operation aimed across that boundary. The permission name alone does not reveal the right remedy; the API named in the stack trace matters.
#1 Best Overall
Three permissions with different scopes
| Permission | Practical scope |
|---|---|
INTERACT_ACROSS_USERS |
Limited cross-user interaction, subject to API-specific requirements. Those can include profile-group membership or same-package conditions. |
INTERACT_ACROSS_USERS_FULL |
Broader cross-user capability, generally associated with highly privileged platform components and trusted system software. |
INTERACT_ACROSS_PROFILES |
A narrower permission relevant to supported communication between profiles, especially work-profile arrangements. It does not grant general access to unrelated users. |
Android’s permission reference documents permission names, but the exact grant and API rules can depend on Android version and device configuration. Do not assume that declaring one of these permissions makes an app eligible to use every API that mentions it.
Why a manifest declaration or runtime request usually fails
This declaration asks for the permission; it does not prove the app’s UID has been granted it:
<uses-permission android:name="android.permission.INTERACT_ACROSS_USERS" />Whether a privileged capability is granted can depend on the package’s signing identity, installation location, platform configuration, role, or device-management status. The Android permission reference and a device’s actual build determine the applicable rules; avoid assuming one protection-level label describes every release and vendor build.
INTERACT_ACROSS_USERS is not normally a dangerous, user-controlled runtime permission. There is generally no standard permission dialog for it, and calling requestPermissions() is not the repair. The regular app-permission screen is not a way for a user to grant arbitrary cross-user access. checkSelfPermission() can help inspect state, but a granted result does not override restrictions imposed by the target user or API.
Rank #2
For the same reason, this is not a dependable production fix:
adb shell pm grant com.example.app android.permission.INTERACT_ACROSS_USERSThe shell may reject the grant, or a test may work only because the device is rooted, userdebug, specially provisioned, or running a development image. That does not show that an ordinary release APK can obtain the capability. Android’s runtime-permission guidance describes runtime permission state and recommends inspecting packages with dumpsys package; it does not turn that workflow into a mechanism for granting privileged cross-user access.
Start with the API named in the stack trace
Common sources include bindServiceAsUser(), launching an activity for another user, accessing a user-specific service or system state, and enterprise or cross-profile operations. Capture the complete exception and identify the framework call that failed before changing permissions or component settings.
- Record the exact permission string and exception message.
- Identify the caller package and the target package or component.
- Record the target
UserHandleor user ID, Android version, build, and whether the device is managed. - Check whether the app is installed in the caller’s and target’s users or profiles.
Diagnose users, installations, and package state
1. List users and profiles
adb shell cmd user listNote the IDs and flags shown. Do not assume user 0 is the caller or the only relevant user.
2. Check whether the package is installed for each user
adb shell pm list packages --user 0
adb shell pm list packages --user 10Replace 10 with the target user ID on your device. A package may be present for one user but absent, disabled, or stopped for another.
3. Inspect package and UID details
adb shell dumpsys package com.example.appInspect UID assignments, installed users, requested and granted permissions, package flags, and component declarations. The package dump is diagnostic evidence about that device; it does not establish that a release app can obtain a privileged grant elsewhere.
4. Verify the target component independently
For service binding, check the component name and its declaration:
Recommended Free Tools
<service
android:name=".MyService"
android:exported="..."
android:permission="..." />- Use an explicit component where the API requires one.
- Confirm that the service exists and is enabled for the target user.
- Check whether its exported status or its own permission creates a separate denial.
- Verify that the calling package is the identity the API expects.
Choose a fix for the actual user arrangement
The operation belongs to the current user
Keep it in that user’s context and use the current-user API rather than an asUser variant. If the app does not need to cross a user boundary, removing that operation is the simplest and safest fix.
The target is a managed or other supported profile in the same group
For personal/work-profile communication, prefer CrossProfileApps and its consent and policy checks instead of trying to obtain general cross-user access. Its APIs are available from API level 30. A valid target profile must differ from the caller, belong to the same profile group, be enabled and not hidden, and have the app installed. The CrossProfileApps reference also describes OEM and administrator allowlisting conditions.
The target is an unrelated secondary user
Assume an ordinary third-party app cannot arbitrarily reach into that user. Use a user-mediated action, keep the operation within the current user, or—if the product genuinely requires management across users—use a properly provisioned device-management application or system component.
The app is enterprise-managed
Device-owner and profile-owner apps have enterprise APIs and provisioning requirements; becoming a device administrator is not a generic permission workaround. For example, administrators can use DevicePolicyManager.setCrossProfilePackages() to control which packages may request cross-profile communication. Use the API that matches the management role and policy.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteThe app is OEM or platform software
Check the signing certificate, installation partition, privileged allowlisting, declared role, and the precise Android build configuration. AOSP documentation alone may not capture vendor-specific policy. A normal application should not treat system-app privileges as a deployable workaround.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Use CrossProfileApps with consent and state checks
For supported personal/work-profile cases on API 30 and later, first check whether interaction is already allowed. If not, request consent only when the API says that request is available:
val crossProfileApps = getSystemService(CrossProfileApps::class.java)
when {
crossProfileApps.canInteractAcrossProfiles() -> {
// Proceed with an approved cross-profile operation.
}
crossProfileApps.canRequestInteractAcrossProfiles() -> {
startActivity(
crossProfileApps.createRequestInteractAcrossProfilesIntent()
)
}
else -> {
// Explain that the profile, administrator, or OEM state
// does not permit this request.
}
}Returning from Settings is not proof that access was granted. Re-check canInteractAcrossProfiles() before proceeding; the API also exposes ACTION_CAN_INTERACT_ACROSS_PROFILES_CHANGED for state changes. The app must satisfy manifest and profile requirements, be installed in the relevant profile, and be allowlisted where required. If canRequestInteractAcrossProfiles() is false, this consent flow is not available in the current arrangement.
Why bindServiceAsUser has extra conditions
Context.bindServiceAsUser() is documented from API level 30. Its current reference lists multiple qualifying permission and target relationships, including INTERACT_ACROSS_USERS_FULL; INTERACT_ACROSS_USERS when caller and target service are in the same profile group; a same-package INTERACT_ACROSS_USERS condition for Android 13/API 33 and later; and INTERACT_ACROSS_PROFILES for same-package interaction within the same profile group. See the method reference for the API’s exact current conditions.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Meeting a permission condition is not sufficient by itself. The intent must identify the intended component, that service must exist for a valid and running target user, and its exported and component-permission configuration must allow the bind. User-boundary authorization and component access are separate checks.
Quick Recap
Common fixes that do not address the cause
| Attempt | Why it often fails |
|---|---|
Add INTERACT_ACROSS_USERS to the manifest |
A request is not necessarily a grant, and the API may require other caller, package, profile, or user conditions. |
Call requestPermissions() |
This is not normally a user-grantable runtime permission. |
Switch to INTERACT_ACROSS_USERS_FULL |
The broader capability is generally more restricted, not an easy replacement for an ordinary app. |
| Grant it with ADB | A shell or development-device result may not be available to the production package or device. |
Hard-code user ID 0 |
The caller may be in another user or profile; a hard-coded ID can target the wrong context. |
Use INTERACT_ACROSS_PROFILES everywhere |
It is scoped to supported profile-group cases and still depends on installation, policy, consent, and API rules. |
| Mark the service exported | Export status does not override user-boundary authorization or other permission checks. |
Alternatives when direct cross-user access is not allowed
- Current-user-only design: run the operation and store the data within the active user wherever possible.
- Narrow provider boundary: expose only the required records or actions through a carefully permissioned
ContentProvider, with caller validation and narrowly scoped URI grants. This does not bypass Android user policy. - User-mediated intent: let Android or the user switch profiles or launch an action rather than reaching directly into another user’s process.
- CrossProfileApps: use for supported profile-group communication when the app and device policy permit it.
- Device-policy APIs: use for genuine device-owner or profile-owner management, with the required provisioning and administrator authority.
- Authenticated backend: if the need is shared app state rather than local process access, synchronize through a backend rather than crossing Android’s local user boundary.
Production-readiness checklist
- Can the operation be performed entirely as the current user?
- Have you identified the caller and target user IDs and whether they share a profile group?
- Is the package installed and enabled for the target profile?
- Does the exact API support the permission and caller/target relationship you have?
- For profile interaction, did you check consent, allowlisting, and profile state rather than assuming access?
- Was the reproduction performed on a device image and signing configuration representative of deployment?
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
