For example, switching pages in home should only have scale and alpha animations, but a "translate y" animation shows. This is because Data Binding is triggered later (like "in the next frame"), causing the animation runs before view attribute changes.
This commit introduces WindowInsetsHelper class and use it to handle all window insets. With the help of LayoutInflaterFactory from the previous commit, we can control insets behavior by adding our attributes to the XML and anything is done by WindowInsetsHelper class.
As changes are highly coupling, this commit also contains new ItemDecoration for lists, replacing the random combination of padding and empty drawable. And "fixEdgeEffect" extension for RecyclerView, making edge effects respect padding.
This add the ability touch layout XML instantiates process. And most importantly, we can access AttributeSet, making custom view attribute possible.
Some other changes requires this.
The goal of original implementation, wrap view again and again, seems to be use the shadow and customizable round corners from MaterialCardView. But this can be done with use MaterialShapeDrawable which used in MaterialCardView directly. This will significantly simplify the layout and MagiskDialog class.
If we assign the execution output directly it will fail (tested on Android 11):
pdx201:/ # INSTALLER=/data/adb/magisk_install /data/adb/magisk_install/flash_script.sh
/data/adb/magisk_install/flash_script.sh[31]: typeset: -o: is not an identifier
Because:
local cmds=$($bb sh -o standalone -c "
for arg in \$(tr '\0' '\n' < /proc/$$/cmdline); do
if [ -z \"\$cmds\" ]; then
# Skip the first argument as we want to change the interpreter
cmds=\"sh -o standalone\"
else
cmds=\"\$cmds '\$arg'\"
fi
done
echo \$cmds")
/system/bin/sh: typeset: -o: is not an identifier
Signed-off-by: Pablo Mendez Hernandez <pablomh@gmail.com>
Previously, Magisk uses persist or cache for storing modules' custom
sepolicy rules. In this commit, we significantly broaden its
compatibility and also prevent mounting errors.
The persist partition is non-standard and also critical for Snapdragon
devices, so we prefer not to use it by default.
We will go through the following logic to find the best suitable
non-volatile, writable location to store and load sepolicy.rule files:
Unencrypted data -> FBE data unencrypted dir -> cache -> metadata -> persist
This should cover almost all possible cases: very old devices have
cache partitions; newer devices will use FBE; latest devices will use
metadata FBE (which guarantees a metadata parition); and finally,
all Snapdragon devices have the persist partition (as a last resort).
Fix#3179
