Don't add the LAUNCHER intent; Godot already has an export option for it

[dsnopek]

Presently, we are forcibly adding this Android intent for when using any OpenXR loader:

<category android:name="android.intent.category.LAUNCHER" />

... however:

• Godot already has an export option ("Show In App Library") to add this intent, and it's already enabled by default. So, we don't really even need to add this
• Always adding it makes it impossible for an Android plugin to add a second Activity which will launch by default, which is necessary for making a hybrid app on Meta's platform, that starts as a panel app (and later switches to immersive)

[m4gr3d]

Godot already has an export option ("Show In App Library") to add this intent, and it's already enabled by default. So, we don't really even need to add this

Godot defines an intent-filter for regular app launch, the logic in this plugin adds another intent-filter for XR launches. The intent-filter do not merge, and so don't share their categories, so it's necessary to add the LAUNCHER category to this intent-filter as well.

Can you elaborate further on the issue you're seeing configuring the manifest for hybrid apps.

[dsnopek]

Godot defines an intent-filter for regular app launch, the logic in this plugin adds another intent-filter for XR launches. The intent-filter do not merge, and so don't share their categories, so it's necessary to add the LAUNCHER category to this intent-filter as well.

Hm, I don't think that's exactly right.

When doing a gradle-based export without this PR, we end with the following in the android/build/build/intermediates/merged_manifest/debug/AndroidManifest.xml:

        <activity
            android:name="com.godot.game.GodotApp"
            android:configChanges="orientation|keyboardHidden|screenSize|smallestScreenSize|density|keyboard|navigation|screenLayout|uiMode"
            android:excludeFromRecents="false"
            android:exported="true"
            android:label="@string/godot_project_name_string"
            android:launchMode="singleInstancePerTask"
            android:resizeableActivity="true"
            android:screenOrientation="landscape"
            android:theme="@style/GodotAppSplashTheme" >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />

                <category android:name="android.intent.category.DEFAULT" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />

                <category android:name="android.intent.category.LAUNCHER" />

                <!--
                    Enable access to OpenXR on Oculus mobile devices, no-op on other Android
					platforms.
                -->
                <category android:name="com.oculus.intent.category.VR" />

                <!--
                    OpenXR category tag to indicate the activity starts in an immersive OpenXR mode.
					See https://registry.khronos.org/OpenXR/specs/1.0/html/xrspec.html#android-runtime-category.
                -->
                <category android:name="org.khronos.openxr.intent.category.IMMERSIVE_HMD" />
            </intent-filter>

The first <intent-filter> section is added by Godot, and the 2nd is added by this extension.

For hybrid apps (in my current implementation), we are adding a new activity, and depending on the settings, we may want that activity to have LAUNCHER (so it starts by default), but for this activity to not have it. We already have a way to remove the LAUNCHER added by Godot (there's an export setting), but we don't have a way to remove the one added by this extension (because it's hard-coded to always add it).

Unfortunately, due to the way Android manifest merging works, we can't add do tools:node="remove" to get rid of it, because merging isn't cumulative: we can only remove things in the original AndroidManifest.xml, we can't remove things that were added by earlier mergings.

I hope that makes sense? If not, maybe we can do a call and I can show you :-)

[dsnopek]

Or, actually, I think I understand what you're saying now. So, maybe what we need is an export option to enable/disable the LAUNCHER added by this extension as well? Because the problem is if we don't completely remove LAUNCHER from the 1st activity, we can't get the 2nd activity to start by default when opening the app.