[0.76] Android old-architecture crash when app started via headlessJS init pathway - was: Some Android Devices Crash After Upgrade to 0.76.1 #47592
Comments
react-native-bot
added
Needs: Author Feedback
Needs: Repro
|
Warning Missing reproducer: We could not detect a reproducible example in your issue report. Please provide either:
|
nes123
changed the title
|
Hey @nes123, Without a minimum reproducer, we can't help you in the best way. This may be related to your dependencies, if it is possible to reproduce the error only with React Native core it would help. You can use our Reproducer Template to investigate further |
|
Thank you for your reply @migueldaipre unfortunately i didnt manage to reproduce this crash. It is happening in 1/20 cases in production without any noticeable pattern. Any help will be very much appreciated. |
github-actions
bot
added
Needs: Attention
|
Some more info: It happens when opening firebase notification when the app is killed..crashes on start. The stack includes this error in addition to what I provided above: Crashes with EarlyJsError: TurboModuleRegistry.getEnforcing(...): 'PlatformConstants' could not be found. Verify that a module by this name is registered in the native binary. Only checked with new architecture disabled. |
|
I'm also having the same issues with RN 0.76.1 in production. |
|
Hey @migueldaipre 👋 I'm the react-native-firebase maintainer and I'm working on reproducing this, and I'm able to (on 0.76.2 even) I have information here invertase/react-native-firebase#8131 The problem is that it requires doing something/anything that boots the app externally via a receiver (I think?) while new arch is disabled, and the best way I know to do that is by sending an FCM to the device. Unfortunately that requires having a firebase project setup and everything - it's pretty difficult to share a reproduction like that. I'll see if I can get a more minimal reproduction but until then if there is anything I can do to troubleshoot, please let me know Until then, full methodology to reproduce is in this comment, along with error seen: |
- add native android receiver you can trigger with an easy intent - add native android headlessJS service that receiver starts - document how to trigger the error Related: facebook/react-native#47592
|
Okay, got a reproducer up that's pretty minimal, with instructions in the README on exactly how to trigger I think it's something about the module loading implemented in 0.76.x - it looks to me like the soloader isn't seeing the new combined modules or something, in the old-architecture pathway. Just a hunch based on https://github.com/mikehardy/old-arch-android-receiver-boot-crash Apart from the documentation the reproducer is a +49/-1 diff, with no non-stock dependencies at all from the template so it's pretty minimal, hopefully easy to understand |
|
Hey @mikehardy 👋 Thank you for all your effort and time to build a minimal reproducer without any external dependencies. I'll add the necessary tags for an investigation soon by the core team. |
migueldaipre
added
Issue: Author Provided Repro
|
@mikehardy Thanks for working on the reproducer. Also, when a notification is received, what's the initialization path followed by an app with Firebase in the old architecture? Could you guide me through it? |
|
Hey @cipolleschi - first, thanks for any attention here, it's appreciated. As motivation there have been several headlessJS issues with new architecture as well as some other things and I know those are being worked out, but people are still using old arch even on 0.76+ and react-native-firebase has to use headlessJS for background messaging to device, so this affects a lot of people. Otherwise just go to new arch right? But this will be with us for a while. Anyway to your questions - 1- old-arch only correct: this does not reproduce in new architecture. I only reproduce this in old architecture The initial app wakeup:
The handoff from android native receiver to android native headlessJS service:
Sending FCM in a reproducer is a HUGE pain because of all the external setup required - create firebase project (credentials, ugh), connect them (json init files, play services stuff, ugh) - it works now but you can't share it because credentials (ugh) So I have essentially mocked all the FCM stuff out and just have the purest expression of the bug: 1- define a receiver that you can trigger with a repro-specific example intent So now you can just use The only repro restriction between my repro and the react-native-firebase call chain is that since we are not sending 'high-priority' FCM, the system will impose background service start restrictions in higher APIs causing the reproducer to fail for unrelated reason ( IllegalStateException or BackgroundServiceStartNotAllowedException depending on API ) To keep the reproducer simple, it's easier to just run it in lower APIs. API24 / Android 7 works well Does that explain everything? Hope so 🤞 |
|
BTW - the title of this issue should be, I think: And I do have a strong hunch that it is something about the soloader / appmodules change that combined native modules between 0.75 and 0.76. Supporting information for that hypothesis:
and after a few tries it ends with:
That seems important |
|
Also for what it's worth, I can see libappmodules.so in the correct spot for my emulator arch in the local APK I reproduced the problem with. 
(which makes sense, the app works in foreground or when following "regular" / non-headlessJS init pathway) |
|
I am wondering if there some kind of workaround for this? |
|
@noamyagil no known workaround, no known PR. Someone affected+motivated is going to need to follow the steps to build react-native locally and instrument the area around soloader during reproduction locally to catch it in action and figure out the "why" then post a PR I believe. I'm focused on getting things working in new architecture personally so I won't be advancing anything here myself though obviously anyone is more than welcome to use my reproducer to trigger it, would be wonderful if that was useful+helped |
|
@mikehardy I may be out to lunch but I seem to have my headless stuff (background-geolocation, background-fetch) working with both new and old arch on 76.3. Is this a flakey phenomenon that periodically happens on some devices? |
|
I could trigger the old arch crash every time from cold start in background after a kill then a service wake. New arch seems good with some library issues (maybe react-native-push-notifications? Maybe reanimated?) but it seems good in the libraries I've tested |
|
@mikehardy Just to better understand that maybe I missed something. Does this error problem only occur when using the old architecture in version RN76? If you use the new architecture, does everything work fine? |
I believe that’s what @mikehardy said, yes. |
|
@cortinico could this be related to the headless JS issue, even if it is on the old architecture? |
|
I'm not sure what could be the reason, but I want to look more closely into this one in the next days. Thank you very much @mikehardy for the repro and the enormous amount of work you already did in this investigation. This is really priceless! Let's find the root cause and get it sorted out |
cortinico
changed the title
cortinico
removed
the
Needs: Attention
|
I have the suspect it has to do with the fact that @mikehardy could you try to edit those lines: as such: class ExampleReceiver : BroadcastReceiver() {
override fun onReceive(context: Context, intent: Intent?) {
+ SoLoader.init(this, OpenSourceMergedSoMapping)
Log.d("REPRODUCER", "we received an intent. Starting ExampleService...");and let me know if it fixes. I'll investigate further tomorrow. |
|
@cortinico unfortunately no, adding that (but with
|
Background messaging is critical to react-native-firebase and notifee, this is some vital functionality for us 😅 . Wish I could just up a PR but I don't know the area well. So posting up reproducers it is... |
Summary: Fixes facebook#47592 The logic in HeadlessJsTaskService is broken. We should not check whether `getReactContext` is null or not. Instead we should use the `enableBridgelessArchitecture` feature flag to understand if New Architecture was enabled or not. The problem we were having is that `HeadlessJsTaskService` was attempting to load the New Architecture even if the user would have it turned off. The Service would then die attempting to load `libappmodules.so` which was correctly missing. Changelog: [Android] [Fixed] - Fix crash on HeadlessJsTaskService on old architecture Differential Revision: D66826271
migueldaipre
added
the
Resolution: PR Submitted
|
This should be the fix: @mikehardy if you wish you can try it in your reproducer, but you'll have to build from source. The problem was that there was a bug inside the Also the APK is NOT containing the |
Summary: Fixes facebook#47592 The logic in HeadlessJsTaskService is broken. We should not check whether `getReactContext` is null or not. Instead we should use the `enableBridgelessArchitecture` feature flag to understand if New Architecture was enabled or not. The problem we were having is that `HeadlessJsTaskService` was attempting to load the New Architecture even if the user would have it turned off. The Service would then die attempting to load `libappmodules.so` which was correctly missing. Changelog: [Android] [Fixed] - Fix crash on HeadlessJsTaskService on old architecture Reviewed By: javache Differential Revision: D66826271
|
built from source, needed a tiny tweak to work for me (I suggested same on linked PR) but it looks like you nailed the root cause, @cortinico 🐐 😄 |
|
BTW @mikehardy I want to call out how important was for you to provide a reproducer and even going the extra mile by providing an initial investigation! If we were able to identify the problem and fix it so quickly was exclusively thanks to you. It looks like I fixed the bug, but most of the work was done by you and I just wanted to call it out. |
Summary: Pull Request resolved: #48124 Fixes #47592 The logic in HeadlessJsTaskService is broken. We should not check whether `getReactContext` is null or not. Instead we should use the `enableBridgelessArchitecture` feature flag to understand if New Architecture was enabled or not. The problem we were having is that `HeadlessJsTaskService` was attempting to load the New Architecture even if the user would have it turned off. The Service would then die attempting to load `libappmodules.so` which was correctly missing. Changelog: [Android] [Fixed] - Fix crash on HeadlessJsTaskService on old architecture Reviewed By: javache Differential Revision: D66826271 fbshipit-source-id: 2b8418e0b01b65014cdbfd0ec2f843420a15f9db
Summary: Pull Request resolved: #48124 Fixes #47592 The logic in HeadlessJsTaskService is broken. We should not check whether `getReactContext` is null or not. Instead we should use the `enableBridgelessArchitecture` feature flag to understand if New Architecture was enabled or not. The problem we were having is that `HeadlessJsTaskService` was attempting to load the New Architecture even if the user would have it turned off. The Service would then die attempting to load `libappmodules.so` which was correctly missing. Changelog: [Android] [Fixed] - Fix crash on HeadlessJsTaskService on old architecture Reviewed By: javache Differential Revision: D66826271 fbshipit-source-id: 2b8418e0b01b65014cdbfd0ec2f843420a15f9db
|
Thank you guys 🚀 Upgraded from 0.76.3 to 0.76.5 and reduced this specific crash issue from over 100k from single day to 0 events (so far tested on 20% of users but already rolling to 100%) |
|
Great I will update too |
|
@LukasMod that's amazing! Thanks for the update <3 |
|
I'm experiencing a crash on startup of my app, and I think it's this same issue as it's only come about since upgrading to RN 0.76, old architecture. Can anyone confirm if it's the same issue from this log? |
Description
After upgrading from react-native 0.73 to 0.76.1 few android apps in production crash on start.
any help will be much appreciated
Steps to reproduce
Reproducer is here: https://github.com/mikehardy/old-arch-android-receiver-boot-crash
React Native Version
0.76.1
Affected Platforms
Runtime - Android
Output of
npx react-native infoStacktrace or Logs
Reproducer
N/A
Screenshots and Videos
No response
The text was updated successfully, but these errors were encountered: