Shizuku can help normal apps uses system APIs directly with adb/root privileges with a Java process started with app_process.
The name Shizuku coms from a character.
Why was Shizuku born?
The birth of Shizuku has two main purposes.
- Provide a convenient way to use system APIs
- Convenient for the development of some apps that only requires adb permissions
Shizuku vs. "Old school" method
"Old school" method
For example, to enable/disable components, some apps that require root privileges execute
pm disable directly in
- (pre-Pie) Start the Java process with app_process (see here)
- (Pie+) Execute the native program
- Process the parameters, interact with the system server through the binder, and process the result to output the text result.
Each of the "Execute" means a new process creation, su internally uses sockets to interact with the su daemon, and a lot of time and performance are consumed in such process. (Some poorly designed app will even execute
su every time for each command)
The disadvantages of this type of method are:
- Extremely slow
- Need to process the text to get the result
- Features are subject to available commands
- Even if adb has sufficient permissions, the app requires root privileges to run
The Shizuku app will direct the user to run a process (Shizuku service process) using root or adb.
- When the app process starts, the Shizuku service process sends the binder to the app process.
- The app interacts with the Shizuku service through the binder, and the Shizuku service process interacts with the system server through the binder.
The advantages of Shizuku are:
- Minimal extra time and performance consumption
- It is almost identical to the direct invocation API experience (app developers only need to add a small amount of code)