Due to changes in ec3705f2ed187863efc34af5415495e1ee7775d2, the app can
no longer communicate with the dameon through a socket opened on the
daemon side due to SELinux restrictions. The workaround here is to have
the daemon decide a socket name, send it to the app, have the app create
the socket server, then finally the daemon connects to the app through
the socket.
The aforementioned fragment has fixed issue with layouts being oversized on API21 (maybe a bit lower and higher as well, did not test) which was notable on homepage.
Unfortunately it deprecated most of the logic behind hiding of the top action view. Since it inherited and overridden the functionality from HideBottomViewOnScrollBehavior it no longer called the old methods and so the whole class was rendered _useless_. Fortunately we didn't need the whole backing implementation so the parent class was changed to the bare minimum. Hopefully this incident will not repeat.
Thanks goes to material team for introducing breaking changes in feature update.
Added pinch in to increase list span count / out to decrease
The setting will be remembered across the whole app (every list that uses Staggered Grid)
Updated indication of whether the policy has root access enabled permitted or not
Displays crossed out app logo if not permitted
- Update backup format as we might be patching multiple partitions
- Update uninstaller to remove files in persist (sepolicy.rule)
- Better handling for dtb/dtbo partition patching
All files (that used styles) were refactored to use styles directly so themes can only actually adjust colors
- Elaborate themes would be super hard to maintain and would certainly break over time
Added "endless" scrolling support
- this is done in order to display everything very swiftly and load as user needs it
- for the most part we'll download only ~10 items and load the rest as scroll progresses, this accomplishes the illusion that whole list is being populated
Added sections and updated repo view
Previously, we use either BroadcastReceivers or Activities to receive
messages from our native daemon, but both have their own downsides.
Some OEMs blocks broadcasts if the app is not running in the background,
regardless of who the caller is. Activities on the other hand, despite
working 100% of the time, will steal the focus of the current foreground
app, even though we are just doing some logging and showing a toast.
In addition, since stubs for hiding Magisk Manager is introduced, our
only communication method is left with the broadcast option, as
only broadcasting allows targeting a specific package name, not a
component name (which will be obfuscated in the case of stubs).
To make sure root requests will work on all devices, Magisk had to do
some experiments every boot to test whether broadcast is deliverable or
not. This makes the whole thing even more complicated then ever.
So lets take a look at another kind of component in Android apps:
ContentProviders. It is a vital part of Android's ecosystem, and as far
as I know no OEMs will block requests to ContentProviders (or else
tons of functionality will break catastrophically). Starting at API 11,
the system supports calling a specific method in ContentProviders,
optionally sending extra data along with the method call. This is
perfect for the native daemon to start a communication with Magisk
Manager. Another cool thing is that we no longer need to know the
component name of the reciever, as ContentProviders identify themselves
with an "authority" name, which in Magisk Manager's case is tied to the
package name. We already have a mechanism to keep track of our current
manager package name, so this works out of the box.
So yay! No more flaky broadcast tests, no more stupid OEMs blocking
broadcasts for some bizzare reasons. This method should in theory
work on almost all devices and situations.
