react-native-ble-manager
react-native-ble-manager copied to clipboard
innoveit
App crashes after 4-5 seconds of calling startScan on signed apk - Android
Before open an issue
- Check the closed issues, your question maybe is not new.
- We can't debug or reproduce hardware issue.
- If the library is not working 99% you did something wrong, in the code, installation or in the phone permissions.
Describe the bug on specific android devices, after calling BleManager.scan the app crashes after 4-5 seconds on signed APK The error reported on firebase is not giving any details:
Crashed: Thread: SIGSEGV 0x00000000c0deadc4
#00 pc 0x326534 libart.so (BuildId: d963fb24d06855807a6574ea74a2cf53)
#01 pc 0xba09eda6
#02 pc 0xba09e544
#03 pc 0xba09ed86
#04 pc 0x322dfe libart.so (BuildId: d963fb24d06855807a6574ea74a2cf53)
#05 pc 0xba09e544
so i digged further with adb logcat and i noticed couple of things related to the crash:
2025-02-18 10:20:02.048 22972 22972 I RNBleManager DiscoverPeripheral: null
2025-02-18 10:20:02.057 2130 2397 D BtGatt.GattService onScanResult to scannerId: 3- eventType=0x1a, addressType=1, address=XX:XX:XX:XX:42:47, primaryPhy=1, secondaryPhy=0, advertisingSid=0xff, txPower=127, rssi=-78, periodicAdvInt=0x0
2025-02-18 10:20:02.127 2130 2397 D BtGatt.GattService onScanResult to scannerId: 3- eventType=0x10, addressType=1, address=XX:XX:XX:XX:3E:98, primaryPhy=1, secondaryPhy=0, advertisingSid=0xff, txPower=127, rssi=-58, periodicAdvInt=0x0
2025-02-18 10:20:02.264 22972 22972 F libc Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xc0deadc4 in tid 22972 (com.bletest), pid 22972 (com.bletest)
2025-02-18 10:20:02.340 23057 23057 I crash_dump32 obtaining output fd from tombstoned, type: kDebuggerdTombstoneProto
2025-02-18 10:20:02.341 621 621 I tombstoned received crash request for pid 22972
2025-02-18 10:20:02.342 23057 23057 I crash_dump32 performing dump of process 22972 (target tid = 22972)
2025-02-18 10:20:02.800 2130 2478 D BtGatt.GattService Binder is dead - unregistering scanner (3)!
2025-02-18 10:20:02.800 2130 2478 D LeAppInfo removeLeacReportedServerApp, appName: com.bletest
2025-02-18 10:20:02.801 802 802 I Zygote Process 22972 exited due to signal 11 (Segmentation fault)
i noticed that the crash is being dumped to Tombstone so i ran adb.exe bugreport to pull the tombstone file. and it contained
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'samsung/a13vensser/a13ve:14/UP1A.231005.007/A137FXXU6EXG3:user/release-keys'
Revision: '1'
ABI: 'arm'
Processor: '1'
Timestamp: 2025-02-18 10:20:02.370105320+0000
Process uptime: 11s
Cmdline: com.bletest
pid: 22972, tid: 22972, name: com.bletest >>> com.bletest <<<
uid: 10263
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xc0deadc4
r0 c0dead90 r1 e42ae809 r2 0000000d r3 000000a5
r4 fff61294 r5 fff61284 r6 fff61274 r7 0000206e
r8 00000000 r9 e91baa00 r10 e1630e00 r11 ba09eda8
ip 00000000 sp fff61260 lr e163454c pc e1634534
30 total frames
backtrace:
#00 pc 00326534 /apex/com.android.art/lib/libart.so (nterp_op_invoke_virtual+52) (BuildId: d963fb24d06855807a6574ea74a2cf53)
#01 pc 00876da8 /data/app/~~v5p35KBpWZ0nsdHyyvV0yQ==/com.bletest-7FoSQHRwBdIS8-dMoCMLFg==/oat/arm/base.vdex (it.innove.NativeBleManagerSpec.emitOnDiscoverPeripheral+16)
#02 pc 0032c500 /apex/com.android.art/lib/libart.so (nterp_helper+2800) (BuildId: d963fb24d06855807a6574ea74a2cf53)
#03 pc 00876546 /data/app/~~v5p35KBpWZ0nsdHyyvV0yQ==/com.bletest-7FoSQHRwBdIS8-dMoCMLFg==/oat/arm/base.vdex (it.innove.DefaultScanManager.onDiscoveredPeripheral+318)
#04 pc 0032c500 /apex/com.android.art/lib/libart.so (nterp_helper+2800) (BuildId: d963fb24d06855807a6574ea74a2cf53)
#05 pc 008763c4 /data/app/~~v5p35KBpWZ0nsdHyyvV0yQ==/com.bletest-7FoSQHRwBdIS8-dMoCMLFg==/oat/arm/base.vdex (it.innove.DefaultScanManager.-$$Nest$monDiscoveredPeripheral+0)
#06 pc 0032ba48 /apex/com.android.art/lib/libart.so (nterp_helper+56) (BuildId: d963fb24d06855807a6574ea74a2cf53)
#07 pc 00876234 /data/app/~~v5p35KBpWZ0nsdHyyvV0yQ==/com.bletest-7FoSQHRwBdIS8-dMoCMLFg==/oat/arm/base.vdex (it.innove.DefaultScanManager$2$1.run+12)
#08 pc 005a2c87 /system/framework/arm/boot-framework.oat (android.os.Handler.dispatchMessage+70) (BuildId: 72d9f3b9c14393f5511d5220f35de6d6627160bb)
#09 pc 005a5847 /system/framework/arm/boot-framework.oat (android.os.Looper.loopOnce+854) (BuildId: 72d9f3b9c14393f5511d5220f35de6d6627160bb)
#10 pc 005a547f /system/framework/arm/boot-framework.oat (android.os.Looper.loop+478) (BuildId: 72d9f3b9c14393f5511d5220f35de6d6627160bb)
#11 pc 00383c9f /system/framework/arm/boot-framework.oat (android.app.ActivityThread.main+1542) (BuildId: 72d9f3b9c14393f5511d5220f35de6d6627160bb)
#12 pc 00143dd5 /apex/com.android.art/lib/libart.so (art_quick_invoke_stub_internal+68) (BuildId: d963fb24d06855807a6574ea74a2cf53)
#13 pc 001bc1e1 /apex/com.android.art/lib/libart.so (void art::quick_invoke_reg_setup<true>(art::ArtMethod*, unsigned int*, unsigned int, art::Thread*, art::JValue*, char const*) (.__uniq.192663596067446536341070919852553954320.llvm.17112358095869631794)+112) (BuildId: d963fb24d06855807a6574ea74a2cf53)
#14 pc 001bbd3f /apex/com.android.art/lib/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+134) (BuildId: d963fb24d06855807a6574ea74a2cf53)
#15 pc 0029e8f1 /apex/com.android.art/lib/libart.so (_jobject* art::InvokeMethod<(art::PointerSize)4>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jobject*, _jobject*, unsigned int)+1100) (BuildId: d963fb24d06855807a6574ea74a2cf53)
#16 pc 004c433f /apex/com.android.art/lib/libart.so (art::Method_invoke(_JNIEnv*, _jobject*, _jobject*, _jobjectArray*) (.__uniq.165753521025965369065708152063621506277)+22) (BuildId: d963fb24d06855807a6574ea74a2cf53)
#17 pc 0009c179 /system/framework/arm/boot.oat (art_jni_trampoline+56) (BuildId: 6baf4648bfc29351da5cc24a455a4e1c5e4a4b5d)
#18 pc 0088faed /system/framework/arm/boot-framework.oat (com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run+116) (BuildId: 72d9f3b9c14393f5511d5220f35de6d6627160bb)
#19 pc 00898603 /system/framework/arm/boot-framework.oat (com.android.internal.os.ZygoteInit.main+3034) (BuildId: 72d9f3b9c14393f5511d5220f35de6d6627160bb)
#20 pc 00143dd5 /apex/com.android.art/lib/libart.so (art_quick_invoke_stub_internal+68) (BuildId: d963fb24d06855807a6574ea74a2cf53)
#21 pc 001bc1e1 /apex/com.android.art/lib/libart.so (void art::quick_invoke_reg_setup<true>(art::ArtMethod*, unsigned int*, unsigned int, art::Thread*, art::JValue*, char const*) (.__uniq.192663596067446536341070919852553954320.llvm.17112358095869631794)+112) (BuildId: d963fb24d06855807a6574ea74a2cf53)
#22 pc 001bbd3f /apex/com.android.art/lib/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+134) (BuildId: d963fb24d06855807a6574ea74a2cf53)
#23 pc 001ef055 /apex/com.android.art/lib/libart.so (art::JValue art::InvokeWithVarArgs<art::ArtMethod*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, art::ArtMethod*, std::__va_list)+268) (BuildId: d963fb24d06855807a6574ea74a2cf53)
#24 pc 00106599 /apex/com.android.art/lib/libart.so (art::JValue art::InvokeWithVarArgs<_jmethodID*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, std::__va_list)+24) (BuildId: d963fb24d06855807a6574ea74a2cf53)
#25 pc 004706af /apex/com.android.art/lib/libart.so (art::JNI<true>::CallStaticVoidMethodV(_JNIEnv*, _jclass*, _jmethodID*, std::__va_list)+454) (BuildId: d963fb24d06855807a6574ea74a2cf53)
#26 pc 000899d9 /system/lib/libandroid_runtime.so (_JNIEnv::CallStaticVoidMethod(_jclass*, _jmethodID*, ...)+20) (BuildId: e953cf0acaa62fa69ffe71cea5372e21)
#27 pc 0009295d /system/lib/libandroid_runtime.so (android::AndroidRuntime::start(char const*, android::Vector<android::String8> const&, bool)+512) (BuildId: e953cf0acaa62fa69ffe71cea5372e21)
#28 pc 00002547 /system/bin/app_process32 (main+982) (BuildId: 518f3945cf61e7eeaf79c722821f237c)
#29 pc 0005bde5 /apex/com.android.runtime/lib/bionic/libc.so (__libc_init+60) (BuildId: ac29b057fca6aa7ac9a9161d7c6d401f)
which i deduced that the crash happened on emitOnDiscoverPeripheral in NativeBleManagerSpec. I added some logs in onDiscoveredPeripheral to see if the WritableMap is being corrupted in some way or there is something being returned as null and not handled, but i couldn't get to any results.
full logcat bugreport dumpstate-2025-02-18-10-20-35.zip tombstone will be under: FS/data/tombstones/tombstone_01 Git for test project that crashes
To Reproduce
Steps to reproduce the behavior:
1- generate a release apk by cd android && gradlew assembleRelease
2- go to Samsung Remote Test Lab sign in and get your free credits
3- search for device SM-A135F or SM-A137F and choose one from the list. it does not matter which android version or region, the crash happens on all devices in the list
4- upload the release apk to the device and install it
5- launch the app, you can wait for 40 seconds without doing anything and the app will crash on its own. or click Scan bluetooth and the app will crash after 5 seconds
Note: you can start a Remote Debug Bridge and launch the app with yarn run android, but it did not help me much since the app does not crash and behave as normal
Expected behavior App will crash
Smartphone (please complete the following information):
- Device: SM-A135F SM-A137F (samsung a13)
- OS: Android13 Android14
- react-native-ble-manager version: 12.1.3
- react-native version: 0.77.1 / 0.78.0-rc.5
Additional context The crash that happens on it's own after 40 seconds of app launch and without doing anything is related to GC and can be checked in tombstone_00. i fixed it to be able to further debug the crash that is happening on scan by checking if mEventEmitterCallback is not null before calling any emit function in Spec file
Same issue! Can't figure it out. Tried all sorts of patches.
I can't reproduce it but seeing the error logs in production. It does seem to be mostly related to Samsung A13 I've noticed
Same issue, i assume happening on low end devices, weirdly it was fine on development phase
Same issue! Can't figure it out. Tried all sorts of patches.
I can't reproduce it but seeing the error logs in production. It does seem to be mostly related to Samsung A13 I've noticed
it started happening when we switched our production app to react native new architecture since we were forced to be able to publish on IOS. now we reverted back our android app to old react native version so users can continue using the app, we were receiving crash logs by the hundreds. At first i wasn't able to reproduce the crash on our testing devices, although not all were high end devices and we had phones similar to A13 specs, but the crash doesn't happen on them.
so i decided to try one of the phones that are crashing, and the A13 was available on Samsung Remote test lab, it is a real device not emulator that you can test on and completely free you get 10 credits per day approx. 8 hours of testing.
if you test your app on it, it will crash
Created an issue also on react-native facebook/react-native#49510
@barakataboujreich any luck with this? I'm still struggling wtih this issue and seems to be happening to quite a few users. The weird thing is that it doesn't happen on debug - only release. Not sure why that would be the case
@barakataboujreich i'm pretty sure the issue is the event emitters.
For me at least, the error happens when the scan locates a device. The scan is fine but once there is a device returned from the scan then it crashes. When i comment out this line the crash stops https://github.com/innoveit/react-native-ble-manager/blob/67470d247a2cd2c7ca58e574b110d2fd7d2cc741/android/src/main/java/it/innove/DefaultScanManager.java#L224
Again - not happening on debug. Only release. Do you know if there is anything weird going on with these A13's in release related to event emitters?
@barakataboujreich i might have found a solution. I haven't fully tested it yet but is working on samsung A13 (but won't get a chance to test on phones that currently work or ios yet)
Instead of sending events with bleManager.emitOnDiscoverPeripheral(map);
reactContext
.getJSModule(DeviceEventManagerModule.RCTDeviceEventEmitter.class)
.emit("onDiscoverPeripheral", map);
And then in the app
const bleManagerEmitter = new NativeEventEmitter(NativeModules?.BleManager)
useEffect(() => {
const deviceListener = bleManagerEmitter.addListener(
"onDiscoverPeripheral",
handleDiscoverPeripheral
)
return () => {
deviceListener?.remove()
}
}, [])
Here is a patch package to update all of the event emitter requests https://gist.github.com/CaptainJeff/b56113ee751658fe07f377b23e6a18ac
@CaptainJeff yeah the issue is related to specific devices A13 is one of them. the list of devices we got crash on: A13, A13 5G, A03 Core, A11, Moto G Pure, Lenovo Tab M8 at first i thought maybe it is a chip issue since the early reports were showing crashes on Mediatek chip only. but then crash reports kept on coming and the issue was happening on any chip. so i thought maybe it is a ram issue, but then some reports had 1.47GB+ free ram out of 4GB. so i went and bought one of the oldest cheapest Huawei phone that freezes if i open a browser, and surprisingly our app works normal and doesn't crash. so i have no idea what is the issue with these devices and i think neither does react-native team.
i didn't try to solve the issue to be honest since it is coming from the event emitter that is auto generated by codegen. and our app is an access control system and we cannot afford users crashing and not being able to access buildings so i had to revert back to react native old architecture and wait for a solution. And yeah the crash isn't because of startscan. the crash happens when the phone detects a ble peripheral and the library try to report back to the app through the event emitter. there is also another crash that happens, if you open the app and leave it still do not press any button for 50 60 seconds, the app will crash on it's own, also because of event emitter, something related to garbage collection
thank you for the patch, i will try it on monday and test it on our live devices that works and report back to you
@CaptainJeff i can confirm that the changes that you made fixed all the crashes that were happening, and is functioning as it should on all of our test devices,. as i understood, you reverted back to the way this library used to send events from native code to JS before TurboModules. but i don't understand why the library changed the way it handles the event emission, maybe it was a requirement by react native when switching to TurboModules. i wish someone from the library contributors would have answered or appeared active on this topic... Should i post on the react native issue thread, maybe someone can explain more about this crash and why it was solved by the change of methods? as much as i am happy about the fix, i am a little bit worried because if RN can't apply a proper fix, i will need to always make sure the libraries that we use and have event emitters will not cause the app to crash and maintain our version of the library code
@CaptainJeff i can confirm that the changes that you made fixed all the crashes that were happening, and is functioning as it should on all of our test devices,. as i understood, you reverted back to the way this library used to send events from native code to JS before TurboModules. but i don't understand why the library changed the way it handles the event emission, maybe it was a requirement by react native when switching to TurboModules. i wish someone from the library contributors would have answered or appeared active on this topic... Should i post on the react native issue thread, maybe someone can explain more about this crash and why it was solved by the change of methods? as much as i am happy about the fix, i am a little bit worried because if RN can't apply a proper fix, i will need to always make sure the libraries that we use and have event emitters will not cause the app to crash and maintain our version of the library code
The new library version no longer uses NativeEventEmitter, which I believe will be removed in the future. It seems that the codegen part is still invoking the old NativeEventEmitter for compatibility. I am pretty sure the problem is in the new architecture, the best thing is to use version 11.X until there is a fix.
@marcosinigaglia thank you for the clarification. For now this is what i am doing, for android i have an old architecture project. but for IOS i had to have a new architecture project so i am able to publish the app to the store, and it is started to getting complicated managing two solutions and migrating every feature to the other solution.
and i feel react native maintainers believe that the issue is with the library and not RN, and i do not know how to push them further more to investigate this issue since it is clear now that the cause of the crash is not the library itself but something related to new architecture. i opened an issue but it has gone inactive
The part of the code that handles events is very simple, it used to call the emitter or now passes through the code generated by codegen. If you can easily generate the exception try passing a default value to emitOnDiscoverPeripheral and see if that works. Perhaps it is something in the WritableMap that triggers the exception, from the stacktrace it is not clear.
The part of the code that handles events is very simple, it used to call the emitter or now passes through the code generated by codegen. If you can easily generate the exception try passing a default value to emitOnDiscoverPeripheral and see if that works. Perhaps it is something in the WritableMap that triggers the exception, from the stacktrace it is not clear.
ok i will try to debug it later on today. yeah the crash happens every time i start scanning on the A13 in samsung test lab, it never works. the mystery is that it only happens in release mode. if i run yarn run android the crash does not happen
Hi, I finally able to test using the samsung remote test lab. I used the example app and the latest expo without any issue. Probably something is wrong in your app and the new architecture is not set correctly.
Hi, I finally able to test using the samsung remote test lab. I used the example app and the latest expo without any issue. Probably something is wrong in your app and the new architecture is not set correctly.
is there any difference between expo and react-native-cli ?
also is this a release apk? because when i run it in debug mode yarn run android the app does not crash and behave normally
the crash only happens when i use a release apk cd android && gradlew assembleRelease then upload the apk to the device and install it, then i see the crash happens
It's a release with an apk. You can try the example project or try to use the same RN version and check if something is different. The expo result is not far from the react-native-cli but in my experience is more "solid".
It's a release with an apk. You can try the example project or try to use the same RN version and check if something is different. The expo result is not far from the react-native-cli but in my experience is more "solid".
i will need a bit of time to try to test expo/rn versions and see the issue from where it is generated. i am starting to feel it might be an environment setup issue.
@marcosinigaglia i tried today a build with expo using development build, and generated the signed apk following the steps mentioned by expo EAS to remove any doubt of an environment setup issue. i used a custom template to apply your library, because i was not able to build the example app.
i had a different behavior the app was scanning but i was not able to see any devices in the list. i am 100% sure that i applied onDiscoverPeripheral the same way you apply it in the example app. And on my personal phone the same apk with the same android version but different phone model, the app scans and display the devices. I am not sure if the app did not crash because the event emitter were not called for some reason. the adb logcat shows the library scanning successfully on the SM-A135
2025-03-07 12:54:46.164 2000 2169 D BtGatt.GattService onScanResult to scannerId: 4- eventType=0x1b, addressType=1, address=780E31_5, primaryPhy=1, secondaryPhy=0, advertisingSid=0xff, txPower=127, rssi=-60, periodicAdvInt=0x0
2025-03-07 12:54:46.170 2879 2894 I BluetoothAdapter BluetoothAdapter() : com.bletest
2025-03-07 12:54:46.172 2000 2169 D BtGatt.GattService onScanResult to scannerId: 4- eventType=0x10, addressType=1, address=19A3F2_A, primaryPhy=1, secondaryPhy=0, advertisingSid=0xff, txPower=127, rssi=-88, periodicAdvInt=0x0
2025-03-07 12:54:46.172 2879 2879 I RNBleManager DiscoverPeripheral: null
2025-03-07 12:54:46.183 2879 2879 I RNBleManager DiscoverPeripheral: null
2025-03-07 12:54:46.209 2000 2169 D BtGatt.GattService onScanResult to scannerId: 4- eventType=0x10, addressType=1, address=0E904F_4, primaryPhy=1, secondaryPhy=0, advertisingSid=0xff, txPower=127, rssi=-89, periodicAdvInt=0x0
2025-03-07 12:54:46.210 2879 2879 I RNBleManager DiscoverPeripheral: null
2025-03-07 12:54:46.211 2000 2169 D BtGatt.GattService onScanResult to scannerId: 4- eventType=0x10, addressType=1, address=4612AC_7, primaryPhy=1, secondaryPhy=0, advertisingSid=0xff, txPower=127, rssi=-71, periodicAdvInt=0x0
2025-03-07 12:54:46.218 2879 2879 I RNBleManager DiscoverPeripheral: null
2025-03-07 12:54:46.219 2000 2169 D BtGatt.GattService onScanResult to scannerId: 4- eventType=0x10, addressType=1, address=0851D2_0, primaryPhy=1, secondaryPhy=0, advertisingSid=0xff, txPower=127, rssi=-56, periodicAdvInt=0x0
2025-03-07 12:54:46.228 2879 2879 I RNBleManager DiscoverPeripheral: null
question 1: did you try the expo app on the SM-135 or SM-137?
question 2: i am building the rn cli app on a windows machine with node version 22.12.0, java version "17.0.12". should i change any of these versions?
question 3: i cloned the library repo using the github desktop app. then went to the library directory and then cd example && npm install. then i tried npx expo run:android. and i tried on another clean clone just running npx expo run:android but i get the same error:
is this the correct way to run the example app? or am i missing something?
@marcosinigaglia can you confirm please that you tried the signed apk on the SM-A135 or SM-A137?
@marcosinigaglia can you confirm please that you tried the signed apk on the SM-A135 or SM-A137?
Yes it was a SM-A135
Might be worth mentioning that I wasn't getting this crash for my app when I ran it on samsung remote test lab but purchased an SM-A135 and it happened on that.
As noted above this fixed the issue https://github.com/innoveit/react-native-ble-manager/issues/1336#issuecomment-2675886632
But really not sure why event emitters would only have issues with these particular devices
@CaptainJeff that is weird, for my build i am having constant crashes on test lab. after your fix and a build from cli, i stopped facing crashes on testlab, so we tried a production release with the fix we started receiving too many crash reports. the app crashes instantly, although we do not start scanning or subscribe to any event on app launch, and the component that start scanning is not even loaded yet. only we initialize the library on app start in a useeffect.
on expo build the app does not crash, but i am not seeing any devices reported to JS. the adb logs shows the library is scanning, somehow the event is failing to report back but not crashing the app. i doubt that i am doing something wrong, because it is not that complicated to use this library as i used it perfectly fine before the new RN architecture.
there is too many weird behaviors that i had to revert back to old architecture again just so users are able to use the app...
@marcosinigaglia can you share some insights how to solve the build errors with the example app?
@barakataboujreich run npm run build in the project's root before build the example.
@barakataboujreich really really strange.
Just to confirm. Before trying my fix was the app crashing instantly as well or was that introduced with my solution?
We have seen that same thing happen but i'm not sure if its related to this (it seemed to be happening prior to this patch but still on the new architecture). It seems to be happening on phones with really low memory available and seems to be a garbage collection error which I haven't been able to track down yet. But would be interesting if you only saw this happen once these changes were introduced.
I can't reproduce the instant crash even on my Galaxy a13 but do see users having the isseu based on crash logs
@barakataboujreich really really strange.
Just to confirm. Before trying my fix was the app crashing instantly as well or was that introduced with my solution?
We have seen that same thing happen but i'm not sure if its related to this (it seemed to be happening prior to this patch but still on the new architecture). It seems to be happening on phones with really low memory available and seems to be a garbage collection error which I haven't been able to track down yet. But would be interesting if you only saw this happen once these changes were introduced.
I can't reproduce the instant crash even on my Galaxy a13 but do see users having the isseu based on crash logs
Sorry i might not have been clear with my previous statement. The crash related to GC was always there before/after you introduced your solution.
I just wanted to imply that on app start i don't even subscribe to any event emitter or start scanning and according to the log the app crashes within 2 seconds.
@CaptainJeff if we make the changes you suggested in https://github.com/innoveit/react-native-ble-manager/issues/1336#issuecomment-2675886632 also remove from NativeBleManager.ts line 3 and line 202 to 212, codegen will not generate any code in NativeBleManagerSpec referencing setEventEmitterCallback since we do not need them anymore, i suspect we will have a temporary working solution for all the crashes even GC one.
@barakataboujreich
Yeah, I probably should have removed those references from NativeBleManager.
What is your approach for the GC crash? Or are you saying you think my fix and removing those lines will fix it?
@CaptainJeff yeah i suspect applying your fix and removing these lines will fix the GC crash, since the crash logs is pointing that GC destroyed something related to setEventEmitterCallback. and when i applied both changes i even solved this crash android 8 without upgrading to RN 78 or applying changes suggested by temp fix
Yeah interesting. I'm still at a loss for whats causing the GC crash. But definitely could be related to this. I'll test it out
@barakataboujreich damn. I didn't update ios to be compatible with this refactor yet. Have you tested on ios to see if the eventemitters done like this works?