CleveresTricky

Install the module

The installer creates a complete KernelSU, APatch, or Magisk module with the service, native payload, scripts, policy, metadata, and integrity records required at runtime.

Where to find it: KernelSU / APatch / Magisk. Where is each feature?

What to do

  1. Install the official ZIP through your root manager.
  2. Open WebUI (Magisk: Action).
  3. Add authorized key material in Keyboxes.
  4. Keep optional identity controls off until needed.

Details and limits

Kernel requirement: Android 12-17 support describes the Android API level, not every legacy kernel. The runtime requires working pidfd_open and pidfd_send_signal system calls (checked at startup). Older kernels without these features cannot start the supervisor, even on Android 12. If the service is offline, use Create emergency report on the WebUI gate; factory reset cannot add missing kernel support.

Minimum kernel baseline: Linux 5.3 or newer with functional pidfd_open and pidfd_send_signal. The installer rejects older release numbers even when features have been backported. Android 12 GKI commonly uses 5.10, which is recommended; Android API 31 alone does not guarantee kernel compatibility.

Supported path

Installation must run from KernelSU, APatch, or Magisk while Android is active. Android 12 through Android 17 are supported on ARM64 and x86 64. All three provide full WebUI support; on Magisk the WebUI opens from the module Action button via the standalone WebUI host app (see Magisk Support).

Recovery installation paths stop with an explanation before a partial module is left behind.

The installer selects the architecture specific Rust inject and webui_bridge executables and the libcleverestricky.so library. It also installs the daemon, service APK, module metadata, installer script, early boot script, service script, native webroot, and SELinux policy required by their lifecycle stage.

Binary and script payloads are intentional parts of the module template. KernelSU and APatch use the metadata and boot scripts to recognize and start the module. The build process verifies that required files and both native architecture outputs exist before creating a ZIP.

Integrity and permissions

The build adds a SHA 256 record for every packaged payload. Installation verifies each file it extracts against that record.

Runtime verification then walks the installed module with bounded input, rejects symbolic links and non regular entries, requires integrity records for normal payloads, rejects unexpected unchecked payloads including system.prop, and enters tamper lockdown when a required file is missing or changed.

Manager owned state files named disable, remove, update, and the module tamper marker may exist without payload checksums because they are control state rather than executable or property payloads.

Runtime scripts restore conservative file modes and SELinux labels without recursively following unexpected links or crossing mounts.

Official release authenticity

Archive internal SHA 256 records prove consistency of the installed payload but they are not by themselves proof of who created an archive. A person who can replace every file inside a ZIP can also replace checksum records and the installer script inside that same ZIP.

Official release builds therefore publish a separate SHA256SUMS file for the release ZIP. The release workflow also creates GitHub-signed build provenance for that digest through the repository Actions identity. This external provenance is the trust anchor that distinguishes an official build from a repack that merely recalculates archive internal hashes.

When authenticity matters, download from the official project release page and verify the release digest and GitHub attestation before installation. A modified archive cannot retain the official digest or provenance for its changed bytes.

Installation sequence

  1. Download the release ZIP from the official project release page.

  2. Verify its entry in SHA256SUMS and GitHub build provenance when source authenticity is required.

  3. Install it through KernelSU, APatch, or Magisk.

  4. Confirm that the manager reports success.

  5. Reboot Android.

  6. KernelSU / APatch: Open the module WebUI and review Dashboard and Logs. Magisk: Tap the module Action button to open the WebUI via the WebUI host app (installed automatically on first use). Runtime status can also be checked via su -c "cat /data/adb/cleverestricky/native_runtime.log", process inspection (su -c "ps -A | grep -E 'cleverestrickyd|cleverestricky_backend'"), or emergency-report.sh (see Magisk Support).

Do not extract or delete template binaries manually. An incomplete payload will fail verification or prevent native runtime activation.

Back to all guides

The same ZIP installs the optional CleveresTricky Identity (Optional Zygisk) companion as a separate module. The core module never requires Zygisk. Without an active provider, the companion starts disabled; enable Zygisk and then enable the companion in your root manager for app-specific overrides. Companion disable choices survive updates. Removing the core removes its companion, and a disabled, removed or mismatched core prevents companion hooks.