[Bug] AnalyserNode returns zero data on Android 16 (Expo 55) while microphone is active

[418442040]

Description I am experiencing an issue where the AnalyserNode fails to capture any audio data on Android 16, specifically on a Redmi device. While the system's microphone privacy indicator is visible (confirming the mic is active), the frequency data buffer remains entirely filled with zeros.

This exact same code works perfectly on Android 12.

Environment

Framework: Expo 55 (React Native)

Library: react-native-audio-api

Device: Redmi (Xiaomi)

OS Version: Android 16 (API Level 36)

Permissions: RECORD_AUDIO is granted.

Steps to Reproduce

Initialize AudioContext and AnalyserNode.

Connect AudioRecorder to the AnalyserNode via createRecorderAdapter.

Start recording.

Call analyser.getByteFrequencyData(rawData).

Observed Behavior The rawData array is always [0, 0, 0, ...] and avgEnergy is always 0, even when there is loud input. The waveform remains flat.

Expected Behavior The AnalyserNode should provide real-time frequency data, matching the behavior on Android 12.

Code Snippet

TypeScript
const rawData = new Uint8Array(analyserRef.current.frequencyBinCount);
analyserRef.current.getByteFrequencyData(rawData);
// rawData is consistently [0, 0, 0...] on Android 16
Additional Context (Potential Causes)

Android 16 Foreground Service Policy: Does the library handle the new FOREGROUND_SERVICE_MICROPHONE requirements for API 34+ correctly?

AudioContext Lifecycle: On Android 16, does the AudioContext require a specific user-interaction trigger or a different sampleRate initialization?

Hardware-Specific: This was observed on a Redmi device; there might be a specific interaction with MIUI/HyperOS on the Android 16 base.

Is there any workaround or an updated configuration required for Android 16 support?

CloneVoice.tsx

[michalsek]

Hey, thanks for the report, we will check it as soon as possible

as for foreground service requirements, you can check how to setup them f.e. here:

• https://docs.swmansion.com/react-native-audio-api/docs/inputs/audio-recorder/#configuration

also for the FGS to work propely you have to show user-facing notification, you can use the api from here:
https://docs.swmansion.com/react-native-audio-api/docs/system/recording-notification-manager
(which also creates requirement for notification permission)

[418442040]

Hi @michalsek,

I found a workaround for the "zero data" issue on Android 16. It seems that on API 36, initializing the AudioContext without parameters leads to the empty buffer.

If I explicitly define the sampleRate, the AnalyserNode starts returning data:

TypeScript
const audioContext = new AudioContext({ sampleRate: 16000 }); // This works
However, there is a new inconsistency: Even with the same code, the data returned by getByteFrequencyData on Android 16 is significantly different from Android 12. The amplitude/energy levels feel scaled differently, which makes it very difficult to create a consistent visualizer/waveform animation that works across both versions.

Is there an internal change in how react-native-audio-api handles the gain or normalization on Android 16?

Should we be targeting a specific sampleRate to ensure consistent FFT results across devices?

Looking forward to your thoughts on this!

[poneciak57]

@418442040 you can try any power of 2 like 16384 (closest to 16k) if that would be the case. We will investigate that anyway

[michalsek]

@418442040 in your example, you are creating new AudioContext on each state change

const audioContextRef = useRef(new AudioContext());

which in result, tears down, and creates new audio stream on each loop of the draw method. Not sure why this behaves this way on android 16, while not on earlier versions.

But you can safely use AudioContext and AudioRecorder as a singletons inside the application, outside of typical reacts state lifecycle

[418442040]

Hi @michalsek @poneciak57 ,

Thanks for the insights!

Singleton Pattern: I've followed your advice to move AudioContext and AudioRecorder outside the component lifecycle as singletons. This significantly improved the stability on Android 16 and prevented the stream from tearing down during state changes.

Sample Rate: Explicitly setting the sampleRate (e.g., 16000) indeed fixed the "zero data" issue on API 36.

Consistency Issue: I am still observing that even with the same sampleRate and fftSize, the energy levels from getByteFrequencyData are noticeably different between Android 12 and 16. On Android 16, the data feels more "compressed" or has a different gain scaling.

Thanks again for the help!

[michalsek]

That is most likely due to the differences in the system implementation or even hardware differences, which i'm afraid we don't have any capability to change how we receive the raw data. You can try some min/max/avg scalling on top of the data received from the analyser node, although that heavly depends on your usecase :)

Closing this issue for now, if you have any more problems let us know! :)