1. 24 Oct, 2019 5 commits
  2. 23 Oct, 2019 16 commits
  3. 22 Oct, 2019 4 commits
  4. 21 Oct, 2019 2 commits
    • 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
    • topjohnwu's avatar
      Allow upgrade Magisk daemon in emulator · 953c40b0
      topjohnwu authored
      953c40b0
  5. 20 Oct, 2019 4 commits
  6. 19 Oct, 2019 2 commits
  7. 17 Oct, 2019 4 commits
  8. 16 Oct, 2019 3 commits