Closed chunxiaoyi closed 3 years ago
The reason why I've used a script instead of system.prop was so that i could check if any other gboard bottom padding altering module was present (and if they were the code wouldn't run and it would let those modules handle the padding instead) and if no other module was present it would insert that property
A fix seems to be to simply switch the script from a post-fs-data script to a service script (which wouldn't block boot), although I'm not sure a service script would consistently insert the property before Gboard starts up
Also this blocking seem to be rare, so far I've only gotten 2 reports of this issue, so I'm wondering why exactly are a few devices hanging at this simple script
Actually,this blocking does be rare,we don't know why magisk will not exec resetprop
.
Anyway, what is the other bug device's name ?
And this blocking happens randomly, sometimes riru_lsposed will still work. This is another questions cofused me.
By the way,when I update magisk to 22102 (offcial),this blocking will not happen again
And this blocking happens randomly, sometimes riru_lsposed will still work. This is another questions cofused me.
By the way,when I update magisk to 22102 (offcial),this blocking will not happen again
Alright, I've switched to using service.sh, try redownloading the module and check if the issue is fixed
The bug is because Magisk will load system.prop
from modules and update system properties. However, system properties can only be upgraded by one single process and the process that acquires the lock will be Magisk if there is any module that contains system.prop
and triggers Magisk to get the lock. Once that happens, resetprop
will be blocked until Magisk finishes its loading.
In short, resetprop
is not safe on post-fs-data.sh
.
See comments about __system_property_update
: https://cs.android.com/android/platform/superproject/+/master:bionic/libc/include/sys/_system_properties.h;drc=0fe22033095dc0805c191c37075eb0c3e9d29334;l=107
The bug is because Magisk will load
system.prop
from modules and update system properties. However, system properties can only be upgraded by one single process and the process that acquires the lock will be Magisk if there is any module that containssystem.prop
and triggers Magisk to get the lock. Once that happens,resetprop
will be blocked until Magisk finishes its loading.In short,
resetprop
is not safe onpost-fs-data.sh
.See comments about
__system_property_update
: https://cs.android.com/android/platform/superproject/+/master:bionic/libc/include/sys/_system_properties.h;drc=0fe22033095dc0805c191c37075eb0c3e9d29334;l=107
You see, that's what confuses me, i have a few other modules that have system.prop but never once have i gotten this blockage, either way i've already switched to service.sh in the module
Module version: 8.7 Magisk version: 22.1(22100) Android version: 10 device: LG G8 install: Fullscreen + Low (Module Default)
Problems is in
post-fs-data.sh
this file. In my device (lg g8 with Android 10),when the device boots,the log shows(I just pick up the useful part in the boot log.And it will make riru_lsposed broken.) Why will it timeout?
The reason of causing this bug is this code in
post-fs-data.sh
resetprop ro.com.google.ime.kb_pad_port_b 1.0
Why will it (resetprop) cause bugs?We don't know yet,but it looks like magisk's problem. It is very hard to locate it,so,it's hard for magisk developers to fix it.
However,you can easily fix this problem by doing this. 1.Delete
post-fs-data.sh
2.Make a new file calledsystem.prop
3.Write this insystem.prop
ro.com.google.ime.kb_pad_port_b=1.0
I am using my own fixed versions now,and it works well so far.Now just reporting this bug to you for fixing it.