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
Value of <dt>/fstab/<partition>/dev and <dt>/fstab/<partition>/type in official Android emulator ends with newline instead of \0, Magisk won’t be able to patch sepolicy and crash the system.
Signed-off-by: Shaka Huang <shakalaca@gmail.com>
The existing method for handling legacy SAR is:
1. Mount /sbin tmpfs overlay
2. Dump all patched/new files into /sbin
3. Magic mount root dir and re-exec patched stock init
With Android 11 removing the /sbin folder, it is quite obvious that
things completely break down right in step 1.
To overcome this issue, we have to find a way to swap out the init
binary AFTER we re-exec stock init. This is where 2SI comes to rescue!
2SI normal boot procedure is:
1st stage -> Load sepolicy -> 2nd stage -> boot continue...
2SI Magisk boot procedure is:
MagiskInit 1st stage -> Stock 1st stage -> MagiskInit 2nd Stage ->
-> Stock init load sepolicy -> Stock 2nd stage -> boot continue...
As you can see, the trick is to make stock 1st stage init re-exec back
into MagiskInit so we can do our setup. This is possible by manipulating
some ramdisk files on initramfs based 2SI devices (old ass non SAR
devices AND super modern devices like Pixel 3/4), but not possible
on device that are stuck using legacy SAR (device that are not that
modern but not too old, like Pixel 1/2. Fucking Google logic!!)
This commit introduces a new way to intercept stock init re-exec flow:
ptrace init with forked tracer, monitor PTRACE_EVENT_EXEC, then swap
out the init file with bind mounts right before execv returns!
Going through this flow however will lose some necessary backup files,
so some bookkeeping has to be done by making the tracer hold these
files in memory and act as a daemon. 2nd stage MagiskInit will ack the
daemon to release these files at the correct time.
It just works™ ¯\_(ツ)_/¯
- now that Canaries are only commit hashes for the version string, the v is unnecessary/confusing, so the simplest solution is to just remove the v from the filename for all Manager-based downloads of Magisk and Manager
