Magisk General Support / Discussion

Search This thread

jintrigger

Member
Jun 2, 2012
25
1
Hello! I am running an Honor 8 with the Carbon rom and anytime I update Magisk to a version above 15 it removes the fingerprint option (thus rendering anything using it useless) and my lock screen crashes anytime I type in the correct pin. I'm currently sitting at Magisk 14 and everything is fine.

---------- Post added at 09:58 PM ---------- Previous post was at 09:54 PM ----------

Hi folks,

since I didn't find anything about my problem I try to find out what I done wrong - with your help :)

Context: Honor 8 (frd-l09-c432) running with ResurrectionRemix 5.8.4 made by OpenKirin-Team. Working perfect with magisk 14 and previous.

But I didn't get Magisk 15 and up to work properly. I tried many times in different way and setup. Every version.

Gatekeeperd is crashing. Fingerprint don't work. Lockscreen don't work. And I bet many more don't work - just didn't notice.

I followed these steps:



Installed Magisk v15.x via recovery (TWRP 3.1.1-1) and via MagiskManager (different versions, but every time with the actual version; now 5.5.4). Both ways - same result. Magisk is working (MagiskSU, MagiskHide, Systemless Hosts and several modules tested) but FPS stops working - as I never had one and it's impossible to change lockscreen settings. "Fingerprint" completely disappears from Settings / Security.


EDIT: If a pattern is set before I install magisk v15.x I cannot unlock my device. SystemUI is crashing every time I enter Pattern/PIN/Password and the FPS has no function.


Only way to get it back is to flash stock-boot. After that it's possible to install Magisk v14 without any problems and everything is working.

I tried nearly everything... Beginning in flashing the uninstaller zip and ending up in a clean install (after I flashed the stock EMUI boot image I was forced to format internal storage). I also removed magisk.zip from ROM-zip, deleted old MagiskManager from /system/ ...

I tried core-only-mode and disabled anything else which can be disabled - without success

I played around with dm-verity and keepforceencryption flags - also with no success.

What else can I try? What did I do wrong?

