feat(android): initialise Oboe runtime context

crates/chanora_bridge/Cargo.toml

@@ -28,7 +28,7 @@ tokio = { version = "1", features = ["rt-multi-thread", "macros"] }
 
 # Android: route `tracing` output to logcat so a user can see protocol
 # and audio diagnostics via `adb logcat -s chanora`. Also brings in the
-# JNI bindings we need to initialise `ndk_context` for cpal-on-Oboe.
+# JNI bindings we need to initialise `ndk_context` for the Android Oboe backend.
 [target.'cfg(target_os = "android")'.dependencies]
 tracing-android = "0.2"
 log = "0.4"

crates/chanora_bridge/src/android_init.rs

@@ -1,7 +1,7 @@
 //! Android-specific JNI lifecycle helpers.
 //!
 //! On Android the Flutter engine starts our cdylib but does not push
-//! anything into `ndk_context` (the global the cpal-on-Oboe backend
+//! anything into `ndk_context` (the global the Android Oboe backend
 //! reads to find Android audio services). Without that, the first
 //! audio call hangs / fails.
 //!
@@ -14,7 +14,8 @@
 //!    application Context. That JNI function pushes both the
 //!    `JavaVM*` and a `Context` global ref into `ndk_context`.
 //!
-//! After that, cpal can open the default input/output devices.
+//! After that, the Android Oboe backend can open the default
+//! input/output devices.
 
 #![cfg(target_os = "android")]
 
@@ -46,7 +47,7 @@ pub extern "system" fn JNI_OnLoad(
 }
 
 /// Called by `MainActivity.onCreate` with the application Context.
-/// Initialises the `ndk_context` so cpal's Oboe backend can locate
+/// Initialises the `ndk_context` so the Oboe backend can locate
 /// the Android audio services.
 ///
 /// Symbol mangling note: Kotlin / JNI mangles the underscore in