Fixed the run-android cli script to start the correct activity when using different applicationId for different variants

[kgritesh]

I have fixed the old PR #8950 for the latest version of react-native. This PR fixes the runAndroid.js cli that uses the manifest file that is generated during the build process to find out the correct package name and activity name. As a result, it solves the issue where runAndroid command fails to start the app after installing it. Relevant Issue: #5546.

Some feedback i received for the last PR is to see if the desired result can be achieved using less lines of code. I looked at it again and am not sure i know how to achieve that. I list the step involved in order to fix this issue below.

• Find the correct manifest file for the particular variant that was installed

  1. Find all the buildTypes defined in the android/app/build.gradle file.
  2. Use the buildTypes found above and split the variant (default: debug) into a buildType and a product flavor
  3. Find if separate build enabled for different processors
  4. Using the above information find the path for the correct AndroidManifest.xml that is generated for the current run.

• Parse the manifest file found above and extract correct activity class.

• Use this activity class to start the app after its installed

Let me know @hramos@sharnik@Snorlock@chuyik if this works or any pointers in how to fix this.

[vongohren]

Looks like someone else is doing the same: #12634

[karanjthakkar]

I think there should be a null check for separateBuild before you access [1] of it. Reason: I was integrating React Native in an existing project and by default it did not have this key in the build.gradle file, nor is it necessary. So it would keep throwing the wrong error because the code for getManifestFile is wrapped in a try catch. So the error that an end user actually gets is adb invocation failed. Do you have adb in your PATH?.

[karanjthakkar]

@Snorlock I find this more reliable because:

1. The other PR assumes that the --variant flag would consist of the build type and the product flavor, which is not always the case.
2. Also, I'm not sure if extracting build type and product flavor from the variant is the right way to go because there is no way of marking they can exist together and individually as well.

I have tried this PR while integrating an existing project of mine and it worked perfectly with the exception of #12820 (comment).

@hramos@mkonicek Getting this in would really help solve issues faced by people who are integrating RN into existing apps which have different build types and product flavor configurations. What would it take to get this merged? I'd love to help!

// cc: @satya164

[Shane-Goodwin]

I came across this pull request while searching for a solution to this problem. The changes outlined worked almost perfectly except that line 288 should search for "buildTypes" plural. I changed it from:
const regex = new RegExp('buildType\\s+{', 'ig');
to:
const regex = new RegExp('buildTypes\\s+{', 'ig');
and all worked well for my additional buildTypes. Thanks!

[kgritesh]

@ericvicenti@karanjthakkar@Phredward since #13169 is already merged, i am assuming this PR is no longer necessary as it was trying to automatically get the appSuffixID. Please advise if I should close this or make it work with changes in the above mentioned issue.

[karanjthakkar]

@kgritesh I don't think this is needed any longer. Does your use case solve with #13169?

[Phredward]

Hi. I do still feel that it's worth trying to make runAndroid understand build.gradle so that developers only need to specify one argument to run their app (which variant to run).

That said, I no longer think the above is urgent, and I'm happy to take another stab at making this happen with the newer code, depending on what people think is the right way forward.

[aranda-adapptor]

Hi. I do still feel that it's worth trying to make runAndroid understand build.gradle so that developers only need to specify one argument to run their app (which variant to run).

Additionally, once we add flavors to build.gradle, the default react-native run-android no longer works (installDebug installs all test packages from all dependencies onto the target device!). If runAndroid understood build.gradle, it could pick the default (first?) to run installFirstFlavorDebug.

[rod-stuchi]

Working nicely. Thank you!

[facebook-github-bot]

@kgritesh I tried to find reviewers for this pull request and wanted to ping them to take another look. However, based on the blame information for the files in this pull request I couldn't find any reviewers. This sometimes happens when the files in the pull request are new or don't exist on master anymore. Is this pull request still relevant? If yes could you please rebase? In case you know who has context on this code feel free to mention them in a comment (one person is fine). Thanks for reading and hope you will continue contributing to the project.

[steinnes]

This works for me as well, we're using custom applicationIdSuffix different builds and since we started doing that react-native run-android stopped working. I replaced our runAndroid.js with the one from this PR and now it seems to find the right variant and supplies the right application id in the activity string.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. If you think this issue should definitely remain open, please let us know why. Thank you for your contributions.

[mnsrv]

why this is not merging?

[MrLoh]

It seems like #13169 wasn't merged and there's still no solution for this, since the first pull request was release in July 2016?

[hramos]

#13169 was merged, see d8f23f7. Closing as this PR is no longer necessary.

[fgeorgsson]

Whenever one of your flavors has a different package name #13169 still fails as it will use the packageName from the wrong AndroidManifest.xml. That is, it will not use the AndroidManifest.xml that was generated during build. This patch is still needed, your conclusion is wrong.

[Rovack]

@hramos, In light of the 11 people (at least) who believe the linked PR did not, in fact, solve the problem that necessitated this one, perhaps you could reconsider closing this?

[hramos]

First time I am aware of this. Can you please file a new issue?

[johanforssell]

I'm writing new versions of old apps, and thus I have inherited old app id's.

My code have the package com.common.package (in source files and AndroidManifest.xml).

My build.gradle contains

 buildTypes {
debug {
}
release {
minifyEnabled enableProguardInReleaseBuilds
proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
}
}
flavorDimensions "appName"
productFlavors {
appAAA {
dimension "appName"
applicationId "com.AAA.app"
versionCode 100
versionName "3.0.0"
}
appBBB {
dimension "appName"
applicationId "com.BBB.app"
versionCode 100
versionName '3.0.0'
}
}

First the app can be installed with gradlew

cd android && ./gradlew installAppBBBDebug

The I can start it manually with

adb -s emulator-5554 shell am start -n com.BBB.app/com.common.package.MainActivity

This is a bloody hassle. I would rather not have to mess with it like this.

[famousfilm]

Cross-posting what @Lavielle wrote because it solved my problem.
#17541 (comment)

Quote:
I ran into this issue and found some way to make it work:
I have two product flavors

• prod, with applicationId "com.yetno.yetnoapp" (which is the main app id)
• dev, with applicationId "com.yetno.yetno_app"

When building and running dev (react-native run-android --variant=devDebug) I was getting the error described in this issue.

Then I noticed, if I build the prod variant first and have it installed on the device, building and installing the dev variant works fine.
So the steps are:

1. cd android && ./gradlew clean
2. cd ..
3. react-native run-android --variant=prodDebug
4. react-native run-android --variant=devDebug

So this is not really an answer, but it worked for me and maybe it can help some of you guys out :)

[nicodelpiano]

@famousfilm Are you sure that works? I'm guessing you are executing the Activity from prodDebug, not devDebug which is the one you want.

[famousfilm]

@nicodelpiano - I didn't use prodDebug for my setup, but that is one you can use. The instructions above were copied from a separate post just so no one one had to click links to get the content.

[philjoseph]

I have different ProductFlavors with completely different App ID's and this PR is resolving the pb of the application launch. I really think this shall be merged @hramos

[petergaultney]

This is affecting us as well, on 0.56. Thanks @kgritesh for the PR. Maintainers: let's please see this re-opened and merged...

[hramos]

The CLI is no longer part of the repository in 0.59. Please open a new issue / PR against https://github.com/react-native-community/react-native-cli instead.

[elirangoshen]

I still have this issue. on rn 0.60.4 please reopen this