Commit Graph

267 Commits

Author SHA1 Message Date
Alessandro Astone
ab9442d4ae
Fixup mounting system on Lineage Recovery
* Lineage Recovery 17.1, like AOSP Q recovery, has '/' as a shared
   mount point, causing `mount --move` to fail.
   If it fails, directly mount system to /system_root via
   /dev/block/ symlinks, like AnyKernel and OpenGapps

Co-authored-by: John Wu <topjohnwu@gmail.com>
2020-03-08 22:38:47 -07:00
osm0sis
f5c099e9a7 scripts: fix addon.d after merge to trampoline
- pass addon.d arguments through trampoline or nothing will happen
- exit immediately after handing over from trampoline
- better grep for recovery OUTFD which should work in all cases
- output to logcat when booted and no binaries are found
- use /postinstall/tmp path to call functions from addon.d-v2 in progress
- remove unnecessary check for $MAGISKBIN since we're already executing from within it
- make sure we're not in $TMPDIR again before we delete it
- use $MAGISKBIN wherever possible in case it ever needs to be changed
2020-03-08 22:33:19 -07:00
topjohnwu
db9a4b31f9 Update scripts to use BusyBox standalone mode 2020-03-08 22:25:06 -07:00
topjohnwu
740559e3bc Fix int detection in scripts 2020-02-10 16:45:44 -08:00
topjohnwu
b3bc1a3907 Merge addon.d scripts 2020-02-09 03:07:49 -08:00
topjohnwu
4dd8d75cc0 Update scripts 2020-02-08 03:26:39 -08:00
osm0sis
45d5b4bea6 scripts: recovery addon.d-v2 and env fixes
- recovery addon.d-v2 requires /system and /system_root stay mounted
- find OUTFD from recovery update_engine for addon.d-v2 output
- fix finding OUTFD on addon.d failure with toybox ps
- simplify heredoc creation
- update to longer apex BOOTCLASSPATH
- save and restore any mountpoint symlinks encountered

Closes #2284
2020-02-07 21:56:28 -08:00
osm0sis
f2d2f28e23 scripts: fixes for Tegra partition naming + bootsigner on Android 10
- adjust mount scripts to support SOS, APP and CAC Tegra partition naming (vendor is still vendor, oddly)
- -Xnodex2oat is removed on Android 10 in AOSP (despite it still erroneously showing in dalvikvm --help); older devices will still run safely without it
- Android 10 dynamically linked binaries need APEX mounts and variables so add this to recovery_actions/cleanup (thanks @Zackptg5)
- clean up known systemless root leftovers because we're helpful
2020-02-01 01:09:12 +08:00
topjohnwu
b39f407596 Load libsqlite dynamically 2020-01-11 03:20:59 +08:00
topjohnwu
3049a81c3b Update several scripts
- 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
2020-01-01 14:02:44 +08:00
topjohnwu
46ba726232 Match exact "SKIPUNZIP=1" to prevent confusion 2019-12-29 15:16:04 +08:00
topjohnwu
7f667fed18 Allow customize.sh to skip unzip
Close #2184
2019-12-29 00:45:49 +08:00
topjohnwu
025b060506 Exclude META-INF in unzip 2019-12-28 02:33:35 +08:00
topjohnwu
b336655a79 Brand new module installer script
The new module installer script completely changes the way how module
installer zips are structured. More info will come later in docs.

The new installer script also supports installing sepolicy.rule to
persist partitions in order to make the module work on the next boot.
2019-12-27 17:53:27 +08:00
topjohnwu
06c42d05c3 Drop image based Magisk support 2019-12-15 21:01:12 -05:00
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