After adding library with generated Java bindings the stacktraces are polluted with new symbols

[orestesgaolin]

It's quite unusual issue, but we've noticed it after adding library binded with jnigen.

Suddenly the non-symbolicated stacktraces in release started showing the method and class names from this library:

2025-03-05T12:30:59.918860Z E [BFSP] getFirmwareInfo failed
com.happitech.heartbeatandroid.o70: Connection lost during packet read
	at com.happitech.heartbeatandroid.j90.V(Unknown Source:55)
	at com.happitech.heartbeatandroid.j90.i0(Unknown Source:193)
	at com.happitech.heartbeatandroid.j90.X(Unknown Source:82)
	at com.happitech.heartbeatandroid.j90.P(Unknown Source:0)
	at com.happitech.heartbeatandroid.d90.a(Unknown Source:4)
	at com.happitech.heartbeatandroid.mj7.B(Unknown Source:10)
	at com.happitech.heartbeatandroid.hj7.a(Unknown Source:14)
	at com.happitech.heartbeatandroid.uj7.B(Unknown Source:9)
	at com.happitech.heartbeatandroid.hj7.a(Unknown Source:14)
	at com.happitech.heartbeatandroid.sj7.B(Unknown Source:9)
	at com.happitech.heartbeatandroid.hj7.a(Unknown Source:14)
	at com.happitech.heartbeatandroid.zk7$a.run(Unknown Source:2)
	at com.happitech.heartbeatandroid.c57$a.run(Unknown Source:9)
	at com.happitech.heartbeatandroid.a57.run(Unknown Source:13)
	at com.happitech.heartbeatandroid.a57.call(Unknown Source:0)
	at java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:307)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
	at java.lang.Thread.run(Thread.java:1012)

Normally this stacktrace would use other native library polar-ble-sdk. After symbolicating the stack it looks normally:

We observe similar situation in Crashlytics:

Flutter 3.27.4
jnigen 0.14.0

Config:

android_sdk_config:
  add_gradle_deps: true
  android_example: "example/"

classes:
  - kotlin.Unit
  - android.util.Size
  - com.makevisible.happitech.happitech_client.HeartMonitorInstance
  - com.happitech.heartbeatandroid.HeartListener
  - com.happitech.heartbeatandroid.HeartMonitor
  - com.happitech.heartbeatandroid.c
  - com.happitech.heartbeatandroid.Error
  - com.happitech.heartbeatandroid.FrequencyHRV
  - com.happitech.heartbeatandroid.HeartRate
  - com.happitech.heartbeatandroid.IBIData
  - com.happitech.heartbeatandroid.LicenseCheckStatus
  - com.happitech.heartbeatandroid.QualityRealTime
  - com.happitech.heartbeatandroid.Status
  - com.happitech.heartbeatandroid.TimeHRV
  - com.happitech.heartbeatandroid.Warning
  - com.happitech.heartbeatandroid.settings.PoincareGraphSettings
  - com.happitech.heartbeatandroid.settings.PPGGraphSettings
  - com.happitech.heartbeatandroid.settings.IBIGraphSettings
  - com.happitech.heartbeatandroid.SDKMode
  - com.happitech.heartbeatandroid.ClassificationResults
  - com.happitech.heartbeatandroid.ClassType

output:
  dart:
    path: "lib/android/android_hrvsdk.dart"
    structure: "single_file"

log_level: "all"

proguard rules section:

# Happitech SDK
-keep class com.makevisible.happitech.** { *; }
-keep class com.happitech.heartbeatandroid.* { *; }
-keep enum com.happitech.heartbeatandroid.wrapper.* { *; }
-keepclassmembers class com.happitech.heartbeatandroid.wrapper.* { *; }
-dontwarn kotlinx.android.parcel.Parcelize
-dontwarn kotlinx.parcelize.Parcelize

This Happitech SDK library is obfuscated aar.

[HosseinYousefi]

Is your issue the fact that you see com.happitech.heartbeatandroid in the stack trace but you don't want to?

In order for jnigen to be able to work at all, you'd need to not obfuscate the signatures because JNI uses reflections in runtime to find and call the methods. So I don't know if we can fix this issue.

[orestesgaolin]

Yes, I don't want the stacktraces to be "mismatched". At this point in time this library is not even initialized, we are certain it hasn't been used as it's behind feature flag. Nonetheless it appears in stacktraces.

We'll reach out to vendor to ask if they can provide non-obfuscated version. Btw the bindings still work with obfuscated library, does it mean it may break if the reflection misses the method?

[HosseinYousefi]

There might be a clinit for the library if the feature flag is in Dart. So the library might do some initialization works behind the scene even if you're not using it.

Btw the bindings still work with obfuscated library

It's the implementation that is obfuscated and not the interface exposed to you, so it shouldn't affect the user's workflow. Otherwise what's the point of the library if we don't even know what is the name of the method to call!