- 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
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.
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.
- /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
- 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
- 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
- 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
Rewrite the whole module mounting logic from scratch.
Even the algorithm is different compared to the old one.
This new design focuses on a few key points:
- Modular: Custom nodes can be injected into the mount tree.
It's the main reason for starting the rewrite (needed for Android 11)
- Efficient: Compared to the existing implementation, this is the most
efficient (both in terms of computation and memory usage) design I
currently can come up with.
- Accurate: The old mounting logic relies on handling specifically every
edge case I can think of. During this rewrite I actually found some
cases that the old design does not handle properly. This new design is
architected in a way (node types and its rankings) that it should
handle edge cases all by itself when constructing mount trees.
The modules will show updates at the top, active modules in the middle and finally remote modules at the bottom. The modules "install" button will be at the top of the "active" list.
This is done over usability concerns, as updates are more important than a list of installed modules.
This commit fixes the issue of adding single-span items in between full-span items whilst using `StaggeredGridLayoutManager` on recycler view.
Adding such items results in:
```
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 13
at java.util.Arrays.rangeCheck(Arrays.java:123)
at java.util.Arrays.fill(Arrays.java:2828)
at androidx.recyclerview.widget.StaggeredGridLayoutManager$LazySpanLookup.invalidateAfter(StaggeredGridLayoutManager.java:2876)
at androidx.recyclerview.widget.StaggeredGridLayoutManager.handleUpdate(StaggeredGridLayoutManager.java:1548)
at androidx.recyclerview.widget.StaggeredGridLayoutManager.onItemsUpdated(StaggeredGridLayoutManager.java:1524)
at androidx.recyclerview.widget.RecyclerView$6.dispatchUpdate(RecyclerView.java:1021)
at androidx.recyclerview.widget.RecyclerView$6.onDispatchSecondPass(RecyclerView.java:1032)
at androidx.recyclerview.widget.AdapterHelper.consumePostponedUpdates(AdapterHelper.java:121)
at androidx.recyclerview.widget.AdapterHelper.consumeUpdatesInOnePass(AdapterHelper.java:557)
at androidx.recyclerview.widget.RecyclerView.dispatchLayoutStep2(RecyclerView.java:4128)
at androidx.recyclerview.widget.RecyclerView.dispatchLayout(RecyclerView.java:3851)
at androidx.recyclerview.widget.RecyclerView.onLayout(RecyclerView.java:4404)
...and more
```
Affects versions including and prior to androidx.recyclerview:recyclerview:1.2.0-alpha02 (at the time of this commit) and possibly more after that.
This bug is caused by a single fact and that is - array inside of `LazySpanLookup` is not being invalidated and resized correctly when non-full-span item is being added in between of two full-span items. The invalidation however passes on some (high performance) devices so it doesn't necessarily cause issues for _some_ users; others keep getting the same crash over and over again.
Possible fix for anyone reading this, in the hope of fixing the same error, is to copy-paste the `StaggeredGridLayoutManager` and fix the array length before calling `Arrays.fill()`. There's no fix from user's perspective if you need to keep the UI as-is.
We however don't need the UI as-is, so we're instead opting to use LinearLayoutManager until is the issue resolved.
Continues tracking at https://issuetracker.google.com/issues/37034096Close#2631