Logs are here (tell me if anything's missing): https://drive.google.com/folderview?id=1nTIPHsn7QazdVCVYmX_zxwrSLrz8Z4IV

EDIT2: I also uploaded bootimage to the same place - just in case



EDIT3: In case it's important: after successful installation of v15.x, reboot, device behaves like selinux=enforcing. In last_kmesg is shown that the kernel is started with parameter setenforce=1. Usually no problem except for this device. Behavior when switching to enforcing after reboot is exactly the same. I know, if it is like I think, it is primarily a ROM problem but has anyone got an idea to workaround? Since development for Kirin seems to be very hard...

Regards

Sent from my FRD-L09 using XDA Labs

This is basically the same problem I am having.
 

Psycake

Senior Member
Jan 8, 2018
83
7
I created a module for you with that kl file, try it please, if it will work I will upload it to the Magisk repo.

Thank you, thank you, thank you, you are amazing, dude.

I'll root my phone this week, and will try your module when I do so. This doesn't modify the /system partition, right?
 

jdavis45

Member
Nov 28, 2015
37
15
Magisk 15.3 can't remember/edit SU for apps on OmniRom 8.1 for OnePlus 3T

This has been reported a while ago and there's been no update to my knowledge but Magisk Manager loves to crash on OmniRom 8.1.0 (any version up to current 20180122-oneplus3-weekly). Every time you open an app that needs SU access, you get multiple prompts and sometimes crashes or failures to get root. Furthermore, you can't edit anything in Manager in the Superuser tab without a crash.

Here was the first report TMK: https://forum.xda-developers.com/apps/magisk/mod-magisk-v1-universal-systemless-t3432382/post75035807#post75035807
And another: https://forum.xda-developers.com/apps/magisk/mod-magisk-v1-universal-systemless-t3432382/post75091530#post75091530

The issue seems to be that Magisk can't write to the SQLite Database to store this request as approved forever and some have suggested that it's F2FS related. It also only effects Magisk 15.x as users report success on 14.x. Here's a short example of it crashing trying to use the Manager app.

--------- beginning of crash
01-23 19:25:09.658 E/AndroidRuntime(5508): FATAL EXCEPTION: main
01-23 19:25:09.658 E/AndroidRuntime(5508): Process: com.topjohnwu.magisk, PID: 5508
01-23 19:25:09.658 E/AndroidRuntime(5508): android.database.sqlite.SQLiteDiskIOException: disk I/O error (code 7434)
01-23 19:25:09.658 E/AndroidRuntime(5508): at android.database.sqlite.SQLiteConnection.nativeExecuteForChangedRowCount(Native Method)
01-23 19:25:09.658 E/AndroidRuntime(5508): at android.database.sqlite.SQLiteConnection.executeForChangedRowCount(SQLiteConnection.java:735)
01-23 19:25:09.658 E/AndroidRuntime(5508): at android.database.sqlite.SQLiteSession.executeForChangedRowCount(SQLiteSession.java:754)
01-23 19:25:09.658 E/AndroidRuntime(5508): at android.database.sqlite.SQLiteStatement.executeUpdateDelete(SQLiteStatement.java:64)
01-23 19:25:09.658 E/AndroidRuntime(5508): at android.database.sqlite.SQLiteDatabase.delete(SQLiteDatabase.java:1576)
01-23 19:25:09.658 E/AndroidRuntime(5508): at com.topjohnwu.magisk.database.SuDatabaseHelper.deletePolicy(Unknown Source:21)
01-23 19:25:09.658 E/AndroidRuntime(5508): at com.topjohnwu.magisk.database.SuDatabaseHelper.deletePolicy(Unknown Source:2)
01-23 19:25:09.658 E/AndroidRuntime(5508): at com.topjohnwu.magisk.adapters.PolicyAdapter.lambda$null$4$PolicyAdapter(Unknown Source:48)
01-23 19:25:09.658 E/AndroidRuntime(5508): at com.topjohnwu.magisk.adapters.PolicyAdapter$$Lambda$5.onClick(Unknown Source:12)
01-23 19:25:09.658 E/AndroidRuntime(5508): at com.topjohnwu.magisk.components.AlertDialogBuilder.lambda$setPositiveButton$0$AlertDialogBuilder(Unknown Source:9)
01-23 19:25:09.658 E/AndroidRuntime(5508): at com.topjohnwu.magisk.components.AlertDialogBuilder$$Lambda$0.onClick(Unknown Source:2)
01-23 19:25:09.658 E/AndroidRuntime(5508): at android.view.View.performClick(View.java:6294)
01-23 19:25:09.658 E/AndroidRuntime(5508): at android.view.View$PerformClick.run(View.java:24774)
01-23 19:25:09.658 E/AndroidRuntime(5508): at android.os.Handler.handleCallback(Handler.java:790)
01-23 19:25:09.658 E/AndroidRuntime(5508): at android.os.Handler.dispatchMessage(Handler.java:99)
01-23 19:25:09.658 E/AndroidRuntime(5508): at android.os.Looper.loop(Looper.java:164)
01-23 19:25:09.658 E/AndroidRuntime(5508): at android.app.ActivityThread.main(ActivityThread.java:6494)
01-23 19:25:09.658 E/AndroidRuntime(5508): at java.lang.reflect.Method.invoke(Native Method)
01-23 19:25:09.658 E/AndroidRuntime(5508): at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
01-23 19:25:09.658 E/AndroidRuntime(5508): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
01-23 19:25:09.664 W/ActivityManager(975): Force finishing activity com.topjohnwu.magisk/.MainActivity
01-23 19:25:09.695 I/ActivityManager(975): Showing crash dialog for package com.topjohnwu.magisk u0
01-23 19:25:09.976 W/Looper (975): Dispatch took 171ms on android.ui, h=Handler (android.view.Choreographer$FrameHandler) {218d578} [email protected] msg=0
01-23 19:25:10.166 W/ActivityManager(975): Activity pause timeout for ActivityRecord{5398a1c u0 com.topjohnwu.magisk/.MainActivity t1183 f}
01-23 19:25:10.593 I/ActivityManager(975): Killing 4746:com.google.android.youtube/u0a93 (adj 906): empty #17
01-23 19:25:10.963 I/ActivityManager(975): Killing 5508:com.topjohnwu.magisk/u0a211 (adj 900): crash
01-23 19:25:11.022 I/ActivityManager(975): START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10300000 cmp=com.topjohnwu.magisk/.SplashActivity (has extras)} from uid 10211
01-23 19:25:11.035 E/ActivityManager(975): applyOptionsLocked: Unknown animationType=0
01-23 19:25:11.049 D/ConnectivityService(975): ConnectivityService NetworkRequestInfo binderDied(NetworkRequest [ LISTEN id=15, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ], [email protected])
01-23 19:25:11.063 I/ActivityManager(975): Start proc 6078:com.topjohnwu.magisk/u0a211 for activity com.topjohnwu.magisk/.SplashActivity
01-23 19:25:11.066 W/ActivityManager(975): setHasOverlayUi called on unknown pid: 5508
01-23 19:25:11.165 W/AppOps (975): Finishing op nesting under-run: uid 1000 pkg android code 24 time=0 duration=0 nesting=0
01-23 19:25:11.191 W/FileUtils(6078): Failed to chmod(/data/user_de/0/com.topjohnwu.magisk/databases/su.db): android.system.ErrnoException: chmod failed: EPERM (Operation not permitted)
01-23 19:25:11.240 E/ActivityThread(5836): Failed to find provider info for com.facebook.katana.provider.AttributionIdProvider
01-23 19:25:11.795 W/FileUtils(6078): Failed to chmod(/data/user_de/0/com.topjohnwu.magisk/databases/su.db): android.system.ErrnoException: chmod failed: EPERM (Operation not permitted)
01-23 19:25:11.884 I/ActivityManager(975): START u0 {cmp=com.topjohnwu.magisk/.MainActivity (has extras)} from uid 10211


