Magisk General Support / Discussion

Search This thread

pndwal

Senior Member
Mostly I am talking about how the direct install failed. Maybe it was either just the Pixel or 25.0 failing, because of the new init thing. I did not install 25.0, because 25.1 was what popped up for update.
Then I don't understand "Maybe the failed install was caused by 25.0 not 25.1"... 🤔
Yeah. Install to inactive slot always worked for Full OTA, but never for incremental.
and AFAIK, Pixel always used Delta...
I am unsure of what other issues could be causing this. Only guess was maybe I have to deactivate the "Systemless Hosts" module that Magisk installed. I am going to try again with OTA incremental and 25.1. Before I would have to restore old stock and factory reset (because of boot loop), than do the OTA before Magisk and setting things up. I just come here to see if anyone else is having this issue.
Are you talking about need for full data wipe needed in order to install Magisk after an OTA?... IIRC, late Pixels had this issue for a long while... If you're still facing this to boot w/ Magisk 25.1+ after OTA, please say...

Restore images, take incremental OTA, download full ROM matching OTA, extract boot image, patch/flash boot image should work without data wipes generally... PW
 

shoey63

Recognized Contributor
I am on 25.1. Last time I tried to update using OTA incremental was with 24.3.
25.1 should work. If you are hesitant, then change to latest canary. Took an OTA incremental update with it the other day on Pixel 6. Android 13 beta 2 > beta 3.
Forget about your experience with 24.3. Didn't work for Pixels either, but there has many fixes since then.
 
  • Like
Reactions: pndwal
25.1 should work. If you are hesitant, then change to latest canary. Took an OTA incremental update with it the other day on Pixel 6. Android 13 beta 2 > beta 3.
Forget about your experience with 24.3. Didn't work for Pixels either, but there has many fixes since then.
It wasn't just 24.3, though, and not just android 12. I am going to do the update. I just don't like the hassle of going back to straight stock and incremental updating to latest than restoring all my apps. Neo Backup for the win! I will make sure to backup and sync everything to my PC before I do anything.
 

zgfg

Senior Member
Oct 10, 2016
7,583
4,982
Mostly I am talking about how the direct install failed. Maybe it was either just the Pixel or 25.0 failing, because of the new init thing. I did not install 25.0, because 25.1 was what popped up for update.


Yeah. Install to inactive slot always worked for Full OTA, but never for incremental.


I am unsure of what other issues could be causing this. Only guess was maybe I have to deactivate the "Systemless Hosts" module that Magisk installed. I am going to try again with OTA incremental and 25.1. Before I would have to restore old stock and factory reset (because of boot loop), than do the OTA before Magisk and setting things up. I just come here to see if anyone else is having this issue.
Your discussion with @pndwal is getting very interesting.
Sorry if I did not properly catch-up the problem but some thoughts you (both) may think of:

AFAIK, problem with Systemless hosts applies only to (Pixel) devices with f2fs System/SAR - if your System is ext4 filesystem type, no problem.
You can check the filesystem type by eeading (before unrooting) /vendor/etc/fstab.*

Second, Uninstall Magisk (with/without Restore images) would uninstall all modules (incl. Systemless hosts) - wouldn't it?
In that case, manually uninstalling Systemless hosts before that step would not make any difference

Third, if I understand correctly, you are afraid now that due to Delta OTA, you cannot extract the new boot.img to be able to patch.
Also, you say that although you apply Uninstall Magisk (with Restore Images) before OTA but without rebooting, that you are still running root after the Delta OTA

Well, in that case you can disk-dump the Boot from that inactive slot, after the Delta OTA finishes.
For disk-dump you need root - you say you still have it (if I understood properly).
You need to know what's your current slot, hence execute (all from Terminal) and before starting OTA:
getprop ro.boot.slot_suffix

Suppose it returns _b, that means that before OTA, your active slot is B and that your OTA (full or incremental) would apply tothe inactive slot A

After the (incremental) OTA, disk-dump the boot_a.img (ie Boot img from the just OTA updated inactive A slot):
su
dd if=/dev/block/bootdevice/by-name/boot_a of=/sdcard/Download/boot img

You can patch now that boot.img (disk-dumped to Download folder on your Internal memory) by Patch method from the Magisk app

Finally, you need to disk-dump the patched img back to the still inactive slot A:
dd if=/sdcard/Download/<PATCHED IMG> of=/dev/block/bootdevice/by-name/boot_a

