@siteed/moonshine.rn: minSdkVersion hardcoded to 35 in build.gradle prevents use below Android 15

[AlexanderBaert79]

The wrapper's android/build.gradle contains:

minSdkVersion Math.max((getExtOrDefault('minSdkVersion', 35) as Integer), 35)

The Math.max against a hardcoded 35 means the effective floor is always 35 regardless of what the host project declares or which AAR version is used.

This is relevant because the Moonshine AAR itself recently had its minSdk corrected from 35 to 26 (moonshine-ai/moonshine#197). The wrapper now sets a higher floor than the AAR it wraps.

A fix would be changing the default and the floor to 23 or 26, for example:

minSdkVersion Math.max((getExtOrDefault('minSdkVersion', 23) as Integer), 23)

Our use case is a React Native 0.73 app targeting API 23 and above. Happy to test a fix.

Cheers,
Alex

[abretonc7s]

Thanks for the report @AlexanderBaert79, and sorry for the outcome — we are staying on minSdkVersion 35 for now.

Your diagnosis was right about the wrapper: the Math.max(..., 35) floor did make 35 unavoidable. But fixing it turned out to be blocked by upstream, not by us.

I tested every published Maven version of ai.moonshine:moonshine-voice. No version offers both minSdk 26 and an API this wrapper can compile against:

version	minSdk	compiles?	what breaks
0.0.59 (what we ship)	35	yes	—
0.0.61 – 0.0.65	35	no	JNI signatures changed
0.0.67 – 0.0.73	26	no	+ TranscriptLine speaker fields removed
0.1.0 – 0.1.3	26	no	+ intent recognition removed, embedding API made package-private

The AAR you found at minSdk 26 is real, but every version carrying it also drops APIs we depend on. 0.0.67 removes speaker-ID fields; 0.1.x removes intent recognition entirely and closes off the embedding primitives (EmbeddingModel and the embedding JNI methods are package-private), so it cannot even be reimplemented without adopting upstream's new AgentFlow API — which owns the microphone, TTS, and dialog state, far beyond what this wrapper does.

I did get a source-built AAR working at minSdk 26 and verified it loads on an API 26 emulator (dlopen with RTLD_NOW, all three .so files, zero symbols requiring >26). So the native code genuinely is fine at 26 — the blocker is purely the Java API surface. Shipping that patched AAR in the npm package would work but adds ~29MB and makes us the distributor of a modified upstream binary, which is not a trade we want to make for one request.

If you need this, the realistic paths are:

1. Build the AAR yourself from source and point at it via SITEED_MOONSHINE_ANDROID_AAR — the wrapper supports that override today, and the floor is now configurable via SITEED_MOONSHINE_ANDROID_MIN_SDK in the work I did here.
2. Ask upstream (moonshine-ai/moonshine) to keep the intent and speaker APIs available in 0.1.x, which would unblock a clean bump for everyone.

Closing as won't-fix for now. Happy to reopen if the upstream API realigns or if more people hit this — the investigation is written up in #435 so the next attempt does not start from scratch.