[Android] OOM Issue - Out of memory issue : 'JNI ERROR (app bug): global reference table overflow (max=51200)global reference table dump

Start with lib/http/HttpClient_Android.cpp and the SendRequestAsync entry point mentioned in the report; inspect the lifecycle of JNI references created for asynchronous callbacks. Use the attached crash logs and the reported telemetry workload to trace whether references remain after completion. Done means the overflow is no longer reproducible and the reference lifecycle is covered by an appropriate validation.

Describe your environment. Describe any aspect of your environment relevant to the problem, including your SDK version, platform, OS version, etc. If you're reporting a problem with a specific version of a library in this repo, please check whether the problem has been fixed on main brach.
Latest OneDS Android SDK

I am encountering a OOM issue consistently due to the below reason.
10-08 07:25:25.793 15234 15234 F DEBUG : Abort message: 'JNI ERROR (app bug): global reference table overflow (max=51200)global reference table dump:

Looks like the global reference limit is reached. I am suspecting some memory leaks. I could find a android related file
https://github.com/microsoft/cpp_client_telemetry/blob/main/lib/http/HttpClient_Android.cpp

Not a cpp expert. Could you help in checking some possibility where the global references are not released.
Logs can be found in this bug
https://domoreexp.visualstudio.com/MSTeams/_workitems/edit/4865741

Stacktrace:
10-08 07:25:25.015 11797 15029 F libc : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 15029 (Pool-Telemetry-), pid 11797 (skype.teams.dev)
10-08 07:25:25.793 15234 15234 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-08 07:25:25.793 15234 15234 F DEBUG : Build fingerprint: 'google/caiman_beta/caiman:16/BP41.250822.010/14082742:user/release-keys'
10-08 07:25:25.793 15234 15234 F DEBUG : Kernel Release: '6.1.141-android14-11-g4e52994af56a-ab13829026'
10-08 07:25:25.793 15234 15234 F DEBUG : Revision: 'MP1.0'
10-08 07:25:25.793 15234 15234 F DEBUG : ABI: 'arm64'
10-08 07:25:25.793 15234 15234 F DEBUG : Timestamp: 2025-10-08 07:25:25.394069110+0530
10-08 07:25:25.793 15234 15234 F DEBUG : Process uptime: 406s
10-08 07:25:25.793 15234 15234 F DEBUG : Executable: /system/bin/app_process64
10-08 07:25:25.793 15234 15234 F DEBUG : Cmdline: com.microsoft.skype.teams.dev
10-08 07:25:25.793 15234 15234 F DEBUG : pid: 11797, tid: 15029, name: Pool-Telemetry- >>> com.microsoft.skype.teams.dev <<<
10-08 07:25:25.793 15234 15234 F DEBUG : uid: 1010301
10-08 07:25:25.793 15234 15234 F DEBUG : tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
10-08 07:25:25.793 15234 15234 F DEBUG : pac_enabled_keys: 000000000000000f (PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY)
10-08 07:25:25.793 15234 15234 F DEBUG : esr: 0000000092000006 (Data Abort Exception 0x24)
10-08 07:25:25.793 15234 15234 F DEBUG : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
10-08 07:25:25.793 15234 15234 F DEBUG : Abort message: 'JNI ERROR (app bug): global reference table overflow (max=51200)global reference table dump:

This is a JNI Global Reference Table Overflow - a critical memory leak in native code!
Root Cause
The Culprit: libmaesdk.so - Microsoft's telemetry SDK
The Bug: HttpClient_Android::SendRequestAsync() creates JNI global references but never deletes them
The Leak: Each telemetry event creates a HttpClient$FutureShim object with a global ref that never gets cleaned up
The Result: After ~50,000 telemetry events (7 minutes of runtime), the global reference table hits the hard limit of 51,200 and the system aborts
The leak happens because of a missing cleanup step in async JNI code:
Leak Sequence: (step 5 missing?)

App logs telemetry event → logger.logEvent()
Java calls native code → nativeLogEventProperties()
Native creates global ref → NewGlobalRef(futureShim)
Async HTTP completes → Uses global ref for callback
Cleanup step MISSING → Should call DeleteGlobalRef()

Also could see ~3 OOM crash traces mostly a side effect of above memory leak.

4865741_Splash.txt
logs (1) (1).txt
logs (1).txt