Compatibility

Generator Requirements and Backend Limits

This page describes requirements introduced or checked by the native-module generator. It does not duplicate the toolchain requirements for creating and building a Supernote plugin.

Required starting point

The existing plugin must already build successfully and contain:

PluginConfig.json
package.json
android/
android/settings.gradle       # or settings.gradle.kts

For the surrounding plugin environment, use the official Supernote documentation.

Generator requirements

Requirement	Scope
Python 3.9+	Runs the generator; repository CI covers 3.9–3.13
npm or Yarn already used by the plugin	Links the generated file: dependency unless --skip-install is selected
Writable plugin root	Required for staged generation, parent integration, and transaction recovery

The generator supports npm and Yarn selection but does not pin or qualify a package-manager version. Conflicting lockfiles require an explicit --package-manager choice.

Generated Android constraints

These values come from generated files and therefore matter even when the existing plugin already builds:

Generated constraint	Backend
compileSdk 35, minSdk 27, Java toolchain target 17	Native, JNI, and JSI
CMake 3.22.1+	JNI and JSI
NDK Clang accepting C23 and C++23 for Android API 27	JNI and JSI
arm64-v8a	JNI and JSI

Check only the backend being added:

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

Doctor probes generator prerequisites and selected compiler features. It is not a substitute for the existing plugin's own environment checks.

Host-path coverage

Generator host/path	Status
Linux	Python suite runs in CI on 3.9–3.13
macOS	Python suite, wheel installation, and all-backend generation smoke tested
Windows	Code has PowerShell and gradlew.bat paths; no Windows CI job
Plugin paths containing spaces	Not qualified end to end
Non-ASCII plugin paths	Not qualified

Backend support boundaries

Backend	Generator support	Additional boundary
Native	Implemented and unit/integration tested	Parent project must compile the generated KSP/bridge output
JNI	Implemented and binding-generation tested	Parent project must compile generated JNI/CMake output
JSI	Implemented and loader/binding-generation tested	Target PluginHost, linker namespace, and SELinux policy must permit execution

“Generated” is not the same claim as “compiled” or “executed.” Repository CI currently validates generator output but does not compile all three backends in a complete external plugin fixture.

JSI support gates

1. Generation: the tool creates the package, HostFunctions, loader, declarations, and autolinking.
2. Compilation: the existing parent project resolves compatible React Native/JSI headers and builds the generated .so.
3. Execution: PluginHost loads that library and device policy permits execution from the plugin's extracted location.

Maintainer testing on 2026-07-30 found that the generated loading pattern ran on a userdebug/permissive configuration. An enforcing retail configuration denied the extracted .so with dlopen ... Permission denied and an SELinux { execute } denial. Permissive success is not proof for an enforcing target.

Re-test the exact PluginHost, firmware, linker namespace, and SELinux policy before assuming JSI execution on another target. The generator cannot change device policy.

Documentation version

The Wiki follows the default branch and may describe unreleased generator changes. Check supernote-module --version and the repository changelog when working with an older generated module.