pub(crate) fn jni_guard<F: FnOnce()>(name: &str, body: F)Expand description
Run the body of a JNI callback with any panic contained.
Every extern "system" function in this file is called by the JVM on an
arbitrary thread. A panic that unwinds out of one crosses the FFI boundary,
which Rust answers by aborting the process — the app vanishes with no
Java exception, no stack trace attributable to it, and no crash report the
user can send. That is the worst possible failure mode for the callbacks
that fire four times a second during playback.
The panics are real, not theoretical: this file builds a fallback Tokio
runtime on threads that have none, and Runtime::new() fails under the fd
exhaustion and thread-spawn refusal an Android device puts a media app
through. Losing one position report is recoverable; losing the process is
not.
A contained panic still leaves whatever it interrupted half-done, so this is
a backstop, not a licence to panic. utils::lock already keeps a poisoned
mutex from cascading; this keeps the FFI boundary from turning any remaining
panic into a process kill.
TRACES: UR-005 | DR-052
Only called from player::android, which is cfg(target_os = "android"),
so it is dead code on every other target — the same reason
RESUME_BACKOFF_STEP_SECS carries this attribute. It is still compiled and
tested here on purpose.