[🐛] Android build error after upgrading to new architecture

[kamal-j]

Issue

I have upgraded react native to 0.68.2 and the android build is failing ever since.

Describe your issue here
When i run
npx react-native run-android

this is the error i get

ERROR:/Users/kamaldeepjayaprakash/Documents/projects/dstreetfinance/dstreet-frontend/node_modules/@react-native-firebase/app/android/build/.transforms/a4a6532b814617c59f54e306212cd90a/transformed/classes/classes.dex: D8: Type io.invertase.firebase.BuildConfig is defined multiple times: /Users/kamaldeepjayaprakash/Documents/projects/dstreetfinance/dstreet-frontend/node_modules/@react-native-firebase/app/android/build/.transforms/a4a6532b814617c59f54e306212cd90a/transformed/classes/classes.dex, /Users/kamaldeepjayaprakash/Documents/projects/dstreetfinance/dstreet-frontend/apps/mobile-df/node_modules/@react-native-firebase/app/android/build/.transforms/9e18e2735b77ba66968224f94e7e09a6/transformed/classes/classes.dex
com.android.builder.dexing.DexArchiveMergerException: Error while merging dex archives: 
Type io.invertase.firebase.BuildConfig is defined multiple times: /Users/kamaldeepjayaprakash/Documents/projects/dstreetfinance/dstreet-frontend/node_modules/@react-native-firebase/app/android/build/.transforms/a4a6532b814617c59f54e306212cd90a/transformed/classes/classes.dex, /Users/kamaldeepjayaprakash/Documents/projects/dstreetfinance/dstreet-frontend/apps/mobile-df/node_modules/@react-native-firebase/app/android/build/.transforms/9e18e2735b77ba66968224f94e7e09a6/transformed/classes/classes.dex
Learn how to resolve the issue at https://developer.android.com/studio/build/dependencies#duplicate_classes.

---

I have also raised an issue in react-native's repo :
react/react-native#34021

Project Files

Javascript

Click To Expand

package.json:

# N/A

firebase.json for react-native-firebase v6:

{
  "react-native": {
    "android_task_executor_maximum_pool_size": 10,
    "android_task_executor_keep_alive_seconds": 3
  }
}

iOS

Click To Expand

ios/Podfile:

• I'm not using Pods
• I'm using Pods and my Podfile looks like:

# N/A

AppDelegate.m:

// N/A

---

Android

Click To Expand

Have you converted to AndroidX?

• my application is an AndroidX application?
• I am using android/gradle.settings jetifier=true for Android compatibility?
• I am using the NPM package jetifier for react-native compatibility?

android/build.gradle:

// N/A

android/app/build.gradle:

// N/A

android/settings.gradle:

// N/A

MainApplication.java:

// N/A

AndroidManifest.xml:

<!-- N/A -->

---

Environment

Click To Expand

react-native info output:

System:
OS: macOS 12.3.1
CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
Memory: 762.99 MB / 16.00 GB
Shell: 5.8 - /bin/zsh
Binaries:
Node: 17.9.0 - /usr/local/bin/node
Yarn: 1.22.17 - /usr/local/bin/yarn
npm: 8.5.5 - /usr/local/bin/npm
Watchman: Not Found
Managers:
CocoaPods: 1.11.3 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5
Android SDK: Not Found
IDEs:
Android Studio: 2020.3 AI-203.7717.56.2031.7678000
Xcode: 13.4.1/13F100 - /usr/bin/xcodebuild
Languages:
Java: 17.0.2 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: * => 18.2.0
react-native: * => 0.68.2
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found

• Platform that you're experiencing the issue on:
  • iOS
  • Android
  • iOS but have not tested behavior on Android
  • Android but have not tested behavior on iOS
  • Both
• react-native-firebase version you're using that has this issue:
  "@react-native-firebase/analytics": "^14.11.0",
  "@react-native-firebase/app": "^14.11.0",
  "@react-native-firebase/auth": "^14.11.0",
  "@react-native-firebase/crashlytics": "^14.11.0",
  "@react-native-firebase/database": "^14.11.0",
  "@react-native-firebase/dynamic-links": "^14.11.0",
  "@react-native-firebase/in-app-messaging": "^14.11.0",
  "@react-native-firebase/messaging": "^14.11.0",
  "@react-native-firebase/remote-config": "^14.11.0",
• Firebase module(s) you're using that has the issue:
  • e.g. Instance ID
• Are you using TypeScript?
  • N

---

• 👉 Check out React Native Firebase and Invertase on Twitter for updates on the library.

[mikehardy]

Just a quick warning on this -

1. the new architecture does not support use of use_frameworks! yet
   -- Road to 0.69.0 reactwg/react-native-releases#21 (reply in thread)
   -- Road to 0.69.0 reactwg/react-native-releases#21 (reply in thread)

2. firebase-ios-sdk v9+ requires the use of use_frameworks!

-- https://firebase.google.com/support/release-notes/ios#cocoapods_users

3. We are in the process of adopting firebase-ios-sdk v9+ here feat(ios, sdk)!: firebase-ios-sdk v9; requires use_frameworks! + Xcode 13.3+ #6274 and I will merge it as soon as I can so we have up to date SDKs

So you should not expect the new architecture to work while using firebase-ios-sdk (via this module) for some unknown time. No effort is being made in this repo to test it until the above issues are resolved, though we are working to resolve those issues with react-native

[kamal-j]

