tts-rs

• minSdkVersion 26 or above. The UtteranceProgressListener subclass Android callbacks need ships as an embedded dex, loaded with InMemoryDexClassLoader.
• A Context supplied before the first Tts, one of two ways. ndk-context is consulted by default; android-activity publishes there for you, including by way of winit or a game engine. Or call tts::android::set_context with a JavaVM and Context of your choosing — it takes precedence over ndk-context and is the right entry point when the process outlives its Activity or never has one, such as speech from a foreground service: ndk-context's slot is typically owned by the Activity's glue and released when it's destroyed, while set_context holds its own reference for as long as backends need it. Either way the supplied context is traded for its application context, so no Activity is pinned.

Nothing here waits for the engine. Android reports it ready on the app's Java main thread, so a backend that blocked for that would deadlock any app whose main thread is itself waiting on the caller — which is every NativeActivity app, since android-activity holds the main thread until the event loop acknowledges each lifecycle callback. Tts::default() therefore returns as soon as the engine has been asked to connect, and anything spoken before it answers is queued and replayed in order. The one exception is synthesize, which returns audio and so has to wait for it; call that off your event-loop thread.

See examples/android_hello_world.rs, built with cargo-apk:

cargo apk run --example android_hello_world
adb logcat -s tts

Editing android/Bridge.java needs a JDK and ANDROID_HOME; build.rs rebuilds the checked-in dex from it.