And then you are ready to reboot - reboot will switch from the slot B to slot A, that was just OTA updated with Magisk already patched and flashed to it's Boot partiition

---

Finally, I don't see why Magisk should be uninstalled before OTA on these A/B devices.
I know it's safer for many reasons but if you have full control of the situation (understanding how things work, modules you had installed and those potentially incompatible with the OTA), you could instead:

- Restore manually the stock boot.img by disk-dumping before OTA

- Disable only the critical modules before OTA

- After OTA updating and patching/disk-dumping the boot.img (in the still inactive slot) and after rebooting (where the updated slot now becomes active), you will boot and Magisk will be up and running with all (not-disabled) modules, previously granted root, DenyList) - it saves you a lot of time configuring all that once again.
Ie, Magisk database, modules, everything is on /data/adb and therefore it's not affected by OTA

---

Well, suggestions above are not by the Bible (TJW), but we should be able also to think and act out-of-the-box. And generally I like and did experiment a lot with the disk-dumping (I don't have Pixel and incremental OTA but anyway)
 
Last edited:

zgfg

Senior Member
Oct 10, 2016
7,583
4,982
The reason to restore the images is to make sure the soon to be inactive slot is stock for the next OTA update.
I know that VERY well - I said that you disk-dump the boot img manually ti restore stock

If you didn't install custom recovery, it is already stock (if not, flash/disk-dump the stock back)

SAR on A11/A12 is R E A D - O N L Y (Magisk makes makes only systemlessly changes!!!), hence complete SAR (System, Vendor, etc) is untouched by your previously installed Magisk

Magisk modules, db etc are on /data/adb and hence not part of OTA matters

I said, if you understand how these things work (particularly about the Systemless rooting mechanism), you don't need to Uninstall Magisk but instead to pinpoint what is necessary (hints above) manually.
If not, then go by the book...

I would personally kill myself
if I would have to reinstall and reconfigure everything, every time (lot of troubles with some of them to make them work or to properly configure), Viper4Android, Hide My Applist, etc

Therefore I ALWAYS just manually restore the Boot (and Recovery if needed), update the system, patch/flash the new Boot, and happily continue using the Magisk with all my previous modules and everything

But ok, if you are afraid of and/or unexperienced, go by the book
 
Last edited:

BillGoss

Senior Member
Sep 2, 2010
5,292
4,654
Sydney
OnePlus 8T
@dl200010
FYI, on the OnePlus 8T on OOS 11 there used to be two ways of updating:
1. Let the System Update download and install the OTA.
2. Manually download the OTA and then do a manual install in System Updater.
Using the first method your could not use Magisk Install to inactive. That always led to problems.
But the with second method, Magisk Install to inactive worked like a charm.
Now on OOS 12 there are still two options:
1. System update downloads and installs
2. Manually download the update and use a OnePlus apk that lets you do a manual install.
And these two options behave the same way as the OOS 11 versions.

It seems that the update_engine used by the two methods are different and behave differently.

I've written up the various options for rooting and keeping root with OTAs for the 8T. You might want to have a look at it and see if you can get ideas on what you can do for your OnePlus 9.
 

pndwal

Senior Member
Your discussion with @pndwal is getting very interesting.
Sorry if I did not properly catch-up the problem but some thoughts you (both) may think of:

AFAIK, problem with Systemless hosts applies only to (Pixel) devices with f2fs System/SAR - if your System is ext4 filesystem type, no problem.
You can check the filesystem type by eeading (before unrooting) /vendor/etc/fstab.*
F2fs loopback fixes were around in 2017... Huawei and Motorola were slow to fix kernel bug and seems loopback module and other fixes were needed for devices produced till late 2018... I believe Pixel fixed this in their kernels earlier...

I doubt very much this bug has made it into late OnePlus kernels.
Second, Uninstall Magisk (with/without Restore images) would uninstall all modules (incl. Systemless hosts) - wouldn't it?
In that case, manually uninstalling Systemless hosts before that step would not make any difference
No; Uninstall Magisk, Complete Uninstall does this, but Restore Images doesn't touch Magisk configuration files... It does:
make sure the soon to be inactive slot is stock for the next OTA update
by 'restoring partitions modified by Magisk back to stock from backups made at install in order to pass pre-OTA block verifications' however...

/data/avb configuration remains available till next Magisk installation and won't be rebuilt either...
Third, if I understand correctly, you are afraid now that due to Delta OTA, you cannot extract the new boot.img to be able to patch.
Also, you say that although you apply Uninstall Magisk (with Restore Images) before OTA but without rebooting, that you are still running root after the Delta OTA

Well, in that case you can disk-dump the Boot from that inactive slot, after the Delta OTA finishes.
For disk-dump you need root - you say you still have it (if I understood properly).
You need to know what's your current slot, hence execute (all from Terminal) and before starting OTA:
getprop ro.boot.slot_suffix

Suppose it returns _b, that means that before OTA, your active slot is B and that your OTA (full or incremental) would apply tothe inactive slot A

After the (incremental) OTA, disk-dump the boot_a.img (ie Boot img from the just OTA updated inactive A slot):
su
dd if=/dev/block/bootdevice/by-name/boot_a of=/sdcard/Download/boot img

You can patch now that boot.img (disk-dumped to Download folder on your Internal memory) by Patch method from the Magisk app

Finally, you need to disk-dump the patched img back to the still inactive slot A:
dd if=/sdcard/Download/<PATCHED IMG> of=/dev/block/bootdevice/by-name/boot_a

And then you are ready to reboot - reboot will switch from the slot B to slot A, that was just OTA updated with Magisk already patched and flashed to it's Boot partiition

---

Finally, I don't see why Magisk should be uninstalled before OTA on these A/B devices.
Basically because 1) delta OTA won't start if pre-OTA block verifications fail, and 2) boot (and other?) partition(s) has/have been altered by Magisk, so this will bork incremental update even on A/B since inactive slot patching is generated as a function of original active slot data and updated bytes from OTA...
I know it's safer for many reasons but if you have full control of the situation (understanding how things work, modules you had installed and those potentially incompatible with the OTA), you could instead:

