• topjohnwu's avatar
    Introduce component agnostic communication · 0f74e89b
    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.
    0f74e89b
daemon.cpp 4.77 KB