More logs are attached. Given this only happens on 15.x, something has changed that it causes a DiskIO error when F2FS is used.

EDIT: Yes, I'm aware of the F2FS bug but even patched kernels are having issues in some cases on Oreo. This is a Magisk side issue. Also, the loopback mod doesn't resolve this either.
 

Attachments

  • crash_log_2.txt
    16.9 KB · Views: 8
  • crash_log_3.txt
    2.7 KB · Views: 2
Last edited:

Artim_96

Senior Member
Feb 15, 2013
2,455
729
Why does magisk uninstall itsrlf on pixel 2? I have to reboot my phone several times a day
Well, it seems there is a bug. Of you end up with Magisk manger reporting back that Magisk isn't installed again, see if the logs are still available from the logs tab. If not you might want to reboot to twrp and get them there from /cache
 

return.of.octobot

Senior Member
Mar 5, 2015
521
1,318
Wilmington, NY
Does anyone have any insight regarding resizing magisk.img and/or utilizing magisk_merge on devices with A/B partitions? Modules which should auto-resize the image fail, and I've been subsequently unable to manually resize it via flashable zip or command line. Discussions that I've had in the terminal app systemizer thread have led me to believe that there's a commonality with folks facing similar issues also having A/B devices. I assume I'm probably not the first person to encounter this problem, wondering if there's any workarounds or alternative approaches. Otherwise, I'm willing to assist with diagnostics if need be. I am using an Essential PH-1, Oreo B3 which uses ext4 so I don't believe there to be any f2fs shenanigans occurring.

Specifically, I'm encountering this while attempting to use app systemizing modules in which case after 2 or 3 apps, once the 64MB cap is met or exceeded I am unable to systemize any further apps and am further unable to adjust the image size manually to accommodate additional apks.
 
Last edited:

rignfool

Senior Member
Dec 8, 2010
5,010
2,729
The Poconos
Does anyone have any insight regarding resizing magisk.img and/or utilizing magisk_merge on devices with A/B partitions? Modules which should auto-resize the image fail, and I've been subsequently unable to manually resize it via flashable zip or command line. Discussions that I've had in the terminal app systemizer thread have led me to believe that there's a commonality with folks facing similar issues also having A/B devices. I assume I'm probably not the first person to encounter this problem, wondering if there's any workarounds or alternative approaches. Otherwise, I'm willing to assist with diagnostics if need be. I am using an Essential PH-1, Oreo B3 which uses ext4 so I don't believe there to be any f2fs shenanigans occurring.

Specifically, I'm encountering this while attempting to use app systemizing modules in which case after 2 or 3 apps, once the 64MB cap is met or exceeded I am unable to systemize any further apps and am further unable to adjust the image size manually to accommodate additional apks.
Ahh yes... The dreaded trying to copy to too small an image bug...

