Install and launch an app on Android secondary users with ADB

by

Summary

When developing on Android devices that support multiple user profiles, you may encounter a situation where ADB cannot launch or install an app for a secondary user. The error 

Activity class {com.opappdevs.getexternaldirs/com.opappdevs.getexternaldirs.MainActivity} does not exist

is typically caused by a mismatch between the target user ID and the package’s installed location. The app is either not installed for that user or the launch intent is being sent to the wrong user context.

Root Cause

  • Package installed only for the primary user – Android keeps a per‑user package list; a secondary user sees an empty slot unless the app is explicitly installed for that user.
  • ADB default target is user 0 (owner) – When you run adb install without --user, the package goes to the owner profile.
  • adb shell am start without --user tries to start the activity in the current (owner) context, but you are connected to the secondary user’s shell, leading to “activity does not exist”.

Why This Happens in Real Systems

  • Multi‑user support isolates apps and their private/external storage per user for privacy and security.
  • ADB historically defaulted to the owner profile; newer Android releases enforce stricter user scoping, causing older workflows to break.
  • Some OEM skins expose a “secondary user” UI but do not expose the same developer options, so the device appears to accept USB debugging but refuses cross‑user launches.

Real-World Impact

  • Lost debugging time – Engineers waste hours trying to run the same APK on a secondary profile.
  • False negative storage bugs – An app that appears to fail accessing external storage on a secondary user may be misdiagnosed as a storage‑permission issue rather than an installation‑scope problem.
  • CI pipelines that spin up multi‑user test devices can fail silently if the install step does not specify the correct user.

Example or Code (if necessary and relevant)

# Install the APK for user 10 (replace with the actual secondary user ID)
adb install --user 10 path/to/app-debug.apk

# Verify installation for that user
adb shell pm list packages --user 10 | grep com.opappdevs.getexternaldirs

# Launch the main activity for user 10
adb shell am start --user 10 -n com.opappdevs.getexternaldirs/.MainActivity

Tip: Find the secondary user ID with adb shell pm list users.

How Senior Engineers Fix It

  • Query the user list before any install: adb shell pm list users.
  • Explicitly target the user in every ADB command (--user <id>).
  • Automate the workflow in Gradle/fastlane scripts to detect the current device’s secondary user ID and inject it.
  • Validate installation with pm list packages --user <id> before attempting to start an activity.
  • If the secondary user cannot install the app (policy restriction), use adb shell pm install-create with the -r flag to create a per‑user install session.

Why Juniors Miss It

  • They assume ADB operates globally and forget that Android’s multi‑user model isolates app installations.
  • They often rely on the IDE’s “Run” button, which defaults to user 0 and does not surface the underlying --user flag.
  • Lack of familiarity with pm list users and the need to explicitly specify the user leads to the “activity does not exist” error being misinterpreted as a code‑level bug.

Leave a Comment