Firebase AI Live API on Android leaks/accumulates Firebase Audio threads on rk3588

[jackleeforce]

Environment

• Firebase AI Logic SDK:
  • Reproduced on 17.8.0
  • Reproduced on 17.10.1
• Backend: GoogleAI / Gemini Developer API
• Model: gemini-2.5-flash-native-audio-preview-12-2025
• Android device with issue:
  • Model: rk3588
  • Android version: 12
  • API level: 32
• Comparison device:
  • Google Pixel 8 Pro
  • Behavior is noticeably more stable there
• App type:
  • Reproduced in a minimal single-activity Android app with only:
    • Connect
    • Disconnect
    • Simulate goAway
• Audio mode:
  • LiveSession.startAudioConversation(...)

Problem Summary

On rk3588, Firebase Live audio threads are not reliably released across disconnect/reconnect cycles.

Depending on timing and reconnect path, we observe one or more of these behaviors:

1. old Firebase Audio / Firebase Blocki threads remain alive after disconnect
2. reconnect partially reuses old threads but also creates new ones
3. repeated reconnects, especially after goAway, cause thread count and CPU usage to keep increasing over time
4. after running for hours, the process becomes unstable and eventually crashes

This is reproducible both:

• in our production app
• in a minimal standalone test app

So this does not appear to be caused by app-specific business logic.

Minimal Reproduction

We built a minimal Android app that only does the following:

• create a LiveSession
• call startAudioConversation()
• disconnect using one of:
  • stopAudioConversation() + close()
  • close()
  • stopAudioConversation() + delay + close()
• reconnect again

We also tested goAway handling in 17.10.1 in two ways:

1. stop audio and restart on the same session
2. stop audio -> delay -> close old session -> connect new session -> start audio

Reproduction Steps

Case A: Manual connect / disconnect / reconnect

1. Launch app
2. Tap Connect
3. Wait until audio conversation is active
4. Tap Disconnect
5. Tap Connect again, either immediately or after some delay

Case B: goAway / reconnect path

1. Launch app and connect
2. Wait for server goAway or simulate the same handling path
3. Reconnect / restart audio according to app logic
4. Observe thread list and CPU

Observed Behavior

On rk3588, after disconnect/reconnect cycles we repeatedly observe leftover threads like:

• Firebase Audio
• Firebase Blocki

Typical symptoms:

• after one connection, we see a pair/group of Firebase threads
• after disconnect, those threads often remain alive
• after reconnect, sometimes the old threads are reused, but often new Firebase Audio threads are also created
• repeated reconnects gradually increase thread count and CPU
• some Firebase Audio threads remain at very high CPU for long periods

Example from a long-running production session on rk3588

• process thread count grew to about 129
• process RSS was around 348 MB
• peak RSS was around 433 MB
• many historical Firebase Audio threads remained alive simultaneously
• multiple Firebase Audio threads each consumed significant CPU

Example from the minimal app on rk3588

• baseline: about 22-24 threads
• connected: about 38-39 threads
• after reconnect cycles: thread count rose into the low 40s
• old Firebase threads remained, and new Firebase threads were added

Example behavior on Pixel 8 Pro

On Pixel 8 Pro, reconnect behavior is noticeably more stable:

• fewer long-lived leftover Firebase threads
• reconnect often appears to reuse existing internal threads
• thread count does not grow as aggressively

Expected Behavior

One of these should happen consistently:

1. after disconnect, Firebase Live audio threads should be fully cleaned up
2. or reconnect should safely reuse the same internal audio threads without thread count growth
3. but it should not keep accumulating Firebase Audio / Firebase Blocki threads over time

What We Tried

We tested all of the following:

• close() only
• stopAudioConversation() then close()
• stopAudioConversation() then wait then close()
• goAway -> stop audio -> restart audio on same session
• goAway -> stop audio -> close old session -> connect new session -> start audio

None of them fully solved thread accumulation on rk3588.

Suggested Investigation Areas

This may be related to:

• device-specific audio stack / HAL behavior on rk3588
• Firebase Live audio worker lifecycle
• incomplete cleanup of internal audio/network scopes after disconnect or reconnect
• interaction between goAway, audio shutdown, and reconnect timing

Request

Could you please investigate whether:

• LiveSession.close() / stopAudioConversation() are expected to fully terminate all internal Firebase audio threads
• thread retention on certain Android devices, especially rk3588-based devices, is a known issue
• there is a recommended reconnect pattern for goAway that avoids accumulating Firebase Audio threads

[lehcar09]

Hi @jackleeforce, thank you for raising this issue. I was able to reproduce the issue where startAudioConversation thread accumulates.

I'll raise this to our engineers for further investigation.

As for the thread retention in rk3588-based devices, we haven't received reports that specifically mentions threading issue for this device. Can you share the k3588-based device you're using?

As for the recommended reconnect pattern, the Firebase AI Logic - Live API, does not support yet some aspects of session management, including resuming a session across multiple connections, extending the session length, or compressing the context window.

Though, you can utilize going away notifications to:

• Inform the user of the impending disconnection if necessary.
• Stop sending new heavy data (like continuous audio/video) as the cutoff approaches.
• Save any critical local state.

[jackleeforce]

hi @lehcar09

Thanks for reproducing and escalating this.
Here are the rk3588 device details we use:

• Device model: rk3588
• Board platform: rk3588
• Hardware: rk30board
• Android version / API level: Android 12 / API 32
• Build fingerprint: Robint/robint_hotel/robint_hotel:12/SQ3A.220705.003.A1/eng.robint.20250806.173814:userdebug/release-keys
• Kernel version: 5.10.110

if any more infos needed, feel free to let me know.

As described in the issue, we can reproduce the thread accumulation with firebase-ai 17.10.1 in a minimal app as well.
One more context on our use case: we are building an always-on voice interaction robot that runs continuously for long periods.
So when we receive a goAway notification, our intended behavior is to proactively:

1. stop audio conversation,
2. close the current session,
3. create a new session, and
4. start audio conversation again.

In other words, we treat goAway as an expected lifecycle event and perform controlled session rollover to keep the robot online.
If helpful, we can provide additional adb-based measurements or rerun specific scenarios you want us to validate

[lehcar09]

Thank you for that info @jackleeforce. It’s highly appreciated if you can also share your ADB measurements and an MCVE/ code snippet for additional details.

[jackleeforce]

Hi @lehcar09 ，thanks for your attention.

I ran the minimal repro on an rk3588 device and captured runtime metrics with the monitor script.
Minimal repro project:

• Repo: https://github.com/jackleeforce/AICatalog
• Application ID: com.android.ai.catalog
• After cloning, please place google-services.json into the app/ directory.
  Repro steps:

1. Connect Android device via ADB.
2. Run monitor script:
   sh ./scripts/adb_live_resource_monitor.sh
3. Open AICatalog.
4. Tap Connect.
5. Tap Simulate goAway repeatedly to trigger goAway -> disconnect -> reconnect.

Raw monitor output from the rk3588 run (verbatim):

$ sh ./scripts/adb_live_resource_monitor.sh
Output directory: diag_output/adb_monitor_20260324_144857
Press Ctrl+C to stop.
[2026-03-24 14:48:57] sample=1 pid=6870 threads=26 rss=192116kB hwm=194744kB audio=0 block=0 top_cpu=0
[2026-03-24 14:48:59] sample=2 pid=6870 threads=28 rss=200036kB hwm=200060kB audio=0 block=0 top_cpu=0
[2026-03-24 14:49:02] sample=3 pid=6870 threads=39 rss=206340kB hwm=206340kB audio=2 block=2 top_cpu=100
[2026-03-24 14:49:05] sample=4 pid=6870 threads=39 rss=209328kB hwm=210716kB audio=2 block=2 top_cpu=103
[2026-03-24 14:49:07] sample=5 pid=6870 threads=40 rss=211500kB hwm=213828kB audio=2 block=2 top_cpu=103
[2026-03-24 14:49:10] sample=6 pid=6870 threads=39 rss=214172kB hwm=215828kB audio=2 block=2 top_cpu=100
[2026-03-24 14:49:12] sample=7 pid=6870 threads=42 rss=215816kB hwm=216180kB audio=3 block=2 top_cpu=103
[2026-03-24 14:49:15] sample=8 pid=6870 threads=41 rss=217488kB hwm=221064kB audio=3 block=2 top_cpu=100
[2026-03-24 14:49:18] sample=9 pid=6870 threads=45 rss=220472kB hwm=221064kB audio=4 block=3 top_cpu=103
[2026-03-24 14:49:20] sample=10 pid=6870 threads=45 rss=205912kB hwm=221228kB audio=4 block=3 top_cpu=100
[2026-03-24 14:49:23] sample=11 pid=6870 threads=45 rss=207268kB hwm=221228kB audio=4 block=3 top_cpu=103
[2026-03-24 14:49:26] sample=12 pid=6870 threads=44 rss=207200kB hwm=221228kB audio=4 block=3 top_cpu=100
[2026-03-24 14:49:28] sample=13 pid=6870 threads=47 rss=206356kB hwm=221228kB audio=5 block=3 top_cpu=103
[2026-03-24 14:49:31] sample=14 pid=6870 threads=45 rss=206144kB hwm=221228kB audio=5 block=3 top_cpu=100
[2026-03-24 14:49:34] sample=15 pid=6870 threads=49 rss=207968kB hwm=221228kB audio=6 block=3 top_cpu=100
[2026-03-24 14:49:37] sample=16 pid=6870 threads=49 rss=207212kB hwm=221228kB audio=6 block=3 top_cpu=103
[2026-03-24 14:49:40] sample=17 pid=6870 threads=49 rss=206920kB hwm=221228kB audio=6 block=3 top_cpu=117
[2026-03-24 14:49:43] sample=18 pid=6870 threads=53 rss=210168kB hwm=221228kB audio=7 block=3 top_cpu=143
[2026-03-24 14:49:47] sample=19 pid=6870 threads=53 rss=209212kB hwm=221228kB audio=7 block=3 top_cpu=155
[2026-03-24 14:49:51] sample=20 pid=6870 threads=53 rss=208024kB hwm=221228kB audio=7 block=3 top_cpu=165
[2026-03-24 14:49:55] sample=21 pid=6870 threads=56 rss=210308kB hwm=221228kB audio=8 block=3 top_cpu=101
[2026-03-24 14:50:00] sample=22 pid=6870 threads=56 rss=211184kB hwm=221228kB audio=8 block=3 top_cpu=77.7
[2026-03-24 14:50:05] sample=23 pid=6870 threads=54 rss=213048kB hwm=221228kB audio=8 block=3 top_cpu=202
[2026-03-24 14:50:10] sample=24 pid=6870 threads=53 rss=209332kB hwm=221228kB audio=8 block=3 top_cpu=113
[2026-03-24 14:50:14] sample=25 pid=6870 threads=52 rss=212152kB hwm=221228kB audio=8 block=3 top_cpu=48.7

From this run, thread accumulation is observable during repeated goAway reconnect cycles:
- audio grows from 0 to 8
- block grows from 0 to 3
- total thread count grows from 26 to 52+
- top Firebase thread CPU spikes above 100% and peaks at 202%

[lehcar09]

Hey @jackleeforce, our engineers have created the PR #8030 which is a potential fix for this issue. Can you help us verify this fix for rk3588 devices? Currently, we don’t have access to this type of device.

To test them, you would need to generate the artifacts. You can check this command section from our SDK ReadMe. Let me know if there’s anything I can help you with.