You need to over resize your image... Copy the stuff you want in the image... And then resize...

e2fsck in the terminal in TWRP will let you repair your image... And then resize it again...

Sent from my PH-1 using Tapatalk
 

miguelr4720

Senior Member
May 24, 2015
111
35
27
New York
I Install Magisk In LG K7 and Safety Net Wont Pass Any Solution For this Please Let me know this is after the King Root and Everytime When i Flash Magisk is giving me and error Safety Net Won't Pass Any Solution for this
 

zelendel

Senior Member
Aug 11, 2008
23,370
20,593
I Install Magisk In LG K7 and Safety Net Wont Pass Any Solution For this Please Let me know this is after the King Root and Everytime When i Flash Magisk is giving me and error Safety Net Won't Pass Any Solution for this
Your first mistake was king root. It uses the vulnerabilities to get root so it will always cause a fail in safety net. Even if you remove it. Xda doesn't advise its use. Unless you are desperate.
 

miguelr4720

Senior Member
May 24, 2015
111
35
27
New York
WOW My Fault I Did not Know this How can I Root With Magisk

Your first mistake was king root. It uses the vulnerabilities to get root so it will always cause a fail in safety net. Even if you remove it. Xda doesn't advise its use. Unless you are desperate.

Wow i Did not Know this how do i remove King root do i need to reflash the phone. to remove it
and how do i root the LG K7 Without the Kingroot? and install magisk correctly:confused:

---------- Post added at 12:36 AM ---------- Previous post was at 12:19 AM ----------

how do i fix this problem with the LG K7 WITH THE KING ROOT CONFLICT
 

Didgeridoohan

Forum Moderator / Developer Relations
Staff member
May 31, 2012
11,423
11,630
Gothenburg
Google Nexus 4
Nexus 6
Wow i Did not Know this how do i remove King root do i need to reflash the phone. to remove it
and how do i root the LG K7 Without the Kingroot? and install magisk correctly:confused:

---------- Post added at 12:36 AM ---------- Previous post was at 12:19 AM ----------

how do i fix this problem with the LG K7 WITH THE KING ROOT CONFLICT

If it's indeed Kingoroot causing your issue a complete reflash might be necessary.

For your other inquires you have the installation instructions in the release thread and if you encounter any issues you have lots of information in the troubleshooting guide. Start with those two and if you can't get things working, post here again with lots of details and relevant logs (see "Asking for help" in the troubleshooting guide).
 

