Commit Graph

252 Commits

Author SHA1 Message Date
topjohnwu
25c557248c Use ContentProvider call method for communication
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.
2019-11-04 14:32:28 -05:00
topjohnwu
26618f8d73 Don't do broadcast tests from app
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
2019-11-03 17:01:09 -05:00
osm0sis
6fd357962f scripts: fix signing in recovery with addon.d-v1
- change to $TMPDIR in addon.d.sh since recovery addon.d-v1 backup + restore leaves you in /tmp/addon.d which the restore then deletes, which would break $BOOTSIGNER execution with the following:
    libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 1078 (main), pid 1078 (main)
    Segmentation fault
- also move $BOOTSIGNER execution to after `cd $MAGISKBIN` to ensure it's in a working directory in all cases
- addon.d.sh data mount wasn't doing anything since /data has to already be mounted for the script to be running, so move it into /system/addon.d/99-magisk.sh stub script where it might be useful on recoveries that don't mount /data initially

Fixes #2013
2019-11-03 03:00:08 -05:00
topjohnwu
b31d986c8d Update scripts 2019-11-02 00:41:51 -04:00
osm0sis
c85b1c56af signing: fixes for bootimg hdr_v1 and hdr_v2
- 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"
2019-11-02 00:27:56 -04:00
osm0sis
6dd34aec47 scripts: refactor and major addon.d fixes
- remove redundant addon.d.sh script bits that were covered elsewhere ($TMPDIR in util_functions.sh, find_dtbo_image in patch_dtbo_image)
- refactor addon.d.sh and flash_script.sh for simplicity and readability, and put common flashing script in util_functions.sh (as patch_boot_image), which should greatly help avoid them getting out of sync going forward and fixes compressing ramdisk support and post-patch cleanup for addon.d
- add check_data to addon.d.sh since moving stock_boot* and stock_dtbo* backups depend on it and so weren't occuring with addon.d
- fix find_manager_apk with working fallback for recovery addon.d execution (where `magisk --sqlite` will not work for hidden Manager), Manager DynAPK hiding, and print a useful log warning if an APK can't be found
2019-11-02 00:27:56 -04:00
topjohnwu
953c40b083 Allow upgrade Magisk daemon in emulator 2019-10-21 13:58:57 -04:00
topjohnwu
75306f658f Revert "Drop API 17 (Android 4.2) support"
Turns out that we cannot use AndroidKeystore anyways, so we don't
actually need to drop API 17. Revert this change.
2019-10-20 07:13:03 -04:00
topjohnwu
9c27d691dd Drop API 17 (Android 4.2) support 2019-10-19 03:11:54 -04:00
topjohnwu
c3e00c279d Legacy adb shell does not have uname 2019-10-11 01:45:06 -04:00
topjohnwu
16b400964b Update vars for 2SI 2019-09-22 06:45:23 -04:00
topjohnwu
cf2d02c0dd Don't wipe ramdisk when A-only SAR 2019-09-22 06:17:54 -04:00
topjohnwu
0e5a113a0c Support patching mnt_point in fstab in dtb 2019-09-22 04:17:15 -04:00
topjohnwu
a1ccd44013 Change MagiskBoot patch behavior
Use environment variables to toggle configurations for patching ramdisk
2019-09-21 05:55:23 -04:00
topjohnwu
4d91e50d6d Update dtb patch to not use in-place modification 2019-09-21 05:30:04 -04:00
topjohnwu
86481c74ff Allow user to select recovery mode
Close #1674
2019-09-08 00:44:26 -04:00
topjohnwu
ee39616a8b Update emulator.sh to support all AVD images 2019-09-04 11:12:09 -04:00
topjohnwu
8cf475f708 Add scripts to setup Magisk in AVD 2019-09-03 17:06:14 -04:00
Chris Renshaw
1283590eeb scripts: prepare addon.d for recovery addon.d-v2 support
- naturally there's no `su` in recovery
- major refactor for common actions and simplicity
2019-09-01 02:19:59 +08:00
osm0sis
dca3fe396f scripts: hide expected x86 busybox error on arm
- Magisk Manager installs have busybox in the $PATH before extracting busybox from update-binary so an error from busybox ash (as sh) attempting to parse the x86 busybox like a shell script would be shown:
./bin/busybox: line 1: syntax error: unexpected "("
- this will only occur when ash tries to run a binary it can't handle, so basically only with x86 binary on an arm* device
2019-09-01 02:19:59 +08:00
topjohnwu
1f8df419c4 Extract x86 busybox first
Fix #1600
2019-07-16 01:16:29 -07:00
topjohnwu
f1112fdf37 Logical Resizable Android Partitions support
The way how logical partition, or "Logical Resizable Android Partitions"
as they say in AOSP source code, is setup makes it impossible to early
mount the partitions from the shared super partition with just
a few lines of code; in fact, AOSP has a whole "fs_mgr" folder which
consist of multiple complex libraries, with 15K lines of code just
to deal with the device mapper shenanigans.

