github
/
Magisk
mirror of https://github.com/topjohnwu/Magisk
1
Fork 0
Code Releases Activity
6,120 Commits 3 Branches 132 Tags 108 MiB
Commit Graph

6120 Commits

Author SHA1 Message Date
topjohnwu 71b7f52663 Release new canary build 2023-03-06 05:32:08 -08:00
LoveSy 981ccabbef No support for partitions w/o symlink in /system 2023-03-06 05:23:40 -08:00
vvb2060 9e07eb592c Fix make private before remount 2023-03-06 05:18:16 -08:00
LoveSy 9555380818 Replace parse_mnt with parse_mount_info 2023-03-06 05:09:12 -08:00
topjohnwu f80d5d858e Update AGP 2023-03-06 05:08:58 -08:00
topjohnwu a1ce6f5f12 Fix race condition when switching root manager 
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.
 2023-03-06 03:58:58 -08:00
LoveSy 1aade8f8a8 No greedy match to find parent mount point 
This fixes /sys is considered as a parent mount point of /system
 2023-03-03 11:09:03 -08:00
LoveSy b9213b7043 Remove redundant stub.apk 2023-03-03 11:07:36 -08:00
LoveSy 4af72324f4 Fix gradle cache 2023-03-03 02:39:22 -08:00
LoveSy b6ea5b8984 Fix SYSTEM_ROOT not passed to boot patch 2023-03-02 23:39:50 -08:00
topjohnwu c279e08c88 Release new canary build 2023-03-02 21:35:14 -08:00
topjohnwu 2717feac21 Fix stub APK building in app 2023-03-02 21:27:48 -08:00
topjohnwu 8adf27859d Build script adjustments 2023-03-02 20:32:46 -08:00
LoveSy 307cf87215 Fix build script 2023-03-02 20:32:46 -08:00
Takeda-senpai ca31412c05 Update strings.xml 2023-03-02 14:34:08 -08:00
LoveSy f59fbd5dca Filter duplicate mount points 
This prevents umounting existing overlay mount points
 2023-03-02 14:33:50 -08:00
topjohnwu 2285f5e888 Fix build script 2023-03-02 03:02:10 -08:00
LoveSy da36e5bcd5 Make worker private 2023-03-02 02:25:44 -08:00
Prithvi 4ed9f57fdc
Update ota.md (#6374) 
Specified the steps of the OTA install process so there is less confusion about what step 1 and 2 entail.
 2023-03-02 02:23:19 -08:00
Daki Carnhof ea7be6162f install.md: Mention Heimdall beside Odin 
Proven to work with Magisk 25.2, LineageOS 18.1, SM-A520F.
 2023-03-02 02:21:14 -08:00
南宫雪珊 3726eb6032
Deny init relabel to adb_data_file 
Co-authored-by: 残页 <a1364259@163.com>
Co-authored-by: LoveSy <shana@zju.edu.cn>
 2023-03-02 02:20:38 -08:00
vvb2060 6e918ffd68 Remove fetchCustomUpdate 2023-03-02 02:05:38 -08:00
vvb2060 4772868d6a Move REMOUNT_ROOT 2023-03-02 02:05:38 -08:00
vvb2060 78df677a42 Use /data/adb/modules directly 2023-03-02 02:05:38 -08:00
vvb2060 85a4b249b3 Skip copy old rule 2023-03-02 02:05:38 -08:00
vvb2060 d06e9a0b51 Allow R8 to delete fetchCanary 2023-03-02 02:05:38 -08:00
vvb2060 5eb774a2ad Fix typo 2023-03-02 02:05:38 -08:00
topjohnwu cbbbbab483 Release new canary build 2023-02-27 23:16:54 -08:00
LoveSy e5641d5bdb Fix avd-magisk 2023-02-27 23:00:42 -08:00
topjohnwu a721206c6f Update items in the right thread 2023-02-27 23:00:21 -08:00
LoveSy c7a27481f9 Update proguard rules to fix module page crash 2023-02-27 20:50:24 -08:00
LoveSy 594c304634 Fix release build 2023-02-26 22:35:20 -08:00
topjohnwu d0ec387c28 Release new canary build 2023-02-26 15:06:33 -08:00
vvb2060 7dbfba76bf Umount by tmpfs id 2023-02-26 14:23:11 -08:00
vvb2060 2a4aa95a6f Identify tmpfs used by magisk 2023-02-26 14:23:11 -08:00
vvb2060 5520f0fbf7 Add stub version to apk comment 2023-02-26 14:23:02 -08:00
LoveSy a1a87c9956 Get rid of vtable hook 2023-02-26 04:59:21 -08:00
vvb2060 2c53356bfd Remove unexpected files 2023-02-26 03:47:38 -08:00
topjohnwu 85d9756f62 Update Zygisk API documentation 2023-02-26 03:16:13 -08:00
LoveSy 79586ece4c Update install.md 2023-02-26 01:17:11 -08:00
AndroPlus 6851d11a8e Update Japanese translation 2023-02-26 01:16:23 -08:00
LoveSy 996a857096 Upgrade kotlin 2023-02-26 01:15:32 -08:00
LoveSy d7158131e4 No need to manually parse mount flags 2023-02-26 01:15:18 -08:00
topjohnwu 3d3082bc82 Minor optimizations 2023-02-26 01:14:10 -08:00
topjohnwu 744ebca206 Don't let inter_node upgrade to module_node 2023-02-25 22:05:50 -08:00
topjohnwu 92077ebe53 Refactor module and node implementation 2023-02-25 18:19:46 -08:00
LoveSy 78ca682bc5 Always mount tmpfs for dirs 
https://android-review.googlesource.com/c/platform/system/core/+/928592
 2023-02-25 18:19:46 -08:00
LoveSy af01a36296 Refactor magic mount to support overlayfs 
Previously, magic mount creates its own mirror devices and mount
mirror mount points. With these mirror mount points, magic mount
can get the original files and directory trees. However, some
devices use overlayfs to modify some mount points, and thus after
magic mount, the overlayed files are missing because the mirror
mount points do not contain the overlayed files. To address this
issue and make magic mount more compatible, this patch refactors
how magic mount works.

The new workflows are as follows:
1. make MAGISKTMP a private mount point so that we can create the
   private mount points there
2. for mirror mount points, we instead of creating our own mirror
   devices and mount the mirror mount points, we "copy" the
   original mount points by recursively mounting /
3. to prevent magic mount affecting the mirror mount points, we
   recursively set the mirror mount points private
4. to trace the mount points we created for reverting mounts, we
   again make the mirror mount points shared, and by this way we
   create a new peer group for each mirror mount points
5. as for tracing the newly created tmpfs mount point by magic
   mount, we create a dedicated tmpfs mount point for them, namely
   worker mount point, and obviously, it is shared as in a newly
   created peer group for tracing
6. when reverting mount points by magic mount, we can then trace
   the peer group id and unmount the mount points whose peer group
   ids are created by us

The advantages are as follows:
1. it is more compatible, (e.g., with overlayfs, fix #2359)
2. it can mount more partitions for which previous implementation
   cannot create mirror mount points (fix #3338)
 2023-02-25 18:19:46 -08:00
LoveSy 97ed1b16d0 Fix gzip decompression 2023-02-20 18:26:04 -08:00
LoveSy 508a001753 Remove obsolete link 2023-02-20 17:25:32 -08:00