- Restore manually the stock boot.img by disk-dumping before OTA

- Disable only the critical modules before OTA

- After OTA updating and patching/disk-dumping the boot.img (in the still inactive slot) and after rebooting (where the updated slot now becomes active), you will boot and Magisk will be up and running with all (not-disabled) modules, previously granted root, DenyList) - it saves you a lot of time configuring all that once again.
Ie, Magisk database, modules, everything is on /data/adb and therefore it's not affected by OTA
And this is also the case with what he been doing! - Uninstall, Restore Images also leaves all this intact...
Well, suggestions above are not by the Bible (TJW), but we should be able also to think and act out-of-the-box. And generally I like and did experiment a lot with the disk-dumping (I don't have Pixel and incremental OTA but anyway)
I think you should be able to use Install to Inactive Slot to 'preserve Magisk after installation' on your A/B Xiaomi whenever an OTA arrives... There are clearly some anomalies w/ OnePlus, but generally the method is not restricted to Pixels. PW
 

J.Michael

Recognized Contributor
Jan 20, 2018
1,252
1,187
Samsung Galaxy Tab A series
The reason to restore the images is to make sure the soon to be inactive slot is stock for the next OTA update.
Maybe I'm misunderstanding your frame of reference, but if "next OTA update" means a future update, after the one you are trying to accept now, then I think the state of the currently-active-soon-to-be-inactive slot will be ignored in that not yet released future OTA update.

If by "next OTA update" you meant the update you are currently trying to accept, then excuse the ring.
 
Maybe I'm misunderstanding your frame of reference, but if "next OTA update" means a future update, after the one you are trying to accept now, then I think the state of the currently-active-soon-to-be-inactive slot will be ignored in that not yet released future OTA update.

If by "next OTA update" you meant the update you are currently trying to accept, then excuse the ring.
You taking the current update depends on if you "restore images" the last time you updated. Because the inactive slot is the one taking the update. Not the current active one.
 

J.Michael

Recognized Contributor
Jan 20, 2018
1,252
1,187
Samsung Galaxy Tab A series
You taking the current update depends on if you "restore images" the last time you updated. Because the inactive slot is the one taking the update. Not the current active one.
Yes, the inactive slot will receive the update. But what it receives is a combination of the active slot and the OTA update. That's why its so important that you return the active slot to the state expected by the people who issued the update. cf. @pndwal's notes.

If you can download a file-set containing a full image of the updated ROM, then you can burn that to either slot. The only problem would be if the official update installer refuses to run unless it is satisfied with the "current" state.

In the case of an incremental update, which consists of records like "replace bytes 17 to 42 with these 92 new bytes", you can't even make sense of the update without the right starting state.

My quibble was with the word "next": if you are currently running v3, and are about to take v4, when you referred to being ready for the "next OTA update", did "next" mean v4 or v5?
 
Yes, the inactive slot will receive the update. But what it receives is a combination of the active slot and the OTA update. That's why its so important that you return the active slot to the state expected by the people who issued the update. cf. @pndwal's notes.

If you can download a file-set containing a full image of the updated ROM, then you can burn that to either slot. The only problem would be if the official update installer refuses to run unless it is satisfied with the "current" state.

In the case of an incremental update, which consists of records like "replace bytes 17 to 42 with these 92 new bytes", you can't even make sense of the update without the right starting state.

My quibble was with the word "next": if you are currently running v3, and are about to take v4, when you referred to being ready for the "next OTA update", did "next" mean v4 or v5?
Yes, by "next" I meant v5.

If you are taking the v4, then currently active is v3 and inactive is v2. You need to restore v3 before installing v4, because when you take v5 v3 will be in inactive with a modified boot and that will fail checks and not install. Unless I am messing something.
 

pndwal

Senior Member
Maybe I'm misunderstanding your frame of reference, but if "next OTA update" means a future update, after the one you are trying to accept now, then I think the state of the currently-active-soon-to-be-inactive slot will be ignored in that not yet released future OTA update.

If by "next OTA update" you meant the update you are currently trying to accept, then excuse the ring.
Good catch!... John says 'The reason to restore the images' is as a prerequisite for available ('next') OTA...
When an OTA is available, first go to (Magisk app → Uninstall → Restore Images)...
This will restore partitions modified by Magisk back to stock from backups made at install in order to pass pre-OTA block verifications. This step is required before doing any of the following steps written below!
https://github.com/topjohnwu/Magisk/blob/master/docs/ota.md#prerequisites

You taking the current update depends on if you "restore images" the last time you updated. Because the inactive slot is the one taking the update. Not the current active one.
Yes, by "next" I meant v5.

If you are taking the v4, then currently active is v3 and inactive is v2. You need to restore v3 before installing v4, because when you take v5 v3 will be in inactive with a modified boot and that will fail checks and not install. Unless I am messing something.
But you are confusing ('messing') things a bit... v3 (inactive with a modified boot) will NOT fail the checks and cause a v5 OTA not to install! - The whole inactive 'slot' can in fact be blank and the OTA will succeed...

The active slot is NOT updated to accommodate a future OTA... Rather, data from active slot is used to generate images to be written to inactive slot in combination with data (binary patches) from the newly available OTA as has been explained... So the active slot is updated to accommodate the current/available OTA...

Of course, Restore Images simply restores current (active) slot to pre-magisk* images using image(s) from /data/magisk_backup_xxxxxxx*, but this is essential for current OTA...

Later OTA's will likewise rely on whatever slot is active at the time, NOT on the inactive slot being updated... In fact, this can be empty / blank / completely erased or corrupt and OTA will still succeed!

Details:
A/B system updates use a background daemon called update_engine to prepare the system to boot into a new, updated version. This daemon can perform the following actions:
• Read from the current slot A/B partitions and write any data to the unused slot A/B partitions as instructed by the OTA package.
• Call the boot_control interface...
• Run a post-install program from the new partition...
https://source.android.com/devices/tech/ota/ab#update-engine

An incremental update is an OTA package that contains binary patches to data already on the device. Packages with incremental updates are typically smaller as they don't need to include unchanged files. In addition, as changed files are often very similar to their previous versions, the package only needs to include an encoding of the differences between the two files.
https://source.android.com/devices/tech/ota/tools#incremental-updates

As mentioned, A/B update engine builds images for inactive slot using original block-verified images from active slot.
During incremental or delta updates, the binary data from the current slot is used to generate the data in the new slot.
https://source.android.com/devices/tech/ota/ab/ab_implement#configuration

*Nb. This further caveat from John is worth noting:
you HAVE to make sure you haven't modified an(y) read-only partitons yourself (such as /system or /vendor) in any way. Even remounting the partition to rw will tamper block verification!!
https://github.com/topjohnwu/Magisk/blob/master/docs/ota.md#ota-upgrade-guides

🤠 PW
 
Last edited:
Good catch!... John says 'The reason to restore the images' is as a prerequisite for available ('next') OTA...

https://github.com/topjohnwu/Magisk/blob/master/docs/ota.md#prerequisites



But you are confusing ('messing') things a bit... v3 (inactive with a modified boot) will NOT fail the checks and cause a v5 OTA not to install! - The whole inactive 'slot' can in fact be blank and the OTA will succeed...

The active slot is NOT updated to accommodate a future OTA... Rather, data from active slot is used to generate images to be written to inactive slot in combination with data (binary patches) from the newly available OTA as has been explained... So the active slot is updated to accommodate the current/available OTA...

Of course, Restore Images simply restores current (active) slot to pre-magisk* images using image(s) from /data/magisk_backup_xxxxxxx*, but this is essential for current OTA...

Later OTA's will likewise rely on whatever slot is active at the time, NOT on the inactive slot being updated... In fact, this can be empty / blank / completely erased or corrupt and OTA will still succeed!

Details:

https://source.android.com/devices/tech/ota/ab#update-engine


https://source.android.com/devices/tech/ota/tools#incremental-updates

As mentioned, A/B update engine builds images for inactive slot using original block-verified images from active slot.

https://source.android.com/devices/tech/ota/ab/ab_implement#configuration

*Nb. This further caveat from John is worth noting:

https://github.com/topjohnwu/Magisk/blob/master/docs/ota.md#ota-upgrade-guides

🤠 PW
So I was missing things. Thanks!
 
  • Like
Reactions: ipdev and pndwal

m0han

Senior Member
Apr 30, 2012
4,992
2,046
I get the feeling this discussion has veered off course because of my comment made in jest (notice the wink). All I meant to opine was @dl200010 did not mess things, but missed things, leading to the confusion that @pndwal was alluding to.
 

Top Liked Posts

  • 3
    Seems so if you're sure you have boot.img matching that ROM (eg. didn't muddle these on PC)... I did suspect borked Magisk configuration .db / files in /data/adb but wipes would have sorted that...

    One other possibility especially if a non-official LOS (but slim chance) is that maintaining dev is using a non LOS standard kernel... Custom kernels requiring AVB stripping using Magisk are also failing post 25.0 due to refactoring... PW
    Yes, it is strange. My solution for this is now official LOS+Magisk 25.2+microG module. Seems to work!
    2
    I too never use she/their injected telemetry releases, i was just referring to her wording 'R.I.P MagiskHide' as you quoted and tested her newest Magisk Detector v3.0 with said, but no prove that MagiskHide detected as promoted
    For riru users, this can be bypassed with MomoHider so this detection is meanless btw
    1
    Not sure if I missed something in this huge thread but I'm having issues with latest Magisk (25.2) with LineageOS microg on a Pixel 4a:
    Everything is ok with the last version of v24 (24.3). But any version of v25 causes the phone not to boot anymore.
    When 25.x is installed it doesn't get past the "Google" splash screen where it stops for a few seconds and reboots, until the "Google" screen appears again with a reboot and so on. Since it doesn't boot Android I can't get a logcat of the crash.
    When reverting to 24.x everything is working without problems.
    I tried installing 25.x through sideloading and patching + flashing the boot.img directly on the device.
    Am I missing anything here?
    You might want to consider utilizing this method.
    1
    Not sure if I missed something in this huge thread but I'm having issues with latest Magisk (25.2) with LineageOS microg on a Pixel 4a:
    Everything is ok with the last version of v24 (24.3). But any version of v25 causes the phone not to boot anymore.
    When 25.x is installed it doesn't get past the "Google" splash screen where it stops for a few seconds and reboots, until the "Google" screen appears again with a reboot and so on. Since it doesn't boot Android I can't get a logcat of the crash.
    When reverting to 24.x everything is working without problems.
    I tried installing 25.x through sideloading and patching + flashing the boot.img directly on the device.
    Am I missing anything here?
    You might want to consider utilizing this method.
    Yup... And we've just been discussing this same issue again... here's some options/reason:
    Ok, so you can simply extract boot image from that ROM and patch with Magisk App, then flash w/ fastboot or TWRP... I'd do that...

    You can also take Magisk App option Uninstall Magisk, Restore images (no need for Complete uninstall - Magisk config, modules etc can be present) after which custom recovery installation of Magisk as a zip installer should succeed.

    Nb. Your issue is the refactoring of magiskinit injection in Magisk 25+ affecting many 2SI devices ... I put info about it here around June 23...

    Your device used legacy ramdisk boot method originally, but was converted to 2SI booting w/ update to Android 10... PW
    👀 PW
    1
    Thank you!
    I' not sure if I understand it correctly:
    When upgrading to 25.x and it bootloops I simply reflash the patched boot.img again?
    Please see post above re. 2SI refactoring...

    Only previously patched images are rendered incompatible due to changes with magiskinit, so Direct Install is broken. Patching and flashing an unpatched image should work fine however, and later Direct Installs will work... PW
  • 6
    Its trivial to sniff or even MITM a desktop, or even just run WinPE and reset admin password and use the users own saved passwords in their browser, heck even export their passwords....

    In any event the biggest risk vector is social engineering

    Chasing root phone users only gives them a "feelgood", it does nothing to stop genuine misuse and fraud, at all.....

    I dont see Google or a bank sending out a representative every time someone makes a transaction to see if theyre genuine....trying to control the device is attacking the wrong end of the transaction and is ultimately pointless
    They're not chasing root users. They just want a guarantee that the device is secure, and they have good reason to. Rooting by nature compromises device security.

    I'm not saying your opinion is invalid; in this context however, it is irrelevant, because regardless of how you may feel about the situation, it's not going to change.
    5
    And I solved it. Thanks to everybody that helped me. @zgfg idea of working on data/adb/magisk.db prompted me to investigate how to reach there. MiXplorer did not have root access granted forever, so it wasn't working. Ended up using adb and, through commandline removed everything releated to Magisk in there. Uninstalled the app, flashed the standard boot.img, installed the app, flashed the patched boot.img, rebooted and... success! 🙃

    It only took me six hours or however much it's been. Now let's hope I can reactivate hiding features, etc.
    5
    Latest Official TJW public Stable (release) Magisk build:

    Magisk

    2022.7.20 Magisk v25.2​

    Maintenance release fixing various issues.
    • [MagiskInit] Fix a potential issue when stub cpio is used
    • [MagiskInit] Fix reboot to recovery when stub cpio is used
    • [MagiskInit] Fix sepolicy.rules symlink for rootfs devices
    • [General] Better data encryption detection
    • [General] Move the whole logging infrastructure into Rust

    Full Changelog: here

    https://topjohnwu.github.io/Magisk/releases/25200.html

    🎉🎊 PW
    5
    I'm also done with this conversation, because you seem to be going out of your way to be obtuse about it. You specifically mentioned that rooted users are a microscopic minority. None of these corporations enacting the security measures are going to go out of their way to make security exceptions for the tiny fraction of android users that are rooted users.
    Let's not forget the security issues that rooted devices present. App developers for the aforementioned banks, etc are extremely concerned with operating in a secure environment. You wouldn't want a third party to be able to view, let alone manipulate, your financial transactions, but a rogue process with root permissions could potentially do exactly that - read account numbers, command unauthorized transactions, and worse. Think of it like a malware browser extension that could give a remote party access to your bank account.

    From the developer perspective, every single rooted device is a compromised security environment, and this is 100% true. There is no easy way to determine whether the end user is using root carefully with vetted applications, or if the device has been hijacked by a malicious rootkit. So, developers use methods such as SafetyNet, Play Protect Certification, and the new Play Integrity API as a means to try to verify the security environment of the device.

    Try to look beyond your own inconvenience as a rooted user and understand this concept. The end answer is simple: If you want an app to work correctly on your device, do not modify your device or software.
    5
    @pndwal You can build Magisk app with custom name and label as you want
    MagiskHide is still effective to hide root from banking apps. It's not dead if you don't care about safetynet stuff.


    Shamiko is taking off your panties on the basic of MagiskHide. So MagiskHide is still better.
    You believe Shamiko too much, It can't really hide zygisk, only fix the zygisk detection of Momo. However, I can't blame it because that was the nature of zygisk and it will never be fixed.
    Still not sure what you're trying to tell me...

    I think we agree on most of this stuff (except your apparent impression that Shamiko Devs have some sort of sexual agenda, or that it's users are somehow prone to 'self abuse'... I won't use the other term either...).

    If you think I have misrepresented any facts regarding Magisk, Shamiko or other, please say it plainly... I think what I provided for the sake of clarity was accurate... 🙁 PW
  • 1084
    This is the place for general support and discussion regarding "Public Releases", which includes both stable and beta releases.
    All information, including troubleshoot guides and notes, are in the Announcement Thread
    156
    Hello, I haven't given much support on XDA lately. It can be resulted from
    • University started and I have limited free time. In fact, I mostly develop during midnight
    • I live in Taiwan, which has large time zone differences between my European/American contributors/testers, which usually forces me to stay up late at night to discuss/test stuffs.
    • The new version is about to come, I don't want to spend effort on supporting old releases
    The planned update is delayed again and again, to some point I think I'll shed some light about what has been happening lately, also along with some announcements.

    New Forum!
    As you might have already discovered, Magisk got its own subforum on XDA! Many thanks to all the support you gave me, and much more information/features/support is about to come!
    **For developers supporting all the devices that are not using standard Android boot format, feel free to create threads in this section (actually, PLEASE do so) for your favorite devices after v7 is out. As I currently know, Asus devices require signing the boot image before flashing, and is model dependant; Sony devices seems to use ELF kernel that is unpatchable, or some has two ramdisks (inner + outer), both requires different workarounds; LG bootloader locked devices has to manually "BUMP" the boot image after flashing Magisk..... and there may be lots of other crazy boot image formats that haven't come up to my attention yet.
    It is impossible for me to support all these non-standard boot images, and I hope the community can collaborate to make Magisk running across all the devices. Overall, community collaboration is what XDA about :D

    The Pixel Phone
    Some of you might already know this news, that the next Pixel Phone right around the corner seems like it does not have ramdisk in boot image, which pretty much wrecked Magisk in all ways. However, it pretty much doomed root itself too. Kernel modifications is inevitable IMO, so I'll try to migrate my scripts to C programs that could possibly be included into the kernel itself. Note that I'm not familiar with linux kernel, I'm not even sure if my idea and concept is correct or not. But once the device is available, I think developers will find a way to bypass all the difficulties, and I'll do my best to learn things ;)

    Current Progress
    In the past month, I've spent quite some time learning SELinux, so that I can avoid using SuperSU's sepolicy patches. Thanks to the helps and tips from @phhusson and @Chainfire, I finally have a much clearer understanding of how SELinux works. The Magisk core parts (the scripts, boot image patches, new features, more supports) are actually done some time ago. What is causing all the delays is the Magisk Manager.
    To be completely honest, although I can code in Java without much issues, Magisk Manager is actually my first Android application, I had to reach out for assistance, and fortunately awesome developers like @DVDandroid and @digitalhigh contributed a lot, which makes the current Manager awesome.
    After the repo system and module management is mostly done, I was about to do some adjustments and release, but what we really done is decided to add another feature: auto-unroot with per-app settings. I decided to wait for it to be finished, and then do my adjustments. Due to reasons that'll be mentioned later, this feature will likely not be available for the next release (should come in future updates)

    Safety Net Disaster
    Those who are using Magisk for Safety Net bypass purposes must have known that Google recently updated the detection method of my Systemless Xposed. I still have no idea what Safety Net is detecting, so currently I cannot fix it on my side (also because I'm busy working on the next update). However, suhide developed by @Chainfire is able to hide Xposed and worked fine.
    However, only my Systemless Xposed v86.2, which is based on SuperSU's su.d, is supported using that method. v86.2 and v86.5 (latest, Magisk based) have nearly identical binaries, and the only difference is the path where the binaries are stored.
    I'm still not sure what's the real issue for it not being supported, I just hope it is not done intentionally.

    Conclusion
    Due to the fact that my Safety Net bypass is not 100% perfect now, I do not want to spend any more time waiting for auto-unroot to be polished. What I'm doing now is finishing up all the things I'd like to change in Magisk Manager (it has been a while since I last contributed to Manager, my fellow developers are doing all the heavy job), which might take a little more time, after that, packed with tons of information to be announced in Magisk Section, I'll release the long awaited update.

    Hope this lengthy post gives you the idea of the whole situation, and again thanks for all your support!!
    121
    Ah, some Chainfire bashing, I hope it is not too late for me to exercise additional villainy.

    First, let me make clear I have nothing against @topjohnwu, nor against Magisk. Magisk is an interesting project and it certainly displays @topjohnwu ingenuity and persistence. I don't doubt we will see more interesting things from his hands.

    -------------------------

    What has happened here is not all that dark and complicated, from either end. I returned from holidays, and someone pointed me at Magisk. My first thought: interesting!

    Among other things, the thread lists some issues with SuperSU, which in combination with the phrase The developer also requests users to not bug Chainfire with compatibility requests for SuperSU with Magisk from the portal article, raised my left eyebrow by nigh half an inch. The popular systemless xposed mod is apparently now based on it, and apparently it now no longer works with SuperSU, and apparently I'm not supposed to fix that, nor any of the other found issues. I found that a bit weird. So yes, I have told @topjohnwu that I was a bit surprised he was posting about issues with SuperSU without notifying me about them (I can't fix or help fix issues I'm not aware of, after all).

    He's also spreading a modified version of the SuperSU package, which is not all that uncommon, nor necessarily a problem. I have not looked into what he modified, I only ran a few quick tests on one of my devices, and found some commonly used commands run as root to be broken. I have informed him of this as well.

    It appears the tool of choice for Magisk is phh's Superuser, because of some of the mentioned issues with SuperSU. That's fine by itself, but fixing issues in that superuser by incorporating SuperSU's binaries into it is a somewhat questionable practise. After all, SuperSU is a commercial closed-source package that helps pay for my dinner, and superuser is a direct competitor. I have informed him that I was surprised he did this without asking for permission. I have expressed similar surprise on him spreading a modified version of LiveBoot (which helps pay for a snack now and then).
    @topjohnwu has also stated that Magisk's scripts are largely influenced by mine (I have not checked). Scripts based on mine are used all over the place on XDA, some people have crafted amazing things based on them, I have never made an issue of this (otherwise I would have just made them binaries). But yes, I have also stated to him that I don't think it's very nice to base something on one program, and then using that to (almost exclusively) push something directly competing with that program.

    tl;dr Towards @topjohnwu, I have:
    - expressed surprise he has issues getting Magisk to work with SuperSU, and has chosen not to inform me about those
    - expressed surprise he is using SuperSU binaries in a competing superuser without permission
    - expressed surprise he is posting a modified LiveBoot without permission
    - informed him of issues with the modified SuperSU he has posted
    - let him know I thought it wasn't very nice to be applying my scripts to benefit seemingly exclusively that same competing superuser

    To be crystal clear:
    - I have not asked for an apology
    - I have not asked for Magisk to be abandoned, neither the root hiding nor systemless module parts, and certainly not systemless xposed
    - I have not made an issue of any of this anywhere, until this post
    - I have not even specifically asked for anything to be taken down (though obviously in my opinion the other superuser package mixed with SuperSU's binaries, as well as the LiveBoot package, should go)
    - I have not reported this thread to XDA moderators for copyright violations or otherwise

    While my conversation with @topjohnwu may not win any awards for being friendly (though it may win some for brevity), I think all things considered my response has been rather mild. To be perfectly honest, until the apology post, I thought this was over with already. I think the apology post was triggered because I haven't replied to his last PM for a while - I was in the zone, it happens.

    To emphasize again, I have nothing against @topjohnwu, Magisk, or systemless xposed, and it is certainly not my goal to see any of them go. If it can be made to work together with SuperSU, great.

    I get it though: you think of something, you want to see if you can make it work, you finally get it to work, you publish it, it takes off - enthusiasm gets the better of you. Maybe in the rush some mistakes are made. That doesn't mean you have to just drop it and run. None of my stuff would make it past 0.1 if I stopped at the first big mistake :)

    Aside from said being in the zone coding, I usually regret actually responding to these sort of things the day after, which has made me hesitant to reply. Surprise me.
    76
    Thread temporarily closed so everyone sees this.

    The flood of "SafetyNet isn't working for me either!" posts are not helpful, at all. Please refrain from posting further, it will be looked into. Please do not forget that not passing SafetyNet is 100% NORMAL AND INTENDED when you have an unlocked booloader or running custom firmware. These are workarounds and they will be worked around in turn.

    The Flash
    Forum Moderator

    EDIT: Thread is reopened... I will be cleaning any SafetyNet posts for a while to keep the thread clean for real issues.
    75
    Hello everyone!

    I am aware that Google has updated Safety Net that makes Magisk itself a no go for Android Pay. In fact, I witnessed the change live while I am developing the new magiskhide, which should hide all Magisk modules and Magisk installed root.

    Google is serious about Safety Net now, clearly hunting down all possibility to run Xposed with Safety Net passed. I spend quite some time examining the new security measures last midnight, and fortunately it seems that it is possible to run Magisk and root along with Safety Net if no Xposed is running. I'm glad I removed the old root toggle at the right time lol, that is no longer feasible with the latest detection.

    So stay tuned for the next update, it will come with bug fixes, along with the new magiskhide to bypass that Safety Net.

    Google, how will a few systemless mods do any harm :p:p