open <package> fails to launch app without explicit --activity flag (launcher activity resolution broken for multi-entry apps)

[EarthXP]

Title

open <package> fails to launch app without explicit --activity flag (launcher activity resolution broken for multi-entry apps)

---

Description

Summary

agent-device open "com.microsoft.office.outlook" --platform android fails to launch Outlook, while explicitly specifying the activity works correctly:

# ❌ Fails
agent-device open "com.microsoft.office.outlook" --platform android

# ✅ Works
agent-device open "com.microsoft.office.outlook" --activity "com.microsoft.office.outlook/.ui.miit.MiitLauncherActivity" --platform android

This suggests the internal launcher activity resolution logic is not correctly identifying the launchable activity for apps with non-standard or multiple launcher entries.

Steps to Reproduce

1. Install Microsoft Outlook on an Android device/emulator
2. Open a session with another app (e.g., Contacts)
3. Attempt to switch to Outlook:

agent-device open "com.microsoft.office.outlook" --platform android
# Result: fails to launch

4. Retry with explicit activity:

agent-device open "com.microsoft.office.outlook" --activity "com.microsoft.office.outlook/.ui.miit.MiitLauncherActivity" --platform android
# Result: launches successfully

Expected Behavior

agent-device open "com.microsoft.office.outlook" --platform android should automatically resolve the correct launcher activity and launch the app, without requiring --activity.

Actual Behavior

The command fails. The app does not launch. The explicit --activity flag is required as a workaround.

Root Cause Analysis

Outlook's launcher activity is com.microsoft.office.outlook/.ui.miit.MiitLauncherActivity, which is likely not what agent-device's internal resolver picks up.

Many production apps (especially Microsoft, Google, and apps from Chinese vendors) have complex manifest configurations:

• Multiple launcher activities (A/B testing, regional variants)
• Activity aliases that wrap the real entry point
• Dynamic entry points that change across app versions

The current resolution logic may be selecting the wrong candidate or failing entirely when multiple MAIN/LAUNCHER intent filters are present.

You can verify the correct activity with:

adb shell cmd package resolve-activity --brief -a android.intent.action.MAIN -c android.intent.category.LAUNCHER com.microsoft.office.outlook

Impact

This is a significant usability issue for agent-driven workflows. AI agents cannot be expected to know the internal activity names of every app in advance. Reliable app launching by package name alone is essential for autonomous mobile automation.

Apps confirmed affected:

• com.microsoft.office.outlook (Microsoft Outlook)

Apps likely affected (same multi-entry pattern):

• Other Microsoft apps (Teams, Word, Excel)
• Many banking and enterprise apps
• Apps from Chinese vendors (WeChat, Alipay, etc.)

Suggested Fix

Consider updating the activity resolution logic to:

1. Use adb shell cmd package resolve-activity --brief -a android.intent.action.MAIN -c android.intent.category.LAUNCHER <package> as the primary resolver
2. If that returns an unexpected result, fall back to querying dumpsys package <package> for all MAIN/LAUNCHER entries and try them in order
3. As a last resort, use adb shell am start -a android.intent.action.MAIN -c android.intent.category.LAUNCHER <package> which lets the system resolve the intent

Option 3 is the simplest and most reliable — it delegates resolution to the Android system itself rather than parsing it client-side.

Environment

• agent-device version: (latest npm)
• Platform: Android (emulator / physical device)
• Android version: (your version)
• Device: (your device model)

Workaround

Specify --activity explicitly:

agent-device open "com.microsoft.office.outlook" --activity "com.microsoft.office.outlook/.ui.miit.MiitLauncherActivity" --platform android

If this is reasonable to be fixed I can come up with PR to fix it and for the options above I may need to test them and come up with the last solution.

[thymikee]

Yes, it’s worth fixing.

• src/platforms/android/index.ts already uses cmd package resolve-activity --brief <package>, but it does not pass -a MAIN -c LAUNCHER.
• That can resolve the wrong target on multi-entry apps, exactly the class of issue you described.

Most pragmatic fix:

1. Update resolver command to include -a android.intent.action.MAIN -c android.intent.category.LAUNCHER.
2. Keep system-driven launch as primary path (am start with MAIN/LAUNCHER).
3. Keep component fallback, but based on corrected resolve output.
4. Add unit tests for resolver parsing and command construction in src/platforms/android/__tests__/index.test.ts.

If you can send PR, please do!

[EarthXP]

sure, I have this PR submitted, plesae review and let me know if there is question. #115