So you should not expect the new architecture to work while using firebase-ios-sdk (via this module) for some unknown time. No effort is being made in this repo to test it until the above issues are resolved, though we are working to resolve those issues with react-native

For the time being I would be more than happy if I can get it working on Android.

[sergey-sivchenko]

@mikehardy, how do you think, will the installation via Swift Package Manager solve the issue? Is it possible in general? It is just an idea based on:

1. According to the Firebase docs:

For Firebase versions 8 and higher, Swift Package Manager is the recommended installation method.

2. use_frameworks! historically had issues with react-native and other libraries

[mikehardy]

@sergey-sivchenko that reminds me of the joke about regular expressions. "Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems."

Swift Package Manager may work. But now you'll be fighting all of the react-native ecosystem because you are not using the supported package manager. Trust me when I say you don't want to do that, since cocoapods is used in some surprising ways to handle all sorts of little things (see for instance https://github.com/facebook/react-native/blob/e5c5dcd9e26e9443f59864d9763b049e0bda98e7/scripts/react_native_pods.rb#L473-L499)

So that's not a direction I want to go. I think with the steady application of a little effort in combination with patience we'll get there.

There's already a PR that gets react-native 0.69 going with the Old Architecture + use_frameworks
There's already a PR that fixes Hermes + use_frameworks
In the PR for react-native 0.69 + use_frameworks there is also a general discovery that sheds light on the New Architecture incompatibility, and I think it will get solved.

Hang tight and it will all work - these issues are being tracked and tested and advanced (by me at least in part) so it'll happen over time

[sergey-sivchenko]

@mikehardy, thank you for the detailed answer. Good to know the opinion of someone with your knowledge and experience. I do not have much experience building the native modules for RN. Recently, one of the dependencies in the app I build switched from manual Framework linking to SPM. So, in the app we have to use both CocoaPods and SPM. On the web I found that it should be possible to the native module as well. But my native module is not published to NPM as a separate package, it is included directly within the RN application (for now and I keen to change it in the near future). As of today everything is smooth and working fine on RN 0.67.4. I hope it will work exactly the same after extracting to NPM package. That's why I came up with the idea above.

[iway1]

@mikehardy don't you think we probably should stick to the old iOS SDK if the new one wont be supporting new versions of React Native?

Being able to use the new architecture, hermes, etc is much more important to a typical React Native dev in general. I would think than using the newest firebase SDK, which has no notable impact on app performance, UX, or any of that, matters very little when compared to adopting the new architecture + hermes (which decreases app start up time, eliminates visible UI layout flickering, and improves performance overall).

It feels like I'm not going to be able to use the newest version of this library any time soon, and will have to stick to 14 for the foreseeable future. It's bizarre to me that a new release of a library designed for React Native has no plans for supporting new versions of React Native

[mikehardy]

don't you think we probably should stick to the old iOS SDK if the new one wont be supporting new versions of React Native?

Hard no. The way the react-native ecosystem works for change is demand-pull and user contribution. If we don't make it possible to move and in fact drive the change, the change doesn't happen. In fact, the patch for react-native to make 0.69 work is already merged in react-native, and the demand has already driven a second change that fixed Hermes + use_frameworks. So that's awesome, and justifies the strategy. I mean. 0.69.0 isn't even out yet and we already have the needed patches in (just planned for release as 0.69.1 quickly following), what a great result!

New architecture will be the same. We're the demand (and also to a large degree: the user contribution), and we'll pull react-native forward (and help do the work to get it there).

[mikehardy]

Another thing, you'll note that 9.2.0 of firebase-ios-sdk is coming out today (it's already tagged and in release process).
It fixes an auth issue among other things, am I to make it so affected people cannot access that fix? And the fixes that will be in >9.2 etc?
Plus my next task is to support a new v9 feature which has been requested here #6264 / #6321 - I see no reason to wait on that.

In other words - the software just moves inevitably on and we'll move with it, even if it's a bit messy. You certainly do not have to update past v14 until it satisfies your business needs (like: hermes working! I do understand that and I'm hoping that is picked for 0.69.1 as well)

[mikehardy]

Oh! Last comment - just I'm fully transparent on my thinking as I was adopting the new SDKs released as part of Google I/O 2022.

You'll note I adopted firebase-android-sdk v30+ first as a separate release (their breaking change, which happily did not result in breaking changes at our layer) prior to doing firebase-ios-sdk which was breaking at our layer. In order to give people maximum fixes with minimum breaks since I knew firebase-ios-sdk was going to be messy. Adopting new firebase-android-sdk versions will just mean doing the standard override until they issue v31 of firebase-android-sdk https://rnfirebase.io/#android

But new architecture is still a larger project which I don't suspect we will tackle here for quite a while unless someone wants to hop over here https://reactnative.dev/docs/new-architecture-intro and start posting PRs 😅 . Luckily the old architecture is not going away any time soon.

[iway1]

@mikehardy I guess I'm just experiencing some residual frustration from having downloaded react-native-firebase today only to realize the newest version that happened to be released yesterday isn't compatible with my project that needs to use the library.

As someone who's day to day is centered around using React Native for app development, I don't typically dive into what's going on with the development of these tools because it's not immediately relevant to me until something doesn't work because of situations like these.

makes sense though, thanks for the thoughtful reply and all of the work you do!

[mikehardy]

My favorite take on this is that open source is less like "hey free beer!" and more like "hey free puppy!" 😆
It's usually not this messy, but the switch to requiring use_frameworks is kind of a doozy. Something like this only comes around every couple years luckily.