https://livekit.io logo
Join Slack
Powered by
We are getting a SIGABRT issue [split_config.arm64...
# ask-ai
s
We are getting a SIGABRT issue [split_config.arm64_v8a.apk!libjingle_peerconnection_so.so] on some Android devices running Livekit React Native. All on the latest versions.
✅ 1
t
Thanks for reaching out, Sam. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I’m sorry you’re seeing SIGABRT crashes on Android. I want to get you back to stable builds as quickly as possible. To help narrow this down and offer targeted troubleshooting, can you share a few details? 1. Crash details • Can you paste the full native crash stacktrace (logcat) around the SIGABRT, including any thread names and the libc / tombstone output? • If you have an address or symbolicated stack from the .so, include that. 1. Environment • Exact LiveKit React Native package/version you’re using. • Android build target / NDK version and ABI(s) you’re shipping (is arm64_v8a the only one affected?). • React Native version and Gradle / Kotlin versions if relevant. 1. Devices & OS • Which device models and Android OS versions show the crash, and which do not (if you have that split)? • Is it limited to OEMs (e.g., Xiaomi, Samsung) or to specific Android API levels? 1. Reproduction • Does the crash happen consistently on a particular flow (joining a room, publishing a track, enabling screen share, background/foreground transitions)? • Steps to reproduce, and whether it happens in release vs debug builds or only when ProGuard / R8 is enabled. 1. Build configuration • Are you using any custom WebRTC/native flags, or building any native parts yourself (customizing 
libjingle_peerconnection_so
)? • ProGuard/R8 rules you’re applying (if minification/stripping differs) and whether you’re using split APKs (you mentioned 
split_config.arm64_v8a.apk
). 1. Temporary mitigations you’ve tried • Any workarounds you've already attempted (e.g., disabling hardware acceleration, forcing software codecs, changing audio/video constraints, adjusting thread priorities)? What I can do once you provide the above: • Analyze the native stacktrace to identify where the abort originates (e.g., assertion failure in WebRTC, JNI misuse, memory corruption). • Suggest targeted fixes or configuration changes (ProGuard rules, ABI packaging, build flags). • Provide steps to capture more useful native crash data (how to get a full tombstone / symbolicate .so) if needed. If you can paste the logcat/tombstone and the LiveKit RN version plus the exact reproduction steps, I’ll start with a focused analysis and recommended next steps. , with interactive elements
s
Copy code
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 7308 >>> <http://com.my.app|com.my.app> <<<

backtrace:
  #00  pc 0x000000000005d3d8  /apex/com.android.runtime/lib64/bionic/libc.so (abort+172)
  #01  pc 0x00000000004874f8  /data/app/~~g13qaB_MjNdawbGYuZ0XAw==/com.my.app-G4PaSDVyQHmx7saNLkWtpA==/split_config.arm64_v8a.apk!libjingle_peerconnection_so.so (BuildId: efbcc64c7abc4d17)
  #02  pc 0x0000000000487c6c  /data/app/~~g13qaB_MjNdawbGYuZ0XAw==/com.my.app-G4PaSDVyQHmx7saNLkWtpA==/split_config.arm64_v8a.apk!libjingle_peerconnection_so.so (BuildId: efbcc64c7abc4d17)
  #03  pc 0x0000000000486d70  /data/app/~~g13qaB_MjNdawbGYuZ0XAw==/com.my.app-G4PaSDVyQHmx7saNLkWtpA==/split_config.arm64_v8a.apk!libjingle_peerconnection_so.so (BuildId: efbcc64c7abc4d17)
  #04  pc 0x00000000005145f0  /data/app/~~g13qaB_MjNdawbGYuZ0XAw==/com.my.app-G4PaSDVyQHmx7saNLkWtpA==/split_config.arm64_v8a.apk!libjingle_peerconnection_so.so (BuildId: efbcc64c7abc4d17)
  #05  pc 0x000000000067978c  /data/app/~~g13qaB_MjNdawbGYuZ0XAw==/com.my.app-G4PaSDVyQHmx7saNLkWtpA==/split_config.arm64_v8a.apk!libjingle_peerconnection_so.so (BuildId: efbcc64c7abc4d17)
  #06  pc 0x00000000009db314  /data/app/~~g13qaB_MjNdawbGYuZ0XAw==/com.my.app-G4PaSDVyQHmx7saNLkWtpA==/split_config.arm64_v8a.apk!libjingle_peerconnection_so.so (BuildId: efbcc64c7abc4d17)
  #07  pc 0x00000000009d8c48  /data/app/~~g13qaB_MjNdawbGYuZ0XAw==/com.my.app-G4PaSDVyQHmx7saNLkWtpA==/split_config.arm64_v8a.apk!libjingle_peerconnection_so.so (BuildId: efbcc64c7abc4d17)
  #08  pc 0x00000000009d89dc  /data/app/~~g13qaB_MjNdawbGYuZ0XAw==/com.my.app-G4PaSDVyQHmx7saNLkWtpA==/split_config.arm64_v8a.apk!libjingle_peerconnection_so.so (BuildId: efbcc64c7abc4d17)
  #09  pc 0x00000000009e6b00  /data/app/~~g13qaB_MjNdawbGYuZ0XAw==/com.my.app-G4PaSDVyQHmx7saNLkWtpA==/split_config.arm64_v8a.apk!libjingle_peerconnection_so.so (BuildId: efbcc64c7abc4d17)
  #10  pc 0x0000000000a0f1d8  /data/app/~~g13qaB_MjNdawbGYuZ0XAw==/com.my.app-G4PaSDVyQHmx7saNLkWtpA==/split_config.arm64_v8a.apk!libjingle_peerconnection_so.so (BuildId: efbcc64c7abc4d17)
  #11  pc 0x0000000000a0efd4  /data/app/~~g13qaB_MjNdawbGYuZ0XAw==/com.my.app-G4PaSDVyQHmx7saNLkWtpA==/split_config.arm64_v8a.apk!libjingle_peerconnection_so.so (BuildId: efbcc64c7abc4d17)
  #12  pc 0x0000000000a0ffa4  /data/app/~~g13qaB_MjNdawbGYuZ0XAw==/com.my.app-G4PaSDVyQHmx7saNLkWtpA==/split_config.arm64_v8a.apk!libjingle_peerconnection_so.so (BuildId: efbcc64c7abc4d17)
  #13  pc 0x0000000000690900  /data/app/~~g13qaB_MjNdawbGYuZ0XAw==/com.my.app-G4PaSDVyQHmx7saNLkWtpA==/split_config.arm64_v8a.apk!libjingle_peerconnection_so.so (BuildId: efbcc64c7abc4d17)
  #14  pc 0x00000000004956ec  /data/app/~~g13qaB_MjNdawbGYuZ0XAw==/com.my.app-G4PaSDVyQHmx7saNLkWtpA==/split_config.arm64_v8a.apk!libjingle_peerconnection_so.so (BuildId: efbcc64c7abc4d17)
  #15  pc 0x00000000004955d8  /data/app/~~g13qaB_MjNdawbGYuZ0XAw==/com.my.app-G4PaSDVyQHmx7saNLkWtpA==/split_config.arm64_v8a.apk!libjingle_peerconnection_so.so (BuildId: efbcc64c7abc4d17)
  #16  pc 0x000000000006ee94  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+196)
  #17  pc 0x0000000000060fb0  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+68)
arm64_v8a is the only one affected. it appears to affect only Samsung devices. I have the following Proguard rule
Copy code
"extraProguardRules": "-keep class org.webrtc.** { *; }\n-keep class livekit.org.webrtc.** { *; }\n-keep class com.oney.WebRTCModule.** { *; }\n-keep class io.livekit.** { *; }"
Using versions: React Native 0.81.5 React 19.1.0 Expo 54.0.30 livekit-client: 2.17.2 livekit/react-native: 2.9.6 livekit/react-native-expo-plugin: 1.0.1 livekit/react-native-webrtc: 137.0.2 config-plugins/react-native-webrtc: 13.0.0 Crash tends to happen when susbcribing to new participants. We have sessions with >150 participants so do not auto-subscribe but trigger subscribe when they come into view after scrolling (debounced to prevent too much subscription churn). We disable camera streams for those not in view. We are not customising.
t
Acknowledged. Now craft the final customer-facing response per guidelines.Thanks — this is very helpful detail. I’m going to respond with targeted troubleshooting and next steps focused on the SIGABRT in 
libjingle_peerconnection_so.so
that happens when subscribing to participants (arm64_v8a, Samsung devices). Summary of what I’m addressing • SIGABRT inside 
libjingle_peerconnection_so.so
(native WebRTC) on arm64_v8a split APKs. • Crash occurs when subscribing to new participants (you use on-demand subscribe for >150 participants). • Affects only Samsung devices. • You’re on LiveKit RN 2.9.6 / livekit-client 2.17.2 / react-native-webrtc 137.0.2 and you’re not customizing native builds. • ProGuard rules provided. What to try next (prioritized, start from 1 and stop when you find improvement) 1. Capture a symbolicated native tombstone ◦ The backtrace shows only addresses in 
libjingle_peerconnection_so.so
. A symbolicated native stack will indicate the exact function or assertion that aborts (e.g., DCHECK failure, JNI misuse, memory corruption). If you can upload the matching 
.so
with BuildId efbcc64c7abc4d17 or provide the native debug symbols, we can map addresses to symbols. If you need instructions for extracting/symbolicating tombstones I can provide steps. 1. Test with the ARM64 ABI removed (quick diagnostic) ◦ Temporarily build and distribute only armeabi-v7a (or exclude arm64_v8a) to confirm the crash is ABI-specific. You said arm64_v8a is the only one affected — this will verify whether fallback ABI avoids the crash and help isolate it to the native lib for arm64. 1. Try a WebRTC / lib version matrix ◦ Although you’re on react-native-webrtc 137.0.2, native WebRTC builds vary by patch. If possible test with: ▪︎ a slightly older react-native-webrtc native binary (one minor version back) ▪︎ or a newer build (if available) ◦ If switching the WebRTC native binary changes the crash frequency, that implicates that native library build. 1. Disable aggressive subscription churn / stagger subscriptions further ◦ Since the crash happens when subscribing to participants, try adding a longer debounce/serializing subscription path (subscribe to one participant at a time, spaced by 100–300 ms) as a mitigation. This narrows whether concurrent subscription operations / thread contention expose the bug. ◦ Also try subscribing in the background thread vs main thread if your current flow uses the main thread. 1. Reproduce on-device with minimal app ◦ Create a small test that reproduces the subscribe pattern (many participants, on-demand subscribe when scrolled into view) to confirm it’s reproducible locally or on a reproducible Samsung device. This helps rule out app-specific state. 1. Check ProGuard/R8 / packaging rules ◦ Your rules look good for keeping WebRTC/LiveKit classes. However, minification can affect JNI class lookups if some classes are renamed and the native side expects certain names. For a test: ▪︎ Run a non-minified build (disable R8/ProGuard) and see if crash persists. ▪︎ Ensure packaging doesn’t strip native symbols: confirm split APK packaging preserves the correct .so for arm64_v8a. You mentioned `split_config.arm64_v8a.apk`; make sure Play Store split installation is not accidentally mixing ABIs. 1. Test hardware/software codec differences and hardware acceleration ◦ On Samsung devices sometimes vendor-specific hardware decoders/encoders cause native crashes. Try forcing software codecs (if configurable) or disable hardware acceleration for video to see if the crash goes away. 1. Monitor memory / resource constraints ◦ With large sessions, device memory or native resource exhaustion can lead to aborts. Monitor native heap / GPU memory when subscribing to many participants. If RAM/FDs spike before the crash, that’s a clue. 1. Look for OEM-specific issues ◦ Since it’s limited to Samsung, test across multiple Samsung models and Android versions to see if a pattern appears (e.g., One UI version or Exynos vs Snapdragon). If it’s a narrow set, it may be a vendor WebRTC binary incompatibility. Information that will let me be more specific • A symbolicated native stack (or the .so / debug symbols) so I can see the exact function failing. • Whether disabling R8/ProGuard removes the crash. • Whether forcing software codecs or excluding arm64_v8a changes behavior. • A reproducible minimal test case or steps that reliably trigger the crash on a Samsung test device. If you want, I can provide: • Exact adb/logcat commands and steps to capture a full tombstone and how to symbolicate with the 
.so
. • A small patch example to serialize/sub-sample subscriptions for testing. • ProGuard/R8 debug configuration suggestions to ensure JNI names are preserved. Next step for you • If you can paste a symbolicated native stack or tell me the result of one quick test (disable R8 or run only armeabi-v7a), I’ll provide the most direct suggestion (and a follow-up plan) based on that result., with interactive elements
Open in Slack
PreviousNext
Powered by