Android: audio focus listener posts to a dead looper after JS reload, interruptions (calls) are missed
Los mantenedores suelen responder en 2 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 76/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- android, kotlin, react-native
- Área
- audio-video-rtc, mobile
Línea de trabajo
Localiza la implementación de Android de AudioFocusListener.requestAudioFocus e inspecciona cómo se registra su listener de cambios de foco de audio. Empieza siguiendo el constructor de la solicitud y la ruta del callback a través de callInvoker; verifica que los cambios de foco sigan generando eventos de interrupción después de una recarga de JS. Se considera terminado cuando el listener usa un looper activo y el escenario de llamada reportado ya no pierde el evento.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Description
On Android, AudioManager.observeAudioInterruptions(true) stops delivering interruption events after a JS reload: focus changes reach the app process but are posted to a dead looper.
W MessageQueue: java.lang.IllegalStateException: Handler (android.media.AudioManager$ServiceEventHandlerDelegate$1) {…} sending message to a Handler on a dead thread
W MessageQueue: at android.media.AudioManager$1.dispatchAudioFocusChange(AudioManager.java:4370)
In our case an incoming phone call (and a WhatsApp call) during a recording was not detected: no began event, the recorder kept running and wrote silence.
Cause
AudioFocusListener.requestAudioFocus builds the request with setOnAudioFocusChangeListener(this) and no handler. Android then dispatches callbacks on the looper of the thread that created the process-wide AudioManager (ServiceEventHandlerDelegate(null) uses Looper.myLooper()), here the JS thread. After a reload that thread is gone, so every later focus change is dropped.
Steps to reproduce
- Dev build, call
AudioManager.observeAudioInterruptions(true)and start anAudioRecorder. - Reload JS (dev menu or Fast Refresh full reload), start recording again.
- Call the device. No
interruptionevent; logcat shows the exception above. After a cold start, the same call is detected (onAudioFocusChange: -2within ~20 ms).
Suggested fix
Pass the main looper explicitly:
AudioFocusRequest
.Builder(focus)
.setOnAudioFocusChangeListener(this, Handler(Looper.getMainLooper()))
.build()
Events still reach JS through callInvoker, so dispatching from the main thread is safe. We ship this as a local patch and can open a PR if useful.
Related suggestion: the began payload does not say whether the loss is transient (AUDIOFOCUS_LOSS_TRANSIENT, e.g. a call or ringtone, followed by a gain) or permanent (AUDIOFOCUS_LOSS). Apps that should not offer "resume" while a call holds the mic need that distinction; we currently report it through shouldResume: true on transient began.
Environment
- react-native-audio-api 0.13.6, React Native 0.88 (new architecture, bridgeless), Expo SDK 58 dev client
- Samsung Galaxy A05 (SM-A055F), Android 14
- Lenguaje dominante
- C++
- Estrellas
- 851
- Forks
- 97
- Merge medio
- 4 d 5 h
- PR fusionados (30 d)
- 27
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de software-mansion/react-native-audio-api
-
android bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
software-mansion/react-native-audio-api#1273 · 5 comentarios ·
Los mantenedores suelen responder en 2 días
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
software-mansion/react-native-audio-api#1238 ·
Los mantenedores suelen responder en 2 días
-
Option to build without recording on iOS, so playback-only apps don't need NSMicrophoneUsageDescriptionPosiblemente ocupada @maciejmakowski2003 la tomó hace 8 días. Abiertoios
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
software-mansion/react-native-audio-api#1350 ·
Los mantenedores suelen responder en 2 días
-
ios
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
software-mansion/react-native-audio-api#1340 · 2 comentarios ·
Los mantenedores suelen responder en 2 días
-
ConvolverNode: SIGSEGV in Convolver::process caused by a race in ThreadPool::wait()Posiblemente ocupada @mdydek la tomó hace 3 días. Abiertobug
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
software-mansion/react-native-audio-api#1339 ·
Los mantenedores suelen responder en 2 días
Todos los issues de software-mansion/react-native-audio-api
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
OpenSpace/OpenSpace#4353 · 1 comentario ·
Los mantenedores suelen responder en 5 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
macOS: a double-click on a notarized altairsim is refused, and the docs give only the offline casePosiblemente ocupada @anhaoXie la tomó hoy. Abiertodocumentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
mutationpp/Mutationpp#337 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
bulletphysics/bullet3#4819 ·