Full Changelog: https://github.com/RikkaApps/Shizuku/compare/v13.5.4...v13.6.0
Full Changelog: https://github.com/RikkaApps/Shizuku/compare/v13.5.3...v13.5.4
I don't have any physical device that can upgrade to Android 14 QPR2, neither does the simulator have 14 QPR2 image, so I cannot test it.
Full Changelog: https://github.com/RikkaApps/Shizuku/compare/v13.5.2...v13.5.3
rish
file has write permission (Android 14 enforces dex runs by app_process
must not have write permission, so place rish
files in /sdcard
will not work, uses needs to copy rish files to terminal apps' data folder)Full Changelog: https://github.com/RikkaApps/Shizuku/compare/v13.5.1...v13.5.2
addUserService
multiple timesrish
Google play now enforces that apps with Activity that has
LEANBACK_LAUNCHER
category intent filter must be uploaded with App Bundle format, and possibly additional review steps (I don't think Google is willing to allow the user to play with adb on their Google TV, right?).
Full Changelog: https://github.com/RikkaApps/Shizuku/compare/v13.3.0...v13.5.1
When developing apps that requires root, the most common method is to run some commands in the su shell. For example, there is an app that uses the pm enable/disable
command to enable/disable components.
This method has very big disadvantages:
Shizuku uses a completely different way. See detailed description below.
First, we need to talk about how app use system APIs. For example, if the app wants to get installed apps, we all know we should use PackageManager#getInstalledPackages()
. This is actually an interprocess communication (IPC) process of the app process and system server process, just the Android framework did the inner works for us.
Android uses binder
to do this type of IPC. Binder
allows the server-side to learn the uid and pid of the client-side, so that the system server can check if the app has the permission to do the operation.
Usually, if there is a "manager" (e.g., PackageManager
) for apps to use, there should be a "service" (e.g., PackageManagerService
) in the system server process. We can simply think if the app holds the binder
of the "service", it can communicate with the "service". The app process will receive binders of system services on start.
Shizuku guides users to run a process, Shizuku server, with root or ADB first. When the app starts, the binder
to Shizuku server will also be sent to the app.
The most important feature Shizuku provides is something like be a middle man to receive requests from the app, sent them to the system server, and send back the results. You can see the transactRemote
method in rikka.shizuku.server.ShizukuService
class, and moe.shizuku.api.ShizukuBinderWrapper
class for the detail.
So, we reached our goal, to use system APIs with higher permission. And to the app, it is almost identical to the use of system APIs directly.
https://github.com/RikkaApps/Shizuku-API
Existing applications still works, of course.
ADB permissions are limited
ADB has limited permissions and different on various system versions. You can see permissions granted to ADB here.
Before calling the API, you can use ShizukuService#getUid
to check if Shizuku is running user ADB, or use ShizukuService#checkPermission
to check if the server has sufficient permissions.
Hidden API limitation from Android 9
As of Android 9, the usage of the hidden APIs is limited for normal apps. Please use other methods (such as https://github.com/LSPosed/AndroidHiddenApiBypass).
Android 8.0 & ADB
At present, the way Shizuku service gets the app process is to combine IActivityManager#registerProcessObserver
and IActivityManager#registerUidObserver
(26+) to ensure that the app process will be sent when the app starts. However, on API 26, ADB lacks permissions to use registerUidObserver
, so if you need to use Shizuku in a process that might not be started by an Activity, it is recommended to trigger the send binder by starting a transparent activity.
Direct use of transactRemote
requires attention
The API may be different under different Android versions, please be sure to check it carefully. Also, the android.app.IActivityManager
has the aidl form in API 26 and later, and android.app.IActivityManager$Stub
exists only on API 26.
SystemServiceHelper.getTransactionCode
may not get the correct transaction code, such as android.content.pm.IPackageManager$Stub.TRANSACTION_getInstalledPackages
does not exist on API 25 and there is android.content.pm.IPackageManager$Stub.TRANSACTION_getInstalledPackages_47
(this situation has been dealt with, but it is not excluded that there may be other circumstances). This problem is not encountered with the ShizukuBinderWrapper
method.
git clone --recurse-submodules
:manager:assembleDebug
or :manager:assembleRelease
The :manager:assembleDebug
task generates a debuggable server. You can attach a debugger to shizuku_server
to debug the server. Be aware that, in Android Studio, "Run/Debug configurations" - "Always install with package manager" should be checked, so that the server will use the latest code.
All code files in this project are licensed under Apache 2.0
Under Apache 2.0 section 6, specifically:
You are FORBIDDEN to use manager/src/main/res/mipmap*/ic_launcher*.png
image files, unless for displaying Shizuku itself.
You are FORBIDDEN to use Shizuku
as app name or use moe.shizuku.privileged.api
as application id or declare moe.shizuku.manager.permission.*
permission.