In order to keep the already overly complicated MagiskInit more
managable, I chose NOT to go the route of including fs_mgr directly
into MagiskInit. Luckily, starting from Android Q, Google decided to
split init startup into 3 stages, with the first stage doing _only_
early mount. This is great news, because we can simply let the stock
init do its own thing for us, and we intercept the bootup sequence.

So the workflow can be visualized roughly below:

Magisk First Stage --> First Stage Mount --> Magisk Second Stage --+
   (MagiskInit)         (Original Init)         (MagiskInit)       +
                                                                   +
                                                                   +
     ...Rest of the boot... <-- Second Stage <-- Selinux Setup  <--+
      (__________________ Original Init ____________________)

The catch here is that after doing all the first stage mounting, /init
will pivot /system as root directory (/), leaving us impossible to
regain control after we hand it over. So the solution here is to patch
fstab in /first_stage_ramdisk on-the-fly to redirect /system to
/system_root, making the original init do all the hard work for
us and mount required early mount partitions, but skips the step of
switching root directory. It will also conveniently hand over execution
back to MagiskInit, which we will reuse the routine for patching
root directory in normal system-as-root situations.
2019-06-29 01:25:54 -07:00
topjohnwu
e29b712108 Start Magisk in SAR 2019-06-25 23:31:59 -07:00
osm0sis
ac28e6e5ca Fix uninstaller missing recent changes
- group unsupported formats into the same code (86f778c0aa (diff-93690a8d9f50c177ef97416af3be8726))
- support A only system-as-root devices (e72c6685ed (diff-93690a8d9f50c177ef97416af3be8726))
- remove unnecessary '--' from magiskboot actions (7f08c06943 (diff-93690a8d9f50c177ef97416af3be8726))
- get_flags need to be before find_boot_image (a4f5d47e72)

closes #1371, closes #1431, closes #1439
2019-05-09 20:28:48 -07:00
topjohnwu
fb40e96917 Update outputs 2019-05-01 01:22:37 -04:00
topjohnwu
4ca25f74c6 More robust mounting scripts
Close #1376
2019-04-30 17:35:58 -04:00
osm0sis
7fda917b86 Fix addon.d error OUTFD derp 2019-04-30 17:09:25 -04:00
osm0sis
e6bd5f2c40 Display error if actual Magisk addon.d script cannot be run
- this would likely occur on an FDE device with block map OTAs (a la LineageOS) since they do not require/request decrypt
- for reference all other addon.d "v1" cases should work fine:
  1) FDE with openrecovery script works fine since it requests decrypt
  2) FBE with openrecovery script OR block map work fine since /data/adb remains accessible
