If Magisk is working, get the APK of the version you want, change the name of the file so it ends in ".zip", and use the Magisk manager app to install it as if it were a module.
Magisk General Support / Discussion
- Thread starter topjohnwu
- Start date
That old method is still valid if the appropriate TWRP (more generally, a custom recovery, it could be OrangeFox, SHRP, etc) exists for the particular phone and ROM
However, there are phones for whom no custom recovery was ported
Or worse, there is a custom recovery (like TWRP) but it does not support storage encryption, etc
For those reasons, and to avoid reports being wrongly addressed to Magisk: "I flashed Magisk through TWRP but it did not install properly" or similar - John does not recommend flashing Magisk through TWRP and instead he recommends the patch and flash method
---
Hence to put it simple - if you know that on your same phone, with the same TWRP and the same ROM you previously and successfully used TWRP to flash Magisk, then no reason it should not work properly again
But if you upgraded the ROM, particularly the Android version, then there is a chance that your old TWRP may not work properly anymore
Hence it depends (there is no definite answer Yes or No). You should know for your phone/ROM/TWRP or you should try
This with @mrjuniork's leave (thanks):
Alpha has been around for a long while, and was originally vvb2060's (Nangong Xueshan's) personal fork. It was not a group effort, and still probably isn't, although vv may well oblige other LSP Devs like @canyie with experimental support for new Shamiko functions etc; after all theses Devs all contribute to that now.
'Alpha' experimental builds go back to 2018 with 'Lite' and 'MTK' builds going back at least to May 2020.
These were clearly test builds for fixes later to be merged into official Magisk with feedback/testing provided by Devs native Chinese Telegram community, and Magisk would be completely different if it hadn't been for them. However, until recent times, Alpha and other forks have gone relatively unnoticed despite their impact.
Alpha was always basically the test fork for vv's fixes, and her changes have been at the forefront of Magisk development for some years now... So many major innovations in official Magisk have been developed in vv's Alpha fork and in her lesser known Lite, MTK and other branches...
Just to mention a sampling I posted more than a year ago: MTK compatibility, single package delivery, 64bit support, sepolicy fixes, several isolated process fixes, fixes for UID, MicroG, process names, file based encryption, mount rules for Sammy, auto-close issues bot, reboot menu, multi-user and shared user id compatibility fixes, hidden apps, Chinese doc translations, offline restore app, unsupported environment checking, fix for apex path (a big one), permission fixes, module Installation fixes, Kotlin code cleanup, MagiskHide stopping fix, Renamable App / single package Magisk archive (developed in cooperation with John).... And countless more recent commits for various devices/compatibility, new functionality and major refactoring of magiskinit injection, sepolicy rules and so on...
As @zgfg mentioned, users here have been testing / discussing @vvb2060's innovations for a good while; Existing Magisk is already very much @vvb2060's, and she is now not just a contributor but an official Magisk Dev...
Far from 'pulling/changing a commit or two, likely small things like package name and update channel', Alpha has added/tested many major innovations and compatibility fixes before they were ever merged in Canary... Alpha is a prime reason John has made comments like:
I had already posted about vv's Alpha, and Lite (test branch for whitelist MagiskHide hidelist for bypassing isolated process leak detections banks had started using) Magisk forks but switched to Alpha for daily use in May 2021 simply because (with his new Android Security job) John was no longer updating official Magisk and this was a way to test fixes in the melting pot without any Canary builds available...
After posting about my Alpha use experience (I said there is "presently no better substitute for Canary builds with regular updates that I'm aware of"), several members here like @zgfg also moved to Alpha in or after August 2021. This was because John had not produced Magisk updates for many months pending the result of Google's internal review of his open-source project as a new 'big tec' employee (see https://topjohnwu.medium.com/state-of-magisk-2021-fe29fdaee458 ), but was now again making commits/fixes in Magisk channels as he, along with vvb2060 and other Devs, was developing new Zygisk Magisk hooking functionality... This was a fairly long process including replacing much MagiskHide/HideList code with the different if simpler DenyList, and still no Canary builds were forthcoming until October 24...
Alpha allowed many of us to test John's official commits (vv was largely focused on testing and contributing to John's changes at this time also) and early Zygisk / Denylist during those 3 months without the need to build personal Magisk 'snapshots' ourselves... (Of course there would also have been official CI builds available, but Alpha had the advantage of filtering out most broken test builds.) This is the period @zgfg was referring to in his post; effectively, as you put it, 'Alpha was before Canary' at least in publishing test builds publicly for some 3 months...
In October, with Zygisk in 23010, most of us moved back to official Canary for daily use/testing.
Lastly, John has never 'denounced' Alpha (or vv) for using the Alpha name; he simply stated:
... It seems that vv was quite agreeable too, and that Alpha discussion group you mentioned even hosted a contest to choose a new name... In the end it seems changing the package name from Magisk to Alpha was mutually acceptable however (so it's just Alpha, not Alpha Magisk)...
Hope this little (recent) history lesson helps.
PW
Edit: Please be careful if responding to this.
Not sure who you're addressing here or accusing, but who's spreading lies? And who ever suggested John was part of any 'Alpha' group?!... No one's lying that I've seen...
... Seems you may be responding to @zgfg's post here, but let me clarify for everyone:
Alpha has been around for a long while, and was originally vvb2060's (Nangong Xueshan's) personal fork. It was not a group effort, and still probably isn't, although vv may well oblige other LSP Devs like @canyie with experimental support for new Shamiko functions etc; after all theses Devs all contribute to that now.
'Alpha' experimental builds go back to 2018 with 'Lite' and 'MTK' builds going back at least to May 2020.
These were clearly test builds for fixes later to be merged into official Magisk with feedback/testing provided by Devs native Chinese Telegram community, and Magisk would be completely different if it hadn't been for them. However, until recent times, Alpha and other forks have gone relatively unnoticed despite their impact.
Alpha was always basically the test fork for vv's fixes, and her changes have been at the forefront of Magisk development for some years now... So many major innovations in official Magisk have been developed in vv's Alpha fork and in her lesser known Lite, MTK and other branches...
Just to mention a sampling I posted more than a year ago: MTK compatibility, single package delivery, 64bit support, sepolicy fixes, several isolated process fixes, fixes for UID, MicroG, process names, file based encryption, mount rules for Sammy, auto-close issues bot, reboot menu, multi-user and shared user id compatibility fixes, hidden apps, Chinese doc translations, offline restore app, unsupported environment checking, fix for apex path (a big one), permission fixes, module Installation fixes, Kotlin code cleanup, MagiskHide stopping fix, Renamable App / single package Magisk archive (developed in cooperation with John).... And countless more recent commits for various devices/compatibility, new functionality and major refactoring of magiskinit injection, sepolicy rules and so on...
As @zgfg mentioned, users here have been testing / discussing @vvb2060's innovations for a good while; Existing Magisk is already very much @vvb2060's, and she is now not just a contributor but an official Magisk Dev...
Far from 'pulling/changing a commit or two, likely small things like package name and update channel', Alpha has added/tested many major innovations and compatibility fixes before they were ever merged in Canary... Alpha is a prime reason John has made comments like:
I had already posted about vv's Alpha, and Lite (test branch for whitelist MagiskHide hidelist for bypassing isolated process leak detections banks had started using) Magisk forks but switched to Alpha for daily use in May 2021 simply because (with his new Android Security job) John was no longer updating official Magisk and this was a way to test fixes in the melting pot without any Canary builds available...
After posting about my Alpha use experience (I said there is "presently no better substitute for Canary builds with regular updates that I'm aware of"), several members here like @zgfg also moved to Alpha in or after August 2021. This was because John had not produced Magisk updates for many months pending the result of Google's internal review of his open-source project as a new 'big tec' employee (see https://topjohnwu.medium.com/state-of-magisk-2021-fe29fdaee458 ), but was now again making commits/fixes in Magisk channels as he, along with vvb2060 and other Devs, was developing new Zygisk Magisk hooking functionality... This was a fairly long process including replacing much MagiskHide/HideList code with the different if simpler DenyList, and still no Canary builds were forthcoming until October 24...
Alpha allowed many of us to test John's official commits (vv was largely focused on testing and contributing to John's changes at this time also) and early Zygisk / Denylist during those 3 months without the need to build personal Magisk 'snapshots' ourselves... (Of course there would also have been official CI builds available, but Alpha had the advantage of filtering out most broken test builds.) This is the period @zgfg was referring to in his post; effectively, as you put it, 'Alpha was before Canary' at least in publishing test builds publicly for some 3 months...
In October, with Zygisk in 23010, most of us moved back to official Canary for daily use/testing.
Lastly, John has never 'denounced' Alpha (or vv) for using the Alpha name; he simply stated:
... It seems that vv was quite agreeable too, and that Alpha discussion group you mentioned even hosted a contest to choose a new name... In the end it seems changing the package name from Magisk to Alpha was mutually acceptable however (so it's just Alpha, not Alpha Magisk)...
Hope this little (recent) history lesson helps.
PWEdit: Please be careful if responding to this.
Last edited:
That should work for 25.2, but may not work properly going forward... Due to recent refactoring you'd only get limited Magisk from 25207, and, depending on fixes it may still not work w/ 25211...
Flashing .zip as module from Magisk App is better because this (and issues others mention above) don't exist when boot image is patched with system booted...
Of course there are other way to bypass version checking/downgrade prevention but this is the simplest method I've seen...
Further, when downgrading especially, it can be necessary to wipe Magisk configuration to avoid issues with changes in magisk.db or Magisk directories made for newer builds... Neglecting this may cause confusing issues...
You can simply delete /data/adb/magisk.db and contents of /data/adb/magisk (this leaves modules) after flashing the downgrade.zip (can be before rebooting) and these configuration files/directories will be rebuilt clean on reboot...
PW
Last edited:
That didnt work for me. I installed stable as module, cleared directory and magisk.db and now im at version 25200 App and 2510 magisk and though systemless Module showed Up finally, adaway refuses His Job...
Do you mean 25.1 Magisk?... So you used 25.1 package for.zip... anyway, you can simply take Direct Install from current 25.2 App to get 25.2 Magisk since you no longer need downgrade prevention bypass...
Edit: If you mean 25210 Magisk you should ensure you download and use 25.2 package (click v25.2 in Magisk GitHub main page) for .zip installation as module to downgrade Magisk (core binaries running) to last Stable release... PW
Last edited:
I believe you mean 25210 which is broken and loads no modules including systemless hosts, roll your boot back to 25209 or stable
Pixel 7Pro stable march SP.
Some modules didn't work properly with Magisk stable 25.210, but work on 25.209 (V4A, Lsposed, PLE,....).
It seems last stable broke something.
Some modules didn't work properly with Magisk stable 25.210, but work on 25.209 (V4A, Lsposed, PLE,....).
It seems last stable broke something.
Good morning - after about three weeks
I totally forgot to come and see on XDA if the problem was known. It is ^^
Can someone please help me in hiding the root for Yes bank app. I was able to hide the root from all the banking apps but no luck with the yes bank after recent update. I have hidden it from denylist in magisk added to hide my list, also enabled it with in lsposed app hide my list app. All the other apps are working fine except this. Is there a way to find which app is the reason for the root detection. CTS profile, playstore is certified too.
play.google.com
YES BANK - Apps on Google Play
YES Mobile 2.0 is completely new and revamped mobile banking application.
I'm not any expert ... But... OnePlus 7T on OOS12 (latest) and official magisk stable 25.2 (not hidden) with enforce denylist with Yes bank on deny list gets me past the root detection error I got before adding into deny list in magisk.... So may be force stop Yes bank then clear data/cache... ? Worked for me to get to the registration screen without error. I don't have/use lsposed so I'm unable to assist with that matter. Clear data and retry?Can someone please help me in hiding the root for Yes bank app. I was able to hide the root from all the banking apps but no luck with the yes bank after recent update. I have hidden it from denylist in magisk added to hide my list, also enabled it with in lsposed app hide my list app. All the other apps are working fine except this. Is there a way to find which app is the reason for the root detection. CTS profile, playstore is certified too.
YES BANK - Apps on Google Play
YES Mobile 2.0 is completely new and revamped mobile banking application.
EDIT: to add that my device is OEM unlocked...
And.. universal safetynet fix v2.3.2 mod 2.1 kdragOn mod by displax
Unable totake screenshots of bank app due to sensitive information on registration screen...
And I don't use Yes....
Last edited:
My device:Can someone please help me in hiding the root for Yes bank app. I was able to hide the root from all the banking apps but no luck with the yes bank after recent update. I have hidden it from denylist in magisk added to hide my list, also enabled it with in lsposed app hide my list app. All the other apps are working fine except this. Is there a way to find which app is the reason for the root detection. CTS profile, playstore is certified too.
YES BANK - Apps on Google Play
YES Mobile 2.0 is completely new and revamped mobile banking application.
Xiaomi RN8T stock A11 MIUI
Magisk Canary 25209
Latest Shamiko public release (for proper root hiding]
[LSPosed Hide My AppList, but not needed for this app]
This app is detecting OEM unlocking when enabled in Developer options (even if enabled with developer options disabled)... With the above setup I get:
With OEM unlocking disabled:
... It's not detecting USB debugging or Developer Options itself...
I have disabled OEM unlocking on my device and rebooted and all is fine... While I believe this is normally safe with the important exception of Magisk use with relocked bootloader (ie. with custom keys set to allow relocking with custom mods incl. Magisk etc), I'm not certain of this... Others may like to verify the safety of disabling OEM unlocking with normal (unlocked device) Magisk use...
The App can be used by disabling OEM unlocking before a reboot however, so you can always enable it again before a reboot...
Hope this fixes your issue!
PWAccessibility service(not granted to the app) andMy device:
Xiaomi RN8T stock A11 MIUI
Magisk Canary 25209
Latest Shamiko public release (for proper root hiding]
[LSPosed Hide My AppList, but not needed for this app]
This app is detecting OEM unlocking when enabled in Developer options (even if enabled with developer options disabled)... With the above setup I get:
View attachment 5872335
With OEM unlocking disabled:
View attachment 5872341
... It's not detecting USB debugging or Developer Options itself...
I have disabled OEM unlocking on my device and rebooted and all is fine... While I believe this is normally safe with the important exception of Magisk use with relocked bootloader (ie. with custom keys set to allow relocking with custom mods incl. Magisk etc), I'm not certain of this... Others may like to verify the safety of disabling OEM unlocking with normal (unlocked device) Magisk use...
The App can be used by disabling OEM unlocking before a reboot however, so you can always enable it again before a reboot...
Hope this fixes your issue!
VPN (Netguard) also seem to trigger it's sensitivity
Attachments
Have you tried using the appCan someone please help me in hiding the root for Yes bank app. I was able to hide the root from all the banking apps but no luck with the yes bank after recent update. I have hidden it from denylist in magisk added to hide my list, also enabled it with in lsposed app hide my list app. All the other apps are working fine except this. Is there a way to find which app is the reason for the root detection. CTS profile, playstore is certified too.
YES BANK - Apps on Google Play
YES Mobile 2.0 is completely new and revamped mobile banking application.
In parallel space/shelter/insular/island ?
... Guess those are additional issues on your device with your setup (and your solutions may help if the member uses similar settings)...
However the member specifically said:
... OEM unlock triggers the "device appears to be rooted" Security Alert notice...
The Security Alert notices you show concern different issues... PW
True...
"Is there a way to find which app is the reason for the root detection"
Don't use yes Bank...
was just helping out in diagnosing the issue.
Rooted with delta and magisk hide...
Don't get OEM unlock error
(maybe it doesn't trigger on delta).
Btw the user did not upload any screenshots
Of his detections...
would help more in identifying the issue
If I correctly understand your screenshots, for Accessibility and VPN you have options to Close the app or Skip (and continue to use)?
I had a similar case with one MDM - it found Accessibility and warned but let me continue
Btw, Ruru also warns about Accessibility (screenshot)
It will be stupid if banking and similar apps prohibit the use of regular Google features like Accessibility (users with disabilities) and VPN (users may need for their work)
Attachments
Yeah, I removed the ref. to 'app' in quoting this above as it seems app detection isn't triggered 'root found' Alert... OEM unlocking enabled is... The question simply assumes it would be an app but that's a red herring; the app in question starts without even using HMA...
I don't either... But only because I prefer No Bank...
And there may be further issues...
Maybe...
Is OEM unlocking already disabled in Developer Options?
Also, what USNF version are you using?...
Can you check /data/adb/modules/safetynet-fix/service.sh to see if the lines highlighted (at the end) here:
https://github.com/kdrag0n/safetyne...e9b5d57eb43446f4954/magisk/service.sh#L57-L60
exist?...
That OEM unlock prop change in USNF was proposed and finally rejected by @kdrag0n and removed from @Displax patch set (later merged in official USNF)...
It may still exist in older or forked USNF builds, and may also have been added in other hide-solution mods...
mmm... But said 'root' detected, so seems it's per my 'Alert' screenshot... PW
Last edited:
Similar threads
Top Liked Posts
-
2
I have run into it (every now and then) updating Magisk using a previously patch image.
- Magisk patched boot image detected
Bootloop and/or a forever (infinite) boot.
If it is just updating Magisk, use a clean (stock) boot image.
In your case, the stock Lineage 18.1 boot image.
For me, if the update failed..
- I normally flash the stock boot image back and reboot.
Since I still have the newer Magisk app (Manager) installed.
- Push the stock boot image to the device (if it is not already there).
- Use the "Select and Patch a File" option to patch the stock boot image.
- Pull the new Magisk patched boot image.- Stock boot image detected
- Flash (install) the new patched boot image.
---
To complicate my reply.
Depending on the device..
I use the hardware key-combo to boot into bootloader.
- Flash the current stock boot image to the device.
- Use fastboot to 'boot' a previously patched boot image.
- Then use the "Direct Install" option to install.
- Stock boot image detected
Hope it helps more than confuse.
Cheers.
2
Generally, in DenyList must be only apps you want to hide Magisk from them (banking apps and so)
And GMS (Google Play Services) - although, when using Zygisk and USNF, USNF will remove GMS from DenyList
If some banking apps still crash (or complain) although in DenyList, then they require additional treatment to hide Magisk, root, unlocked BL - USNF, Shamiko, maybe HMA, etc
Hence first, which apps do crash (and before that, remove 'normal' apps from DenyList if you have them, and reboot)1
I have run into if once or twice.
Sorry I do not remember exactly how I fixed it.
Might have been fixed in Magisk.
The message comes when the current Magisk (demon) is out of sync with Magisk.
The last time I ran into it, I do not remember what fixed it.
Try clearing cache and data of the Magisk app.
Assuming it is the same version that is patched into your boot image.
Clear the cache and data of the Magisk app and uninstall the app.
Reboot and install the Magisk app again.
Delete/data/adband let Magisk recreate it.
This will kill all modules and Magisk settings.
Good luck.
Cheers.1
Null pointer exception for me with this latest v1.4.0 and v1.4.1Yeah, I tried that last night... Either the fix is incomplete or I'm missing something as B/L status is still bypassed using LSP TEE Hide module...
PW
1
The old module TEE Hide just throw an exception in getCertificateChain method, so apps can't know if bootloader is locked or not. I will try to update AttestationSpoofer to bypass (again) the locked bootloader. They are using another cert class, because it doesn't call this method like previous versions.Yeah, I tried that last night... Either the fix is incomplete or I'm missing something as B/L status is still bypassed using LSP TEE Hide module... PW
-
8
Others have already addressed your question, but for me, the biggest benefit here is to have a safety valve in place where your inactive slot is bootable (without first having to flash the firmware) in case you get into a hairy situation where your active slot becomes unbootable for whatever reason. May be useful in some situations.87
Thanks, I realize it is only needed for custom Kernel cases.
I should add extracting vbmeta from payload.bin then in addition to boot.img / init_boot.img so that the step can be performed if the options are selected.6
Your wish is my commandI think it would be good to support, and I posted disambiguation due to some confusion above.
Rather than being 'highly discouraged' (it's not; it's plum necessary
) patching recovery partition is actually the only option for most A-only devices launched with Android 9 (legacy SAR, circa 2018, 2019) other than Xiaomi models!
Hope you reconsider... PW
Although with one caveat,
Yes I can tell if it is Ramdisk yes or no by running a script, but that requires unpacked Magisk, (for not rooted phone, I would need to unpack)
And although it is true that PF eventually unpacks to create a patch, but within the workflow, that stage is much later, and that stage is dependent on choices a user makes in the above screen.
Of course it could be worked out and workflow changed to automatically offer / not offer the choice.
Considering that the target audience is really minute if at all existent, specially considering that the tool has Pixel in its name, and people who have Pixel phone don't need it, and people who need them wouldn't be looking to tools for Pixel Phones ... lol
I decided the leave it up to the user the choice to have that option visible or not. (no auto detection)
The tooltip on option suggests not to turn it on unless ...
I hope that should be enough.6Update:
On a Pixel 5 device, I managed to have both slots bootable.
One slot rooted, and the other not, both on the same 2023-05 firmware.
The process is as follows (which PF will support OOB in the next release)
- Sideload full OTA
- Reboot to bootloader
- Flash patched image.
- reboot to system (observe root)
- Sideload full OTA
- Reboot to System (no patching, observe no root)
- Switch slot (observe root)
With Pixel 5, one is able to make changes to boot after sideload but before reboot.
It still needs to be tested if this works on Pixel 6, 7 * devices
I find flashing full OTA is slower than flashing full factory, but the benefit of having both slots bootable is a big bonus. -
1094This 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 Thread156Hello, 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
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
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!!121Ah, 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.76Thread 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.75Hello 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
