[stable] Fix flutter run failing when the launcher activity is an <activity-alias> (cherry-pick of #187251) - #192726

Cherry-pick of #187251 (commit 05f1a0bdd2b522b3b63442723a06577557e7361f) onto flutter-3.47-candidate.0, requested for the next stable hotfix.

Fixes #38965.

Issue

flutter run and flutter install abort on Android with:

package identifier or launch activity not found.
Please check .../android/app/src/main/AndroidManifest.xml for errors.

whenever the MAIN / LAUNCHER intent-filter is declared on an <activity-alias> instead of directly on an <activity>. The manifest is not actually in error — the same project installs and launches correctly via ./gradlew installDebug. The tool's launch-activity detection only walked <activity> elements, so it found no launcher and reported a misleading manifest failure.

Impacted Users

Android developers whose AndroidManifest.xml uses <activity-alias> as the MAIN/LAUNCHER entry point — a documented Android pattern used to swap launcher icons and labels, to keep a stable launcher component name across activity refactors, and in white-label / flavored builds.

Impact Description

Development on Android is blocked for these projects: flutter run and flutter install cannot start the app, and the error text points at the manifest as though it were malformed, which sends developers looking for a non-existent manifest bug. Artifacts built by Gradle are unaffected — the failure is in the tool's launch path, not in the built app.

Workaround

Partially. The MAIN/LAUNCHER intent-filter can be moved off the alias and onto the target <activity>, but that changes the launcher component name Android exposes, so it is not viable for apps that depend on a stable alias name (for example to preserve homescreen shortcuts), and it has to be reverted before shipping.

Risk

Low. The change is confined to flutter_tools manifest parsing:

• <activity-alias> elements are appended after <activity> elements with followedBy, so plain <activity> matches keep priority and existing manifests resolve to exactly the same launch activity as before.
• Adds a guard so an entry with a missing or empty android:name no longer yields a malformed package/null launch activity.

No framework, engine, or build-output changes.

Test Coverage

Yes — +145 lines of unit tests in packages/flutter_tools/test/general.shard/application_package_test.dart:

• AndroidApk.fromAndroidProject resolves an <activity-alias> launcher from AndroidManifest.xml.
• ApkManifestData.parseFromXmlDump resolves an activity-alias launcher from an aapt dump.
• A launcher entry with no android:name returns null rather than a malformed component.

Existing launcher-detection tests are unchanged.

Validation Steps

1. flutter create activity_alias && cd activity_alias
2. In android/app/src/main/AndroidManifest.xml, remove the <intent-filter> from .MainActivity and add:

<activity-alias android:name=".LauncherAlias" android:targetActivity=".MainActivity">
    <intent-filter>
        <action android:name="android.intent.action.MAIN"/>
        <category android:name="android.intent.category.LAUNCHER"/>
    </intent-filter>
</activity-alias>

3. flutter run on a connected Android device or emulator.
   • Before: fails with package identifier or launch activity not found.
   • After: builds, installs, and launches <package>/.LauncherAlias.
4. Regression check: restore the default <activity>-only manifest and flutter run again — still launches .MainActivity.

Cherry-pick notes

application_package.dart applied cleanly. application_package_test.dart required a three-way merge against unrelated formatting churn on the candidate branch; it resolved without conflicts and the resulting diff is identical in size to the original PR (+13/−3 and +145/−0).

I do not have triage permission on this repository, so I could not apply the cp: review label — could a triager please add it?

cc @mboetger (author of the original PR).

🤖 Generated with Claude Code