2019-04-30 10:27:29 -04:00
topjohnwu
c5758b3f2d Update scripts 2019-04-06 13:04:17 -04:00
topjohnwu
7af7910e78 Revert "Revert to old find boot order"
This reverts commit 5203886f0b.
2019-04-05 15:18:39 -04:00
vvb2060
a4f5d47e72 get_flags need before find_boot_image 2019-04-05 15:18:28 -04:00
topjohnwu
5203886f0b Revert to old find boot order 2019-04-04 20:01:59 -04:00
topjohnwu
91da1cf817 Make on_install happen earlier to allow more customization 2019-03-31 15:37:12 -04:00
topjohnwu
1cd45b53b1 Support recovery based Magisk
Some devices (mainly new Samsung phones we're talking here...) using
A only system-as-root refuse to load ramdisk when booted with boot
no matter what we do. With many A only system-as-root devices, even
though their boot image is kernel only, we can still be able to add
a ramdisk section into the image and force the kernel to use it as
rootfs. However the bootloader on devices like the S10 simply does
not load anything within boot image into memory other than the kernel.
This gives as the only option is to install Magisk on the recovery
partition. This commits adds proper support for these kind of scenarios.
2019-03-30 00:49:48 -04:00
topjohnwu
1c09b3642f Properly setup update flag in module installer 2019-03-27 22:20:39 -04:00
topjohnwu
a199b0ace1 Use ZIPFILE instead of ZIP
The tool zip reads , we don't want it
2019-03-23 20:49:16 -04:00
topjohnwu
2f2108e4e8 Fix typo in module installer 2019-03-23 05:28:43 -04:00
topjohnwu
f9ae4ab475 Add base Magisk module installer script 2019-03-23 04:27:36 -04:00
topjohnwu
b7e2e972c7 Support boot_img_hdr_v2 2019-03-13 16:51:22 -04:00
topjohnwu
7f08c06943 Remove unnecessary '--' from magiskboot actions 2019-03-07 18:07:23 -05:00
topjohnwu
14ae29d907 Support Android Q new init setup 2019-03-03 06:35:25 -05:00
topjohnwu
e72c6685ed Support A only System-as-root Devices
Most Chinese devices (and supposedly Galaxy S10) running Android Pie
is using system-as-root without A/B partition.

https://source.android.com/devices/bootloader/system-as-root#about-system-as-root

According to the docs above, these devices will have a ramdisk block
with size 0 in their boot images. Since magiskinit can run independently
on system-as-root devices, we simply just create an empty ramdisk with
magiskinit added as init.

Huge thanks to @vvb2060 for the heads up and original PR.
Close #980, close #1102
2019-02-28 05:46:36 -05:00
topjohnwu
63b18246d8 Add compressed ramdisk support 2019-02-24 20:39:01 -05:00
topjohnwu
6ca8db2f0c Welcome to the 64 bit world!
Close #854
2019-02-24 08:13:27 -05:00
topjohnwu
3356d7b6ff More friendly to obscure/outdated custom recoveries
Close #1049
2019-02-24 04:45:47 -05:00
topjohnwu
86f778c0aa Group unsupported formats into the same code 2019-02-24 02:30:04 -05:00
topjohnwu
defbbdfe21 Update scripts 2019-02-24 02:11:11 -05:00
HemanthJabalpuri
10613686ed Fix bootloop when removing system SuperSU in <5.0 2019-02-18 03:31:16 -05:00
topjohnwu
1321f097b8 Remove usage of magisk.img
Mounting ext4 images causes tons of issues, such as unmountable with broken F2FS drivers.
Resizing is also very complicated and does not work properly on all devices.
Each step in either measuring free space, resizing, and shrinking the image is a
point of failure, and either step's failure could cause the module system completely broken.

The new method is to directly store modules into /data/adb/modules, and for module installation
on boot /data/adb/modules_update. Several compatibility layers has been done: the new path is
bind mounted to the old path (/sbin/.magisk/img), and the helper functions in util_functions.sh
will now transparently make existing modules install to the new location without any changes.

MagiskHide is also updated to unmount module files stored in this new location.
2019-02-12 02:14:57 -05:00
topjohnwu
ab47b717b1 Reorganize scripts 2019-02-11 17:14:07 -05:00