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
The mechanism was replaced by loading updated directly by id to the initial list. There are two factors why yesterday-me was dumb:
1) By asynchronously loading update state, you have no control over it - hence no search
2) It's incredibly wasteful; running that hardcore search on every query? Not cool
...and from UX stand-point having updates inlined right under installed modules is by far better than nitpicking it from the list or in the search
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.
Running broadcast tests from the app does not accurately verifies
whether the broadcasts can be delivered when the app is not running in
the foreground, which is why we are running the test.
The only sane way to verify broadcasts is to trigger the broadcast test
directly from the daemon on boot complete. If it is not deliverable,
then activity mode shall be chosen.
In the meantime, cleanup AndroidManifest.xml
- increase SignBoot bootimg header version maximum from 4 to 8 (upstream AOSP is already at 3) and make a variable for future ease
- hdr read size of 1024 bytes was too small as hdr_v1 and hdr_v2 have increased the used header page areas to 1632 and 1648 bytes, respectively, so raise this to the minimum page size of 2048 and also make a variable for future ease
- do not return "not signed" for all caught exceptions, show StackTrace for future debugging then still return false for script purposes
- correct "test keys" boot image signing strings (scripts and app) to "verity keys"
Settings are now only on home screen as it directly relates to what user might want to do. It is highly unlikely that they would jump from any other screen to settings.
Log is no longer main destination as it's not used very widely; it's been moved to Superuser screen. This screen now encapsulates all root-related stuff.
Home screen is now strictly info-based, except install buttons, of course.
On API 23+, the platform unifies the way to handle drawable
resources across processes: all drawables can be passed via Icon.
This allows us to send raw bitmap to the system without the need to
specify a resource ID. This means that we are allowed to NOT include
these drawable resources within our stub APK, since our full APK can
draw the images programmatically and send raw bitmaps to the system.
For some reason, Google Play Protect randomly blocks our self-signed
repackaged Magisk Manager APKs. Since we are root, the sky is our
limit, so yeah, disable package verification temporarily when installing
patched APKs, LOLz
Close#1979
Usually, the communication between native and the app is done via
sending intents to either broadcast or activity. These communication
channels are for launching root requests dialogs, sending root request
notifications (the toast you see when an app gained root access), and
root request logging.
Sending intents by am (activity manager) usually requires specifying
the component name in the format of <pkg>/<class name>. This means parts
of Magisk Manager cannot be randomized or else the native daemon is
unable to know where to send data to the app.
On modern Android (not sure which API is it introduced), it is possible
to send broadcasts to a package, not a specific component. Which
component will receive the intent depends on the intent filter declared
in AndroidManifest.xml. Since we already have a mechanism in native code
to keep track of the package name of Magisk Manager, this makes it
perfect to pass intents to Magisk Manager that have components being
randomly obfuscated (stub APKs).
There are a few caveats though. Although this broadcasting method works
perfectly fine on AOSP and most systems, there are OEMs out there
shipping ROMs blocking broadcasts unexpectedly. In order to make sure
Magisk works in all kinds of scenarios, we run actual tests every boot
to determine which communication method should be used.
We have 3 methods in total, ordered in preference:
1. Broadcasting to a package
2. Broadcasting to a specific component
3. Starting a specific activity component
Method 3 will always work on any device, but the downside is anytime
a communication happens, Magisk Manager will steal foreground focus
regardless of whether UI is drawn. Method 1 is the only way to support
obfuscated stub APKs. The communication test will test method 1 and 2,
and if Magisk Manager is able to receive the messages, it will then
update the daemon configuration to use whichever is preferable. If none
of the broadcasts can be delivered, then the fallback method 3 will be
used.
