Compatibility

Compatibility

“Generated” means the Python tool can create files. It does not imply that the parent Android project compiled, PluginHost loaded the result, or a particular device executed it.

This Wiki follows the default branch and may include unreleased changes. Check supernote-module --version and the repository changelog when diagnosing an installed release.

Development tools

Component	Status	Enforcement or evidence
Python	Required: 3.9+	Package metadata; CI covers 3.9–3.13
React Native	Official Supernote template: 0.79.2	Generated Gradle reads the parent version but does not reject another one
Node.js	Official recommendation: current LTS, at least 18	Doctor verifies availability, not an end-to-end install
npm	Supported; no version pinned	Availability checked; real plugin linking is not in CI
Yarn	Supported; no version pinned	Availability checked; modern Yarn variants are not qualified
Java/JDK	Generated target 17; Doctor accepts 17+	Official Supernote environment currently recommends JDK 19+; real template interaction remains unqualified
Android SDK	Required: platform 35; official guide also requests Build-Tools 35.0.0	Doctor checks android-35/android.jar, not Build-Tools
Minimum Android API	Generated modules use API 27	Template constant, not a device-support promise
Android NDK	JNI/JSI: Clang accepting C23/C++23 for API 27 arm64	Doctor runs compiler probes; no revision pinned
CMake	JNI/JSI: 3.22.1+	Generated build and Doctor enforce it
ABI	JNI/JSI: arm64-v8a	Generated Gradle filters to arm64

Use Supernote's Environment Setup for the parent project, then run:

supernote-module doctor --type native
supernote-module doctor --type jni
supernote-module doctor --type jsi

Host operating systems

Host	Status
Linux	Python suite runs in GitHub Actions on 3.9–3.13; this is not Android packaging proof
macOS	Python suite and installed-wheel generation smoke passed in the 2026-08-01 review; complete .snplg build was not run
Windows	Code has PowerShell and gradlew.bat branches; CI has no Windows job, so support is expected rather than qualified
Paths with spaces	Generator source checkout works with spaces; a target plugin root with spaces remains unqualified
Non-ASCII paths	Not covered; use an ASCII plugin path until qualified

Supernote devices and module status

No official per-device or firmware matrix exists for this generator.

Capability	Generation	Repository build proof	Device/runtime status
Kotlin/Java	Implemented	Generated shape and KSP source unit-tested; no official-template package in CI	Matches official Java/TurboModule capability; no per-device qualification published
Kotlin/Java + JNI	Implemented	Bindings unit-tested; no official-template Android/package build in CI	Matches official Java-to-C/C++ route; exact host still requires testing
Synchronous JSI	Implemented	Loader/bindings unit-tested; no official-template build in CI	Host-, firmware-, linker-, and SELinux-dependent; blocked on the tested enforcing retail configuration

JSI support gates

1. Generation: package, HostFunctions, loader, declarations, and autolinking.
2. Compilation: parent project resolves compatible headers/libraries and builds the .so.
3. Execution: PluginHost loads the library and SELinux permits execution from the extracted plugin directory.

The first gate is implemented here. The second is absent from repository CI. For the third, maintainer testing on 2026-07-30 used PluginHost 1.00.26005190, React Native 0.79.2, arm64, on two Nomad configurations. The generated loading pattern ran on userdebug/permissive firmware, while enforcing retail firmware denied the extracted .so with dlopen ... Permission denied and an SELinux { execute } denial. Both lacked the required permission; permissive mode bypassed enforcement.

Do not treat permissive success as retail support. Re-test the exact firmware, PluginHost, and enforcing policy before changing this status.

What is not yet proved in CI

The Python suite does not currently:

• install a real npm/Yarn Supernote fixture;
• compile all three generated backends inside the official template;
• run buildPlugin.sh and inspect a .snplg;
• install and execute the result on a device;
• qualify Windows or non-ASCII target paths.

Report validation at the layer actually tested.