question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[Android] Upgrade of CLI from 3.x to 4.x (with RN 0.62) breaks --appIdSuffix

See original GitHub issue

Environment

System:
    OS: macOS 10.15.3
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 594.50 MB / 32.00 GB
    Shell: 3.1.0 - /usr/local/bin/fish
  Binaries:
    Node: 10.16.3 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.9.0 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.9.0 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 13.2, DriverKit 19.0, macOS 10.15, tvOS 13.2, watchOS 6.1
    Android SDK:
      API Levels: 28, 29
      Build Tools: 28.0.3, 29.0.2
      System Images: android-29 | Google APIs Intel x86 Atom
      Android NDK: Not Found
  IDEs:
    Android Studio: 3.5 AI-191.8026.42.35.5977832
    Xcode: 11.3/11C29 - /usr/bin/xcodebuild
  Languages:
    Python: 2.7.16 - /usr/bin/python
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.11.0 => 16.11.0
    react-native: 0.62.0 => 0.62.0
  npmGlobalPackages:
    *react-native*: Not Found

Description

We’re using an applicationIdSuffix in our apps gradle file for debug, which we run with npx react-native run-android --appIdSuffix debug

    buildTypes {
        debug {
            applicationIdSuffix ".debug"
            signingConfig signingConfigs.debug
        }
    }

This has worked thus far with the CLI v3.x, but as we upgraded our project to React Native 0.62.0, the CLI was upgraded to v4.4.

Now we’re getting the following error when the app builds, running the same command:

$ react-native run-android --appIdSuffix debug
info Running jetifier to migrate libraries to AndroidX. You can disable it using "--no-jetifier" flag.
Jetifier found 1976 file(s) to forward-jetify. Using 16 workers...
info JS server already running.
info Installing the app...

<snip>

FAILURE: Build failed with an exception.

* What went wrong:
Task 'installDebugDebug' not found in project ':app'.

Reproducible Demo

Sample project: https://github.com/cbrevik/suffixExample

Note: I’ve just generated a 0.62 project with npx react-native init, and added an extra commit on top of that with applicationIdSuffix: https://github.com/cbrevik/suffixExample/commit/d6129ec0b79adaab38f5641eadec88e0faeb0493

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:5 (5 by maintainers)

github_iconTop GitHub Comments

2reactions
cbrevikcommented, Mar 31, 2020

Sure! This seems like the bug: https://github.com/react-native-community/cli/commit/19ac71f02c0ececa669afb26dce2cb02f0de23f6#diff-b668aefc66b33ed6e984d3467db0abc1R54 (concat appIdSuffix to variant in order to generate the task name).

The workaround for me was to just overwrite the task name, with:

react-native run-android --tasks installDebug --appIdSuffix debug

Even though that works, it seems like the options should work in a different way.

As far as I understand, a build variant in Android is the full name of the build type with the flavor. So for example the build type could be debug, while the flavor could be demo, which makes the build variant demoDebug. I’m not an expert at gradle though, so 🤷‍♂

In this case, the appIdSuffix should only be used when launching the app, not when building it. I think the appIdSuffix doesn’t have to be the same as the build type, so concatenating the suffix + variant probably isn’t a good idea?

So maybe it’s better if people specify the “full” variant name to build with --variant while --appIdSuffix only helps the CLI launch the correct package.

I’ve commited a fix here; https://github.com/AtB-AS/cli/commit/bd297f4bbae6cb5af0442a3bb01ff82cf766d39e

I’d love to open a PR in this case, if it seems like the right solution.

1reaction
krizzucommented, Mar 31, 2020

I agree that CLI params naming are bit misleading here, so I’m up for the change.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Upgrade to React Native 0.62 - Matt Oakes
React Native 0.62 has been a long time coming and brings many changes, large and small. This article explains what's new, how to...
Read more >
Upgrading to new versions - React Native
Upgrading to new versions of React Native will give you access to more APIs, views, developer tools and other goodies. Upgrading requires a ......
Read more >
@react-native-community/cli: Versions | Openbase
Note: The latest version of the CLI, compatible with React Native 0.62. Breaking changes. Correctly handle flavors and build types in run-android command...
Read more >
Updating Your React Native App - Medium
Update : I finally tried out rn-diff and I now recommend it over react-native-git-upgrade . See below for more details and skip this...
Read more >
React Native CLI 3.1.0 and 4.0.0 - What's New? | blog {callstack}
0? Improved support for different build flavors on Android; Metro update to 0.58 version; Version next; Wrapping up. What is React Native CLI...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found