Incompatible with ReZygisk on Magisk

[R917C]

Steps to reproduce/复现步骤

1. Install Magisk 28001 on Lineageos 20
2. Install Rezygisk Latest CI
   Link: https://github.com/PerformanC/ReZygisk/actions/runs/11207970223
3. Install LSPosed 7111 or above
4. Reboot
5. Enter the passcode and enter the system
6. The system suddenly reboot
7. After reboot, enter the system, go to Magisk module list
8. The Rezygisk's description says "zygote32 crashed"

Expected behaviour/预期行为

Normal use

Actual behaviour/实际行为

See above

Xposed Module List/Xposed 模块列表

Hide my applist v3.3.r424
Donottryaccessibility v1.0.2

Magisk Module List/Magisk 模块列表

Play integrity fix v17.7
Rezygisk v1.0.0 267-f8a0d1d-release
Tricky store v1.0.3
Tricky store helper v0.2.1
Zygisk Assistant v2.1.3 1304dca

LSPosed version/LSPosed 版本

7111

Android version/Android 版本

13

Magisk version/Magisk 版本

28001

Riru version/Riru 版本

N/A

Version requirement/版本要求

• I am using latest debug CI version of LSPosed and enable verbose log/我正在使用最新 CI 调试版本且启用详细日志

Logs/日志

LSPosed_2024-10-12T17_11_31.730416.zip

[JingMatrix]

Please use a stable version of Rezygisk. The one you were using was built in a working in process branch.
For example, try this build from the main branch:

https://github.com/PerformanC/ReZygisk/actions/runs/10426942973

This is not a problem of LSPosed.

[JingMatrix]

Moreover, I would recommand that you simply enable the Zygisk function of Magisk and remove the ReZygisk module.

[JingMatrix]

As a workaround, if you want to continue using ReZygisk, you may try it with KernelSU, where this issue no longer happens.

[JingMatrix]

The sendToBridge method will use the activity service to send a binder (which is the mainService of LSPosed daemon's ServiceManager.java, an instance of LSPosedService.java) to BridgeService.
This process using a third party service, i.e., the activity service, is possible becasue we hook the execTransact method in service.cpp by replacing the CallBooleanMethodV element of the JNINativeInterface structure.
Now, BridgeService failed to receive the binder, most likely, it is because that the above replacment failed.

Hence, one needs to check if Service::HookBridge() method really did its work in ReZygisk with Magisk.

[JingMatrix]

The restarting of system server is called by maybeRetryInject of LSPSystemServerService.java.
Maybe ReZygisk made it too late for LSPosed to inject into system server?
Actually, if we revert #57, then the restarting is no longer needed.

How do we kown that it is indeed too late to start the LSPosed daemon?

The LSPosed deamon used to start as post-fs-data, which was the earliest choice.
But now it starts as late_start service. With Zygisk of Magisk, this change of starting mode delays (the execution of LSPosed deamon) a bit, but with ReZygisk, it delays a lot. If being delayed two much, the daemon has to restart Zygote to hook system server.

As a comparsion, the delay caused by Zygisk Next is close to the one caused by Zygisk of Magisk, but sufficiently shorter than ReZygisk.

Why the delay happens?

post-fs-data mode is BLOCKING. Current ReZygisk rewritten in C, running in post-fs-data mode, blocks services of other modules, such as the LSPosed daemon. That is how the delay happens.

Why the delay is so significant?

1. ReZygisk abandons the usage of threads to avoid blocking
2. ReZygisk run Zygisk modules' service.sh in a blocking mode

How to compare delays quickly?

Looking at the PID of LSPosed logs with tag LSPosedService. LSPosed deamon started with a reasonable delay should get a PID valued between 1000 and 1500.
A PID valued bigger than 3000 is too late for LSPosed deamon.

[JingMatrix]

Current issue will be solved when PerformanC/ReZygisk#91 get merged.