[Android] Derive default app id from application id, not package name

[simon-abbott]

Describe the Feature

In most cases the application id and package name / namespace are the same string. However in some cases they are not. For example, if a project got renamed but didn't want to change all their native code, or they ship with different app ids for prod, testing, local development, etc. This raises the question: why is the default app id (if you don't explicitly pass --appId) based on the package name and not the actual application id?

For example, if I have a React Native 0.71 project with the android/app/build.gradle configured with

android {
    namespace "com.example.foo"
    defaultConfig {
        applicationId: "com.example.bar"
    }
}

then running react-native run-android with no other flags will successfully build and install on the device, but will fail to start because it's trying to run the app com.example.foo.

I think a much more sensible default value would be to use the actual resolved applicationId value.

Possible Implementations

Related Issues

[thymikee]

Sounds reasonable. Can I pick your brain on that @cortinico?

[cortinico]

Can I pick your brain on that @cortinico?

Sure. So the thing is that we both:

• The package name (as we use it for autolinking)
• The app id (as we use it for launching the app)

Currently we default to read either the AndroidManifest.xml or the namespace field from build.gradle. So we're fe

The problem is, as @simon-abbott said, we're reading only one field and using it for two things. We should either:

1. Read both namespace and applicationId
2. Ask users that want to diverge the two to use --appId

[simon-abbott]

I think option 1 is far more intuitive. I would expect that the AndroidManifest package or build.gradle's namespace would be used just for building, while the applicationId is used to launch. Forcing users who want to have them be different to use a CLI flag feels awkward, especially for our particular use-case of having multiple appIds for dev and prod.

There are two types of people using this:

1. People who use the same namespace and appId
2. People who use different namespaces and appIds

Additionally, there are a further two groups of people:

1. Those who want to launch the appId stored in build.gradle
2. Those who want to launch a different appId

With the current implementation we have the following:

	appId == namespace	appId != namespace
appId == launch id	no flags needed	need to use --appId
appId != launch id	need to use --appId	need to use --appId

If we change the implementation to use the applicationId in build.gradle as the default launch id, we have the following:

	appId == namespace	appId != namespace
appId == launch id	no flags needed	no flags needed
appId != launch id	need to use --appId	need to use --appId

This way if the app id you want to launch is the one you are building, then you don't need to use any flags, regardless of your code's namespace. If you want to override the launched application id though (maybe you're building the main app but starting some tests), you can still use --appId to override it as before.

[adamTrz]

I think option 1 is far more intuitive. I would expect that the AndroidManifest package or build.gradle's namespace would be used just for building, while the applicationId is used to launch. Forcing users who want to have them be different to use a CLI flag feels awkward, especially for our particular use-case of having multiple appIds for dev and prod.

Sounds reasonable. Maybe we could detect and pass both values into Android projectConfig and then use one for building and second for installing the app? We could even pop in a warning that both are different and inform user we're selecting one?

Also I've noticed that when *.apk is built whe get output-metadata.json file with actual applicationId.
Maybe we could somehow leverage this info?

[cortinico]

Sounds reasonable. Maybe we could detect and pass both values into Android projectConfig and then use one for building and second for installing the app? We could even pop in a warning that both are different and inform user we're selecting one?

Yup this sounds great to me 👍

[adamTrz]

Created draft PR what will extract appId from default config of build.gradle.
cc @cortinico @simon-abbott mind taking a look? 🙂

#1951