Top Liked Posts

  • 8
    Update snet.jar extension
    The existing API key was revoked for some reason.
    Release an updated extension jar with a new API key.

    In addition, add some offline signature verification and change how
    results are parsed to workaround some dumbass Xposed module "faking"
    success results, since many users really don't know better.

    @topjohnwu

    topjohnwu committed 19 minutes ago
    5
    Re Google SafetyNet changes:

    Not sure what's going on yet, but basicIntegrity fail imay be good sign fix may not be too difficult; this has usually been achieved fairly easily.

    Of course, it may well be Bootloader / Hardware key Attestation related too. In this case, the fun may well be over... PW
    Magisk shows Error when checking SafetyNet, not Fail.

    Might be everyone checking SafetyNet recently using Magisk's API key?
    ¯\_(ツ)_/¯


    If the device shows as certified in PlayStore, you are currently passing SafetyNet. ;)

    Cheers all. :cowboy:
    4
    John Wu, 2h

    So apparently the SafetyNet Attestation API is currently dead. I wonder how this affects non-root devices out there in the wild...

    If most apps are designed to continue to function when the attestation API stop responding, then this is an easy target to exploit in the future...

    Wait a sec, it might just be the API key I'm using is blocked... LOL. Will investigate further.

    Update: got a new API key working, will push a new update soon
    Haha, Hehe ... think April 1 got delayed 2 weeks ... April 1's just t o e a s y ! 🥳 🙃 PW
    3
    As other's have stated, the Magisk apps SafetyNet check showing API error doesn't mean that SafetyNet is failing. Just that the app can't get a proper response from Google's servers. There's probably been some kind of API update...

    https://www.didgeridoohan.com/magisk/MagiskHide#hn_SafetyNet_API_error
    3
    "dual Magisk": Did you try to put Magisk in *both* boot and recovery?
    Yes 😛
    I do not understand "ANY attempt to flash Magisk to recovery finds recovery's 'stock boot image' and patching succeeds": What is "find", and what is "succeeds"?
    See this log for patching recovery image (Recovery mode checked):
    Code:
    - Device platform: arm64-v8a
    - Installing: e136fb3a (22102)
    - Copying image to cache
    - Unpacking boot image
    - Checking ramdisk status
    - Stock boot image detected
    - Patching ramdisk
    - Repacking boot image
    
    ****************************
    Output file is written to
    /storage/emulated/0/Download/magisk_patched-22102_xumwp.img
    ****************************
    - All done!
    Direct Installation log is similar.

    You said Xiaomi. I have a Samsung.
    😆
    I agree the bootloader supports ramdisk. As I quibbled with you earlier, I believe that it is the kernel that may or may not look for / use a ramdisk: it's the same bootloader, whether you boot boot or boot recovery, so if recovery always has a ramdisk, the bootloader always supports ramdisk.
    But recovery ramdisk and boot ramdisk are implemented differently.

    As John took pains to point out, type III (Ramdisk= no) devices (generally speaking) DON'T support boot-ramdisk (even if added manually when missing, as Magisk does) due to lack of bootloader support. However, since bootloader (generally speaking) supports recovery-ramdisk, Magisk in recovery is an option.

    Or the bootloader doesn't even know about ramdisk, and the kernel finds the ramdisk at the end of what the bootloader thought was kernel. Of course, there could be a flag in the kernel's meta-data that tells the bootloader not to bother doing ramdisk stuff, but that would still be a matter of the *kernel* choosing to not allow ramdisk.
    As I understand it, to use any ramdisk type requires ramdisk specific bootloader support. Kernel and ramdisk can be patched, but bootloader (again, generally) cannot be, due to proprietary nature.

    Bootloader support (or lack of it) presents the real challenge.
    I agree that it seems to be possible to install Magisk in boot on my device.

    I do not believe that I have Magisk in boot -- I told you I had to boot repeatedly before hitting the sweet spot that caused Magisk to activate.
    Yep, understand that. 🙂 But I don't understand fully what's going on yet.

    Since trying with stock, I tried patching and flashing TWRP image (w/ fastboot) both w/ stock boot, and Magisk patched boot image with similar results; patching succeeds (completes w/ no errors), but get 'system has been destroyed' on booting.

    Then, with Magisk in boot, I've checked Recovery mode and tried Direct Install. Surprisingly, this succeeds, and reboot (from Magisk App) lands me in recovery.

    It appeared I now had Magisk in Recovery as all settings were for this, but on powering off and trying to boot with recovery key combo / releasing keys at splash screen (for system with Magisk in recovery), like you, I have great difficulty getting to system. I get recovery unless I release keys on vibration, and almost BEFORE splash screen appears! I get System with root this way, but I'm not sure I'm not simply releasing keys too early to boot using recovery at all (ie. that this isn't actually Magisk in boot.)!

    To test this, I've variously to flash stock boot.img (to see if I can boot with and without root as instructions say I should have ability), and with boot.img patched with a slightly different version of Magisk (for bootup comparison), but ANY such changes in combination with patched working recovery image result in 'System Has Been Destroyed', Fastboot mode only available, and this is fixed only by flashing unpatched recovery image.

    Seems the symptoms I have may be similar to yours (difficulty booting to system from recovery key combo, etc). At the very least, I'm not convinced I actually have Magisk in recovery, although it has clearly been Patched / altered.

    At this stage, I suspect that Xiaomi devices that appear as type III (and possibly other devices) may not be properly accounted for in John's Booting Shenanigans summary. I'm thinking the unexplained bootloader compatibility with ramdisk in boot may somehow be there to boot recovery, although not needed for system.... or other perhaps something else is going on.... So we may in fact have more than IV basic boot-types of Android device... There seem to be more discrepancy with John's Type III model that just having Magisk in Boot ability.

    I'd love to get my head around this!
    I do not know if my version of Magisk Manager has a reboot option, but I would be afraid to try to use it to get back to Magisk active from Magisk inactive. I would expect the Manager to need root privilege to trigger a reboot, let alone to trigger a reboot to recovery. Are those really things that Android will allow an unprivileged app to do?
    Covered by @zgfg. 👍 PW
  • 12

    Latest Public (Stable / Beta)

    Release Notes and Changelog:


    2021.4.9 Magisk v22.1​

    This release is focused on fixing regressions and bugs. Check the v22.0 release notes if coming from older releases.

    Note: Magisk v22 is the last major version to support Jellybean and Kitkat. Magisk v23 will only support Android 5.0 and higher.

    Bug Fixes​

    • [App] Prevent multiple installation sessions running in parallel
    • [App] Prevent OutOfMemory crashes when checking boot signature on PXA boot images
    • [General] Proper cgroup migration implementation
    • [General] Rewrite log writer from scratch, should resolve any crashes and deadlocks
    • [General] Many scripts updates fixing regressions
    • [MagiskHide] Prevent possible deadlock when signal arrives
    • [MagiskHide] Partial match process names if necessary
    • [MagiskBoot] Preserve and patch AVB 2.0 structures/headers in boot images
    • [MagiskBoot] Properly strip out data encryption flags
    • [MagiskBoot] Prevent possible integer overflow
    • [MagiskInit] Fix sepolicy.rule mounting strategy
    • [resetprop] Always delete existing ro. props before updating. This will fix bootloops that could be caused by modifying device fingerprint properties.
    🎉 👍 PW
    8
    @osm0sis
    Thank you for having an eye on that.
    Did the "ls" twice, first from a TWRP-terminal in recovery, second from a terminal while phone is "up and running".
    Looks like you have /dev/bootimg as your real partition location and it is still higher in the list in util_functions.sh like how I fixed it in the linked commit, so this is definitely a regression from some other recent change to Magisk.. sigh, I'll look into it. 🤔😕
    8
    Update snet.jar extension
    The existing API key was revoked for some reason.
    Release an updated extension jar with a new API key.

    In addition, add some offline signature verification and change how
    results are parsed to workaround some dumbass Xposed module "faking"
    success results, since many users really don't know better.

    @topjohnwu

    topjohnwu committed 19 minutes ago
    6
    No, the phone is an Estar Takee1.
    ROM is from here: Mikel Android 7 for Takee1
    and is itself a port from this ROM: RidonOS for Micromaxx A311

    You're right, sorry for that. Now here the installation log for canary-version:

    - Target image: /dev/BOOT
    - Device platform: armeabi-v7a
    - Installing: f152b4c2 (22005)
    nanddump: MEMGETINFO: Not a typewriter
    Parsing boot image: [boot.img]
    - Unpacking boot image
    ! Unsupported/Unknown image format
    ! Installation failed

    😛

    /dev/BOOT is known (usually) not an actual boot partition, hence nanddump failing.

    I had originally fixed this back here: https://github.com/topjohnwu/Magisk/commit/2aede97754fec67d393bde0c7725ed84d8c3c112

    So not sure if we're looking at some kind of a regression, or just a further edge case.

    @io2345 what's the actual, correct location of your boot partition? Please give me the output of `ls -alR /dev`
    6

    Latest Canary Changelog, including Release Notes:​


    Magisk (9c0e1897) (22007)​

    • [General] Fix logic to copy sepolicy.rule during module installation
    • [resetprop] Always delete existing ro. props before updating. This will fix bootloops that could be caused by modifying device fingerprint properties.

    Diffs to v22.0​

    • [App] Prevent multiple installation sessions running in parallel
    • [App] Prevent OutOfMemory crashes when checking boot signature on PXA boot images
    • [General] Proper cgroup migration implementation
    • [General] Rewrite log writer from scratch, should resolve any crashes and deadlock
    • [General] Many scripts updates fixing regressions
    • [MagiskHide] Prevent possible deadlock when signal arrives
    • [MagiskHide] Partial match process names if necessary
    • [MagiskBoot] Preserve and patch AVB 2.0 structures/headers in boot images
    • [MagiskBoot] Properly strip out data encryption flags
    • [MagiskBoot] Prevent possible integer overflow
    • [MagiskInit] Fix sepolicy.rule mounting strategy
    • [resetprop] Always delete existing ro. props before updating. This will fix bootloops that could be caused by modifying device fingerprint properties.
    👍 PW
  • 1046
    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
    155
    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!!
    119
    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.
    74
    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
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone