- 24 Oct, 2019 5 commits
- 23 Oct, 2019 16 commits
-
-
topjohnwu authored
-
topjohnwu authored
We might be copying from CE to DE storage, which cannot be moved
-
topjohnwu authored
-
topjohnwu authored
-
topjohnwu authored
-
osm0sis authored
- per https://github.com/USA-RedDragon/sprd-mkbootimg-tools/blob/master/dtbtool.c - touch up hdr and table naming to be more uniform
-
あきと ミズキト authored
-
Abhishek Dubey authored
-
onevt authored
-
topjohnwu authored
-
topjohnwu authored
-
topjohnwu authored
-
topjohnwu authored
-
topjohnwu authored
-
topjohnwu authored
-
topjohnwu authored
-
- 22 Oct, 2019 4 commits
-
-
topjohnwu authored
-
topjohnwu authored
-
topjohnwu authored
-
Viktor De Pasquale authored
-
- 21 Oct, 2019 2 commits
-
-
topjohnwu authored
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.
-
topjohnwu authored
-
- 20 Oct, 2019 4 commits
- 19 Oct, 2019 2 commits
- 17 Oct, 2019 4 commits
-
-
topjohnwu authored
-
topjohnwu authored
-
topjohnwu authored
This not only simplifies hiding stub APKs (no resource IDs involved), but also opens the opportunity to allow users to customize whatever app name they want after it is hidden.
-
topjohnwu authored
- Skip 0x7f01XXXX - 0x7f05XXXX resource IDs in the main app; they are reserved for stub resources - Support sending additional data from host to guest - Use resource mapping passed from host when they are being sent to the system framework (notifications and shortcuts)
-
- 16 Oct, 2019 3 commits