- 18 May, 2020 4 commits
- 17 May, 2020 5 commits
-
-
Tornike Khintibidze authored
-
topjohnwu authored
-
topjohnwu authored
-
topjohnwu authored
-
Hen Ry authored
-
- 16 May, 2020 1 commit
-
-
topjohnwu authored
-
- 10 May, 2020 2 commits
- 09 May, 2020 3 commits
-
-
Chris Renshaw authored
-
Chris Renshaw authored
-
vvb2060 authored
-
- 08 May, 2020 4 commits
-
-
topjohnwu authored
-
topjohnwu authored
-
topjohnwu authored
When detecting device is booting as Safe Mode, disable all modules and MagiskHide and skip all operations. The only thing that'll be available in this state is root (Magisk Manager will also be disabled by system). Since the next normal boot will also have all modules disabled, this can be used to rescue a device in the case when a rogue module causes bootloop and no custom recovery is available (or recoveries without the ability to decrypt data).
-
topjohnwu authored
-
- 07 May, 2020 2 commits
- 05 May, 2020 3 commits
-
-
topjohnwu authored
-
topjohnwu authored
- Do not attempt to patch DTB anywhere outside of boot images as they are no longer essential. This makes Magisk installation to only modify strictly boot/recovery partitions again. - The only required patch for DTB is to strip verity out of partitions
-
topjohnwu authored
Since we no longer need to add new properties in the device tree, and all the patches we do removes strings, we can just directly patch the flat device tree in-place, ignoring basically all the higher level DTB structure and format to accomplish 100% compatibility.
-
- 04 May, 2020 5 commits
-
-
topjohnwu authored
Patching DTBs is proven to be difficult and problematic as there are tons of different formats out there. Adding support for all the formats in magiskboot has been quite an headache in the past year, and it still definitely does not cover all possible cases of them out there. There is another issue: fake dt fstabs. Some super old devices do not have device trees in their boot images, so some custom ROM developers had came up with a "genius" solution: hardcode fstab entries directly in the kernel source code and create fake device tree nodes even if Android 10+ init can graciously take fstab files instead (-_-) 。。。 And there is YET another issue: DTBs are not always in boot images! Google is crazy enough to litter DTBs all over the place, it is like they cannot make up their minds (duh). This means the dt fstabs can be either concatnated after the kernel (1), in the DTB partition (2), in the DTBO partition (3), in the recovery_dtbo section in boot images (4), or in the dtb section in boot images (5). FIVE f**king places, how can anyone keep up with that! With Android 10+ that uses 2 stage inits, it is crutual for Magisk to be able to modify fstab mount points in order to let the original init mount partitions for us, but NOT switch root and continue booting. For devices using dt for early mount fstab, we used to patch the DTB at install time with magiskboot. However these changes are permanent and cannot be restored back at reinstallation. With this commit, Magisk will read dt fstabs and write them to ramdisk at boot time. And in that case, the init binary will also be patched to force it to NEVER use fstabs in device-tree. By doing so, we can unify ramdisk based 2SI fstab patching as basically we are just patching fstab files. This also means we can manipulate fstab whatever Magisk needs in the future without the need to going through the headache that is patching DTBs at installation.
-
topjohnwu authored
Users should manually switch to recovery mode instead
-
Chris Renshaw authored
- /vendor is used only on some older devices for recovery AVBv1 signing so is not critical if fails - this fixes installation in Lineage Recovery on some older devices where /vendor is actually by-name partitions like oem, cust (or even cache), which likely also don't require the AVBv1 signing
-
topjohnwu authored
-
topjohnwu authored
-
- 02 May, 2020 1 commit
-
-
topjohnwu authored
-
- 01 May, 2020 1 commit
-
-
topjohnwu authored
-
- 30 Apr, 2020 3 commits
-
-
topjohnwu authored
-
topjohnwu authored
-
osm0sis authored
- bugged TWRPs were filling persist with recovery logs, so clean those as a potential workaround - abort module install if sepolicy.rule fails to copy, since 99% of the time the module wouldn't include it if it could function without it Closes #2461
-
- 26 Apr, 2020 1 commit
-
-
topjohnwu authored
-
- 24 Apr, 2020 4 commits
-
-
osm0sis authored
- try /dev/block first with full depth to catch all platform/soc variations to the by-name directory, and the new dynamic partition /dev/block/mapper - next try uevent for block devices as before - lastly try /dev with maxdepth 1 (immediate directory) to find /dev/bootimg, /dev/recovery, etc. while avoiding /dev/log/kernel - move bootimg higher in the list than boot so /dev/bootimg gets found first and avoids /dev/BOOT - recovery_a/_b now also exists - minor touch-ups for readability and consistency Fixes #2720
-
osm0sis authored
-
osm0sis authored
- this is needed for installations on Lineage 17.1 Recovery (AOSP Q) for logical partition devices, which uses /dev/block/mapper to stage the partitions Thanks LuK1337 & erfanoabdi @ Lineage
-
topjohnwu authored
Close #2725
-
- 23 Apr, 2020 1 commit
-
-
topjohnwu authored
-