manager.sh + boot_patch.sh:
- all listed files from boot_patch.sh header are required for boot patching, but stub.apk was being removed so install_magisk via addon.d.sh would fail without it; leave it in place
addon.d.sh:
- remove old redundant recovery_actions call (it's also performed by setup_flashable in initialize)
- print ABI to match flash_script.sh output
boot_patch.sh:
- catch and abort on any errors from ramdisk.cpio patching in the future
util_functions.sh:
- fix hiding of mount_partitions /system_root umount stderr
- quote mount_apex .pb DEST name parsing charset for safety even though both work
Fixes#6828
Before this change, the root manager package name is only written into
the database after the repackaged APK is installed. In the time between
the repackaged APK being installed and the package name being written
into the database, if some operation calls `get_manager`, the Magisk
daemon will cache this result and ignore the repackaged APK, even if
the package name is set afterwards, because the cache won't be
invalidated. The result is that the repackaged manager APK will not be
recognized as the root manager, breaking the hide manager feature.
This race condition is more likely to happen when Zygisk is enabled,
because `get_manager` is called with a very high frequency in that case.
To fix the issue, we have to set the new package name into the database
BEFORE installing the repackaged APK. We also stop pruning the
database if the repackaged manager is not found, moving this logic into
the Magisk app. By doing so, we can guarantee that the instant after
the repackaged manager APK is installed, the Magisk daemon will
immediately pick it up and treat it as the root manager.
Another small optimization: when the requester is root, simply bypass
the whole database + manager package check. Since the Magisk app hiding
APK installation proces will call `su` several times to run `pm` under
different UIDs, doing this opimization will reduce the amount of
unnecessary database query + filesystem traversals.
