fix: use namespace instead of appId when generating MainActivity #1830
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes how the fully specified MainActivity is specified.
Previously, for
.-prefixed activities, we read theapplicationIdfrombuild.gradleand appended the Activity name, e.g.build.gradlewith:and
AndroidManifest.xmlwith:would generate
com.example.mobile.MainActivity.However, Android uses the application package's
namespaceinstead of AppID when creating the Activity name (docs):This means, in the previous example, the actual name of the main activity would have been
com.example.MainActivity.This hasn't historically been a problem because the activity name is only used when launching expo-dev-client apps, and Expo CNG generates an Android application package with the same
namespaceandapplicationId, but we've run into a case of an application which bypasses Expo CNG and overrides the defaultapplicationIdfor legacy reasons.This PR changes the approach to correctly use the namespace in this case.
The implementation is based on
@expo/config-plugin's implementation ofgetApplicationIdAsync, which is not very resilient (it's just a regex looking fornamespacein thebuild.gradlefile), but since it's only used in projects using expo dev client at the moment, it should be good enough (without having to properly parse Groovy files).How Has This Been Tested:
How Has This Change Been Documented:
INTERNAL