[🐛] 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 : https://github.com/facebook/react-native/issues/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
• [x] I'm using Pods and my Podfile looks like:

# N/A

AppDelegate.m:

// N/A

---

Android

Click To Expand

Have you converted to AndroidX?

• [x] my application is an AndroidX application?
• [x] I am using android/gradle.settings jetifier=true for Android compatibility?
• [x] 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
  • [x] 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 -- https://github.com/reactwg/react-native-releases/discussions/21#discussioncomment-2793712 -- https://github.com/reactwg/react-native-releases/discussions/21#discussioncomment-2924919

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 #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 :sweat_smile: . 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!" :laughing: 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.

[mikehardy]

I've tested the two PRs to react-native that fix 1) react-native 0.69.0 and 2) hermes and they appear to work, so here's a patch-package patch to use those: https://github.com/mikehardy/rnfbdemo/blob/main/patches/react-native%2B0.69.0.patch

Flipper and New Architecture are still an issue, they are not compatible with use_frameworks on iOS. But, there is progress...

[TheRogue76]

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

Now that these issues are resolved on 0.69.1, Do we know the list of things that need to be done to enable it on the new arch? Or should it work out of the box with V15 on the new RN version since the ios sdk update was merged?

PS: Loved the comparison of open source and free puppy😂

[mikehardy]

Do we know the list of things that need to be done to enable it on the new arch?

Unfortunately no - zero attempt has been made to toggle on new architecture on ios or on android and see if it works at all

I am still just trying to get react-native-firebase v15+ to work with react-native 0.69+hermes - https://github.com/reactwg/react-native-releases/discussions/24#discussioncomment-3051434 - it's a rambunctious puppy, this one, chews up all the furniture...

[brett-james-rocketlab]

FWIW, on React-native 0.68.2 , I can't build the newest version of RNfirebase (v15.1.1.1) on iOS. The issues here are fixes being done in 0.69 which still don't work, but the post install fix, and static linking also don't work. It only shows up on a hardware device in release mode. https://github.com/reactwg/react-native-releases/discussions/24#discussioncomment-3051434

Android seems to be working fine.

Was it possible in the past to install v14 (so google api v8) with use_flipper still on, and hermes still enabled?

[mikehardy]

react-native-firebase v14 (including firebase-ios-sdk v8.15.0) and react-native 0.68 work with flipper and hermes enabled on ios

The difficulty is that firebase-ios-sdk v9+ requires use_frameworks, and this is something that has not historically been emphasized in the react-native ecosystem, so we are in the position of being on the frontier in an open source ecosystem. That's a bit messy and may take a little bit to settle down, but we'll get there.

Android is fine in all cases + combinations except that no effort has been made to get new architecture working yet. It is much more important to just get iOS working well with use_frameworks so all available time is being invested in that right now

[github-actions[bot]]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[mikehardy]

This is still an issue that needs a look

[github-actions[bot]]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[mikehardy]

Bot not respecting the pin after reconfiguration, which is a secondary thing that needs a look...

[TheRogue76]

Bot not respecting the pin after reconfiguration, which is a secondary thing that needs a look...

Just as a reminder, you are fucking amazing, Mike. Bless ya for all the work you do and for still keeping up with this issue.

[TheRogue76]

Sort of random, but I saw some commits on RN's master branch a while ago: https://github.com/facebook/react-native/commit/6d349524201e150029202134910de445328072e8 https://github.com/facebook/react-native/commit/b1b2b8baafa5a221115a23b89cb77a230846c1d0 https://github.com/facebook/react-native/commit/23eb380f6556f97c333b8505e78bebf1e895951f Fingers crossed maybe? (This will probably be 0.72 but it looks promising as far as I can see) Update: They made an announcement: https://github.com/reactwg/react-native-new-architecture/discussions/115

[github-actions[bot]]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[archcorsair]

Hey @mikehardy I believe this is still somewhat related to the topic, I'm aware of the new arch incompatibility, but what about hermes now? What if I'm still using the old arch, but would like to bump my firebase beyond version 14 because we rely on the hermes engine. Is it safe to update in that regard?

I only see one mention of hermes in the changelog and that's under the breaking changes introduced in v15+

[mikehardy]

Hermes should be fine, I test it regularly and use it my work app. Please let me know if it doesn't work for you

[github-actions[bot]]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.