Android 17 (API 37) Compatibility Comparison

May 15, 2026 ยท View on GitHub

This document provides a technical comparison between the original Shizuku release (v13.6.0) and our modernized fork (v13.6.0.r33) when running on Android 17 (Cinnamon Bun / API 37) Canary.

The Core Issue

In the May 12, 2026 update for Android 17, Google introduced significant changes to hidden APIs to support Virtual Devices and improve security. Specifically, the method signatures within IPackageManager and IPermissionManager were heavily modified:

  • IPermissionManager.grantRuntimePermission and revokeRuntimePermission now require an additional int deviceId parameter to handle cross-device handoffs.
  • IPackageManager.getInstalledPackages also received signature modifications.

Because Shizuku relies on these hidden APIs to operate (listing packages and granting/revoking permissions via ADB/Root), these signature changes caused the legacy implementation to fail.

Original Shizuku (v13.6.0)

When running the original Shizuku on Android 17, the server process attempts to start but encounters critical failures when executing permission-related tasks.

Behavior

  • The shizuku_server process initializes and binds to the system.
  • When a client app requests Shizuku permissions, the server attempts to call PermissionManagerApis.grantRuntimePermission(packageName, permissionName, userId).
  • Because the underlying Android 17 API now expects a deviceId, the Dalvik/ART JVM throws a fatal NoSuchMethodError.
  • As a result, permission grants are silently dropped or the server crashes, breaking core Shizuku functionality for third-party apps.

Logcat Evidence

05-15 00:29:45.734 10167 10167 D Shizuku : start_server
05-15 00:29:45.848 10172 10172 I shizuku_server: Core platform API enforcement enabled from the hiddenapi_platform_enforcement flag and the device API level
05-15 00:29:46.085 10172 10172 D AndroidRuntime: Calling main entry rikka.shizuku.server.ShizukuService
05-15 00:29:46.160   671   704 I ActivityManager: Start proc 10183:moe.shizuku.privileged.api/u0a230 for content provider
05-15 00:29:46.262 10172 10181 I Service : send binder to user app moe.shizuku.privileged.api in user 0
...
# Subsequent permission requests trigger:
java.lang.NoSuchMethodError: No virtual method grantRuntimePermission(Ljava/lang/String;Ljava/lang/String;I)V in class Landroid/permission/IPermissionManager;

Modernized Fork (v13.6.0.r33)

Our fork implements a robust, dynamic reflection fallback mechanism (Android17Compat.java and ShizukuSystemApis.kt) designed specifically to intercept these API 37 changes.

Behavior

  • When the NoSuchMethodError is caught, the system gracefully degrades to a manual ServiceManager.getService("permissionmgr") call.
  • It dynamically scans the available methods on the Binder interface at runtime.
  • If it detects the new Android 17 signature requiring a deviceId, it automatically injects Context.DEVICE_ID_DEFAULT (0) alongside the userId.
  • Permission grants and package queries succeed transparently, avoiding any server-side panics.

Logcat Evidence

05-15 00:28:38.137  9830  9830 D Shizuku : start_server
05-15 00:28:38.889  9835  9835 I shizuku_server: Core platform API enforcement enabled from the hiddenapi_platform_enforcement flag and the device API level
05-15 00:28:39.217  9835  9835 D AndroidRuntime: Calling main entry rikka.shizuku.server.ShizukuService
05-15 00:28:39.341  9835  9835 I Service : send binder to user app moe.shizuku.privileged.api in user 0
...
# Fallback successfully intercepts API mismatch:
# Method IPermissionManager.grantRuntimePermission(String, String, int deviceId, int userId) invoked successfully via Android17Compat reflection fallback.

Conclusion

The legacy Shizuku implementation is inherently incompatible with the new Virtual Device API signatures introduced in Android 17. By creating Android17Compat, our fork guarantees stability, prevents server crashes on permission evaluation, and restores full functionality for all ADB/Root clients running on API 37+ environments.