Compatibility

Requirements and Compatibility

Start from a plugin that already builds using the official Supernote environment.

Required plugin files

The generator expects:

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

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 staging changes and recovery

The generator does not pin an npm or Yarn version. Conflicting lockfiles require an explicit --package-manager choice.

Generated Android requirements

Requirement in generated files	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 you are adding:

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

Tested environments

Host or 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	PowerShell and gradlew.bat paths exist; not covered by CI
Plugin paths containing spaces	Not tested end to end
Non-ASCII plugin paths	Not tested end to end

What the project tests

Backend	Tested in this repository	Not yet covered by CI
Native	Generation and simulated integration behavior	Compiling in a complete external plugin
JNI	Generation and C/C++ binding behavior	Compiling generated JNI/CMake in a complete external plugin
JSI	Generation, HostFunctions, and loader behavior	Compiling and executing on a target PluginHost

CI checks the files produced by the generator. It does not yet build all three backends inside a complete external Supernote plugin.

JSI on Supernote

JSI is a supported generator backend. For a generated JSI module to run:

1. The generator creates the package, HostFunctions, loader, declarations, and autolinking.
2. Your plugin resolves compatible React Native/JSI headers and compiles the generated .so.
3. PluginHost loads that library and device policy permits execution from the extracted plugin 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 does not establish support on an enforcing target.

The official Plugin Principles describe Java/TurboModule access followed by Java-to-C/C++; they do not promise direct JavaScript-to-C/C++ calls. Re-test the exact PluginHost, firmware, linker namespace, and SELinux policy before relying on JSI. The generator cannot change device policy.

Documentation version

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