I will make the change.

Without this change everything worked but I was seeing a deprecation warning described here: https://stackoverflow.com/questions/69911807/we-recommend-using-a-newer-android-gradle-plugin-to-use-compilesdkpreview-sv2. After bumping AGP version to 7.2.2 the warning disappeared.

Thanks!! It can be good to explain this stuff ahead of time, so we can reduce review churn

Context for this change is more complex. When I first modified .gradle files to target android 13 every time I run react-native run-android I was receiving the following error:

Starting: Intent { cmp=app.comm.android/.MainActivity }
Error type 3
Error: Activity class {app.comm.android/app.comm.android.MainActivity} does not exist.

However the app was successfully installed and I was able to launch it by tapping icon. Therefore I postponed fixing this error since I wanted to get the diffs up as soon as possible. After some research I found this article: https://medium.com/androiddevelopers/making-sense-of-intent-filters-in-android-13-8f6656903dde
It states that since Android 13 even explicit intents are checked against intent filters. Therefore after our migration the intent that we use in SplashActivity to start MainActivity does not pass intent-filter data test. After discussion with @bartek I decided to add additional intent filter that is compliant with intent from SplashActivity.java we use to start MainActivity.

Context for this change is here: https://medium.com/tech-takeaways/migrating-my-app-to-android-13-f5ad0649d23d

1. Regarding that silence - generally I thought it's weird that Android Studio marks this as error, while the documentation says:

To specify accepted intent data, an intent filter can declare zero or more <data> elements,

Then I discovered that changing action.VIEW to e.g. action.MAIN silences that warning. This implies that some actions require <data> to be set while others not. Maybe we should find an action type that better fits this case?

2. Generally I'm leaning toward moving this to the main manifest. The only reason I didn't rush forcing it was that @marcin ensured me offline that he tested this on a release build.

1. In the article I linked it is stated that since Android 13 explicit intents are checked against intent-filters. Older android versions used intent-filters exclusively against implicit intents. Intent matching is more complex. Briefly there are the rules:

https://developer.android.com/guide/components/intents-filters#Resolution

• If there are no intent filters the intent always matches. If there are many we need to just match one.
• If intent filter declares no action then no intent matches filter. However if there are actions in the filter but not in the intent the intent matches the filter. Intent can't have different action than the one declared in the filter
• Same for categories. But since CATEGORY_DEFAULT is always in intent then intent filter must have this category so that it can be matched.
• If filter declares data then intent MUST contain data that matches data format declared in the filter. If intent has no data then we fail the test.

We can silence that warning with tools:ignore="AppLinkUrlError". Should we do that?

Actually after searching a bit I found a way to avoid warning without suppressing. We can actually define our own custom action for the intent and intent filter: https://developer.android.com/guide/components/intents-filters#Receiving. So I defined the following intent filter in main (worked in debug as well) manifest:

<intent-filter>
  <action android:name="app.comm.android.START_MAIN_ACTIVITY" />
  <category android:name="android.intent.category.DEFAULT" />
</intent-filter>

This solution also works without warning in Android Studio. Based on the matching rules I described above, the action field in an intent filter doesn't matter as long as it is there and intent does not carry any action on its own. The category field DEFAULT is a must.

I would proceed with this solution, however would first like to receive reviewers opinions. cc @ashoat , @bartek

After reading the documentation and based on my own experiences, your solution looks totally legit to me.

If you tested:

• running both debug and release builds
• on both of these you tried:
  • running this from adb cli / react-native run-android
  • running this by clicking launcher icon

Then I'm OK with your approach. Just be sure to make this change in main AndroidManifest, not the debug one