Hiding root and passing Safety Net

Table of Contents


MagiskHide works, but only IF your system is set up correctly and is compatible. In most cases nothing needs to be done except enable MagiskHide (since Magisk v20.4 it is disabled by default), add whatever apps or services that detect root to the Hide list and possibly hide the Magisk Manager itself. Keep reading for lots of tips and tricks.





Basics


Where to start

It’s always a good idea to read through, at least, the release thread for information about what Magisk is and how to get MagiskHide working. Other useful information can be found in the official Magisk Documentation over on GitHub and the support thread.

Requirements


Magisk can hide


Magisk can not hide


Make sure that your device conforms to the above requirements before continuing.







Hiding root from apps

First, it might pay to check out what others have been discussing about the app you are having trouble with. Take a look at the App resources for links to discussions and workarounds for a few select apps that are known to be troublesome when it comes to hiding root.

If you have apps that you need to hide root from, that detect that your device is rooted even if you can pass SafetyNet, here are a few tips (if you can't pass SafetyNet, see the section about SafetyNet). A good aproach would be to try one thing at a time and see if the app in question stops detecting root. No need to try all tips at once...

It is quite common for apps to update with new detection methods and new ways of circumventing MagiskHide surfaces from time to time. So, if an app has been working before and suddenly starts detecting root after an update, it might pay to go through the list again and try the tips available or test the latest Canary update. Here's an example of a current detection method that MagiskHide can't deal with (one of several that are currently known): https://github.com/topjohnwu/Magisk/issues/2406
If the app you're using has implemented one of these detection methods there's likely not much you can do at the moment. If you're capable, analysis of these methods are always welcome and any useful information can be posted on the Magisk Github repo, either as an issue or a pull request.

















































Hiding the Magisk Manager

Keep in mind that full obfuscation of the Magisk Manager is only possible of Android 9 and newer versions. If full obfuscation is possible, the Manager will install a stub app that loads the rest of the app dynamically from it's own data folders. There is nothing in the stub that can be identified as the Magisk Manager.

Hiding the Manager is done by going to the Manager settings and choosing “Hide Magisk Manager”. When this is done, the Manager is repackaged with a random package name and can therefore not be detected by any apps or services looking for com.topjohnwu.magisk. Since v6.1.0 of the Manager, the app name is also changed, by default to "Manager" to circumvent apps and services detecting "Magisk" in the app name, but you can pick your own app name as well to make the app completely anonymous. If you have the app hidden, but it is still called "Magisk Manager", even though you are on app version v6.1.0+, try unhiding it and hiding it again. The name can't be changed when updating from an earlier version than that if it is already hidden.

You can see if your Manager is hidden on the main screen of the app. Under the information about the latest Manager release there will be a package name consisting of a random string. The “Hide Magisk Manager” option will also be changed to "Restore Magisk Manager" in the settings on a hidden Manager. If your hidden Manager is using the stub you will see this in the version string of your installed Manager as a second set of parenthesis with the version number of the stub.

Unhiding the Magisk Manager

Go to the Manager settings and choose "Restore Magisk Manager".

You can also unhide the Manager by uninstalling the repackaged Manager and manually install the apk. Get it from the (release thread or GitHub)

Can't hide the Magisk Manager

If you're having issues trying to hide (repackage) the Magisk Manager, this is often caused by having the Manager installed as a system app, either by you or the ROM creator. This is a bad idea... But, there might be other reasons as well. See "Can't hide the Magisk Manager" for more info.

Isolation apps

If an app is detecting other root apps or files/folders on your device that hint at a rooted/modified device, you might be able to use an isolation app to prevent it from doing this. There are a few different apps you can use. There's Storage isolation that can be used to gain full controll of what parts of your internal storage an app can see. You can also isolate apps in a Workspace profile with apps like Island or Shelter (of which the latter is open source, yay).

USB/ADB debugging

If you haven’t yet, try disabling USB/ADB debugging to see if this helps you use your root detecting app.

OEM Unlocking

If you haven’t yet, try disabling OEM Unlocking to see if this helps you use your root detecting app. Be careful with this option though. There is a chance that it can cause issues.

WARNING 1 On Samsung devices, toggling OEM Unlocking might be enough to lock the bootloader. This might mean you end up with a device that can't boot.
WARNING 2 On some devices (known: Huawei) both OEM Unlock and an unlocked bootloader is necessary for the fastboot flash command to work. This should not be the case on devices that use vanilla Android (Google), or stay close to vanilla Android. Please exercise caution.

Developer options

If you haven’t yet, try disabling Developer options to see if this helps you use your root detecting app.

Samsung Knox

If you have a Samsung device you have likely triggered Knox when rooting your device. This cannot be undone and it cannot be hidden, so if an app is using the Knox fuse to determine if you have been modding your device there is nothing that can be done.

I don't do Samsung, so I do not know how to determine if an app detects Knox or not, except that it might show up in a logcat. If the app works perfectly with Magisk and MagiskHide on a non-Samsung device, but doesn't on a Samsung it's very probable that it's Knox that is causing issues.

Nothing works

If you can't get it working even though you've tried everything, grabbing a logcat when the app detects root might show something (see "Asking for help/reporting bugs"). Save the log and post it in the General support thread, with plenty of details about the issue. Just make sure you've tried everything first.

Xposed/EdXposed and root hiding modules

It might also be possible to use Xposed/EdXposed to help hide root from apps. With Xposed modules like Sudohide and RootCloak you can achieve further obfuscation, even though the modules are quite old. It is possible that Xposed/EdXposed itself will be detected though...







App resources


A list of collected sources for discussions and known workarounds for apps that are particularly difficult to hide root from.

Blackberry Apps


Fate/Grand Order


Google Pay


Harry Potter: Wizards Unite


Microsoft


Pokémon Go


Snapchat










SafetyNet


Passing SafetyNet

If everything works out, SafetyNet should pass with no further input from the user, as long as your device fulfills the basic requirements. Nothing needs to be added to the Hide list. You can see in the Magisk Manager if it works by checking the SafetyNet status, or in the SafetyNet checker of your choice (just make sure that you use one that is properly updated to check the SafetyNet status). If SafetyNet doesn't pass after enabling Hide, try rebooting (also see “MagiskHide isn’t working”).

Google continuously updates SafetyNet. Currently, no versions prior to Magisk v13.3 will pass SafetyNet without major workarounds.

What triggers SafetyNet?

There are two parts to the SafetyNet check, CTS Profile and Basic Integrity.

Examples of when ctsProfileMatch will report as false (failed):
- Uncertified device (the manufacturer haven't applied for Google certification)
- Unlocked bootloader
- Custom ROM
- Signs of system integrity compromise (rooting, etc)
- Signs of other attacks (Xposed, EdXposed, etc)

Examples of when basicIntegrity will report as false (failed):
- Signs of system integrity compromise (rooting, etc)
- Signs of other attacks (Xposed, EdXposed, etc)

Several (but not all) of the things mentioned above can be hidden by Magisk. See what Magisk can and cannot hide under Basics.

Test MagiskHide

First thing to do is to make sure that MagiskHide is enabled (since Magisk v20.4 MagiskHide is disabled by default), or if it is on toggle MagiskHide off and on again. Sometimes MagiskHide stops working temporarily after an update of Magisk or the Manager. If SafetyNet still doesn't pass, make sure MagiskHide is actually working by using a root checker or a root app. Start by making sure the app can detect that your device is rooted. After that, add the app to the Hide list and see if it no longer can detect root. If that is the case, MagiskHide is working on your device. If you can't get it to work, see "MagiskHide Issues".

It can of course also be any other mod that you've done to your device outside of Magisk, so check those as well.

Unlocked bootloader

In March 2020 Google flexed their muscles and showed us that they are ready to implement proper hardware key attestation in the SafetyNet check. By doing this they can easily detect if the bootloader is unlocked and as a result the CTS profile check will fail. This check is very likely impossible to circumvent and as a result Magisk will no longer be able to make SafetyNet pass fully (basic integrity will still pass). This applies to all devices that have shipped with the proper hardware (any device that ships with Android 8+ is required to have it). A device with this hardware will not be able to pass CTS, no matter which of the methods below are tested.

In late June 2020 Google started rolling this out again. If you are failing CTS you can check if hardware attestation is being used by doing a SafetyNet check in the Magisk Manager (v8+), which will report if BASIC or HARDWARE is being used.

In early September 2020 Google changed things up again and suddenly even devices using hardware backed key attestation pass CTS. https://twitter.com/topjohnwu/status/1303845469798367233?s=20
That soon changed back, but while Google is fidgeting with the dials, we'll be seeing stuff like this continuously.

If your device fails CTS and is using hardware backed key attestation, there is currently a temporary fix, that'll likely work until Google rolls this out universally. You can find info about that here.

Topjohnwu has written a faq on hardware key attestation that can be found here:
https://twitter.com/topjohnwu/status/1237830555523149824?s=20
And XDA has a very good article on this as well:
https://www.xda-developers.com/safetynet-hardware-attestation-hide-root-magisk

Since this part of SafetyNet checks for an unlocked bootloader you might be tempted to simply lock the bootloader again. This is a bad idea... Most devices will be permanently bricked if you lock the bootloader on a modified device. There are some devices that you can lock the bootloader on even if it isn't stock, but this is not recommended unless you know exactly what you are doing. Be warned...

SafetyNet fails after an update

If SafetyNet starts failing after an update to either Magisk, the Manager or both it's usually fixed by toggling MagiskHide off and on (see ”Test MagiskHide above”). It might be necessary to reboot after toggling the setting off and on.

CTS profile mismatch vs Basic integrity

There are two parts to a SafetyNet check, CTS compatibility and Basic integrity. The CTS check is a server side checkup up that's difficult to spoof, while Basic integrity is done on the device side and is a lower level of security. Some apps only use the Basic integrity part of the SafetyNet API and thus can be used even if SafetyNet doesn't fully pass.

Both CTS profile and Basic integrity fails

MagiskHide needs to be enabled. Start there. If MagiskHide is enabled and working (see Test "MagiskHide" above), and both checks fail you might be successful if you clear cache for Google Play Services. If that doesn't help you should also make sure that you don't have a mod or module that is triggering SafetyNet (see "Check your modules and mods" below).

CTS profile fails but Basic integrity passes

MagiskHide needs to be enabled (yes, basic integrity can pass even if MagiskHide is disabled). Start there. If MagiskHide is enabled and working (see Test "MagiskHide" above), and you still can't pass the CTS profile check, but Basic integrity shows as true, that basically means Google doesn't trust your device for some reason (also see "Unlocked bootloader" above and "SafetyNet incompatible devices and ROMs" below). You should be able to fix this by matching prop values with a ROM that passes SafetyNet (see "Matching official prop values to pass SafetyNet" and "Spoofing device fingerprint" below).

CTS profile passes but Basic integrity fails

This means that SafetyNet is actually failing and you are likely using a mod like the Xposed HiddenCore module that is trying to spoof the CTS profile check result. In reality you're failing both CTS profile and Basic integrity (see above).

This might be successful against some apps that haven't properly implemented the SafetyNet check. But it won't have any effect on a properly implemented SafetyNet check.

Both CTS profile and Basic integrity passes

Everythings good. You can stop reading (at least this section of the guide).

Check your modules and mods

In March 2020 Google didn't just start using hardware key attestation (see "Unlocked bootloader" below), but they also tightened down what kind of modifications SafetyNet detects. For example, bind mounts in a module may now trigger SafetyNet.

If you suddenly start failing both CTS and basic integrity, try disabling or uninstalling the last module you installed (or try disabling all modules). If you can pass SafetyNet fully with that (or all) module disabled you know it is a module that is causing the issue. If you do not know which module disable each module individually until you find which one is the culprit.

SafetyNet incompatible devices and ROMs

There are devices/ROM’s that just won’t be able to pass SafetyNet. This might have to do with how the ROM is built, and if so there is nothing the user can do to change it.

But, fortunately, most of the time it is much simpler than that.

All custom ROMs are incompatible with SafetyNet out of the box (unless the ROM creator uses the described method below and uses a certified device fingerprint instead of the on that matches the ROM). This has to do with how Google certifies devices, CTS certification (Compatiblity Test Suite). If a device hasn’t passed the Google certification process, or if the ROM alters how the device is perceived by Google, it won’t be able to fully pass SafetyNet (CTS profile mismatch). You might be able to get basic integrity to report as true (see Checking if Basic integrity passes above) and this would mean that MagiskHide is working as it should and it's most likely a simple CTS certification issue.

You can match your ROM's ro.build.fingerprint (and possibly other props, like ro.build.version.security_patch) with an official ROM for your device, or any other device that is certified, to make it pass SafetyNet fully (see "Matching official prop values to pass SafetyNet" and "Spoofing device fingerprint" below).

Matching official prop values to pass SafetyNet

If you use an unofficial/developers ROM you might have to match an official/stable ROM's details (usually ro.build.fingerprint and possibly ro.build.version.security_patch) to pass the SafetyNet CTS profile check (also see "Spoofing device fingerprint" below).

coolguy_16 have made a guide for Moto G 2015 here. Thank you to diegopirate for the tip.

Spoofing device fingerprint

Try changing your device's ro.build.fingerprint to a device's/ROM's that is known to pass SafetyNet. The Magisk module MagiskHide Props Config can do this. This can also be done with a boot script (don't forget to set the proper permissions for the script to execute) and the resetprop tool (also see "Sensitive props").

To change the device fingerprint with a boot script, add the following to a file you place in /data/adb/service.d (and don't forget to set the proper permissions for the script to execute):
#!/system/bin/sh
resetprop ro.build.fingerprint <fingerprint value>

Depending on your ROM and/or device you might also have to edit ro.bootimage.build.fingerprint, ro.system.build.fingerprint, ro.vendor.build.fingerprint and ro.odm.build.fingerprint. It's not necessary for passing the CTS profile check, but if your ROM has one of these other props and you don't match them with the used fingerprint you may get a warning at boot about your device having an internal problem.

If the device fingerprint is from an Android build after March 16 2018 you'll also have to match that build's Android Security Patch date (ro.build.version.security_patch). This is automatically done by MagiskHide Props Config, but otherwise you can go about it the same way as described above.

The response is invalid

This basically means that your device can't get a proper response from the Google servers, for whatever reason. It says nothing about wether your device actually passes SafetyNet or not...

If you get an invalid response result when checking SafetyNet it might mean that the app you're using to check SafetyNet hasn't been updated to work with the latest version of the SafetyNet API.

This response might also mean that Google's servers are down at the moment.

Another thing to try is to force close Play Services, clearing it's data and/or rebooting the device.

You could also try using a different GAPPS package (if you're on a custom ROM) or update the Play Services manually by downloading the latest version from APKMirror.

Make sure that you have a proper working internet connection and that there's nothing interfering (firewalls, etc).

SafetyNet check never finishes

If the SafetyNet status check never finishes (make sure to wait a while), it might mean that your Google Play Services aren’t working properly or have crashed. Try force closing Play Services, clearing data and/or rebooting the device.

You could also try using a different GAPPS package (if you're on a custom ROM) or update the Play Services manually by downloading the latest version from APKMirror.

SafetyNet API error

This error is usually caused by the app you are using to check SafetyNet not having internet access or the snet.apk not downloading properly if you're using the Magisk Manager. If you're using the Magisk Manager, try clearing data for it and make sure that you have a working internet connection when starting the SafetyNet check. The Manager need to download the necessary files to be able to do the check and internet access is required to get a response from Google's servers.

Device uncertified in Play store/Netflix (and other apps) won't install or doesn't show up

If some apps won't install or doesn't show up in the Play store, check the Play store settings. At the bottom there might be a section called "Device certification". Some apps won't install if this shows "uncertified" (a couple of known apps are Netflix and Mario Run). It might even be that your device show "certified" and they don't show up. Even if there isn't a "Device certification" section in your version of the Play store, try the below if you have issues with apps like Netflix not installing or showing up.

The solution is to make sure your device passes SafetyNet and then clear data for the Play store and reboot. If you have multiple users on your device, you might have to clear data for all users. Next time you open up the Play store, "Device certification" should show "certified" and the apps should be able to install/show up again. You might have to wait a bit before the apps show up. Some users have reported having to wait mere minutes, others several hours up to a whole day.

Permissive SELinux

MagiskHide can usually mask a permissive SELinux and let you pass SafetyNet anyway. But, it has been reported that this is not successful on all devices. If you have SELinux set to permissive, try changing it to enforcing and check SafetyNet again.

Passing SafetyNet with EdXposed installed

Google can detect if you have EdXposed installed, but you can usually work around this by making sure you're using the latest release (usually the Canary releases) and using things like the EdXposed Managers Blacklist feature and enabling it for Google Play Services, Play Store and Services Framework.

I still can't pass SafetyNet

Start by clearing data for Play Services and the Play Store. There have been reports of this making SafetyNet passing. It's also a good idea to read through the rest of the guide. For example More hiding tips, MagiskHide Issues, Other things to try, Asking for help/reporting bugs and other parts.

Changing ROM or completely wiping your device and starting out clean might also be a good idea.







MagiskHide Issues


Test MagiskHide

First thing to do is to toggle MagiskHide off and on again (a reboot might also be necessary). Sometimes MagiskHide stops working temporarily after an update of Magisk or the Manager. If it still doesn't work, make sure MagiskHide is actually working by using a root checker or a root app. Start by making sure the app can detect that your device is rooted. After that, add the app to the Hide list and see if it no longer can detect root. If that is the case, MagiskHide is working on your device. If you still can't get it to work, see "Asking for help/reporting bugs".

MagiskHide fails after an update

If MagiskHide starts failing after an update to either Magisk, the Manager or both it's usually fixed by toggling MagiskHide off and on (see ”Test MagiskHide above”).

MagiskHide fails after rebooting

On some devices MagiskHide can't seem to stay enabled across a reboot. It will look like it is enabled, but the service isn't actually running. The solution is to toggle MagiskHide off and on again after rebooting. This can become tedious, so it's better to create a late_start service boot script (service.d) that can do it for you. Something like this:
#!/system/bin/sh
while [ "$(getprop sys.boot_completed)" == 0 ]
do
	sleep 1
done
magiskhide disable
magiskhide enable


MagiskHide doesnt show in the Manager

Your device’s kernel probably doesn’t have support for mount namespace (see ”Mount namespace issues” below).

MagiskHide isn't working

If you can’t get MagiskHide to work, either for SafetyNet or any other app detecting root, there are a few things you can try. Start by testing if MagiskHide actually works (see "Test MagiskHide" above).

Starting MagiskHide manually

MagiskHide is enabled by default and should start automatically on boot. If it isn’t working, try toggling MagiskHide off and on in the Manager settings. If MagiskHide just won't start when toggling it in the Magisk Manager (check the Magisk log, it might have started but the Manager doesn't reflect it), try starting it manually. This can be done in a terminal emulator (as su) by executing the following commands:
su
magiskhide disable
magiskhide enable


Mount namespace issues

If you see this line in the Magisk log (see "Asking for help/reporting bugs"): "proc_monitor: Your kernel doesn't support mount namespace", your device has a Linux kernel that is to old. The Linux kernel version has to be at least 3.8 (thank you TheCech12), or otherwise have the necessary features backported. It is possible to patch the kernel (see "MagiskHide Requirements"). Also, it might be a good idea to ask in your ROM/kernel thread or try a different ROM and/or kernel.

I still can't get MagiskHide to work

Take a look at the rest of the guide, there are more things to try in different sections. For example More hiding tips, Other things to try, Asking for help/reporting bugs and other parts.







More hiding tips


Dependencies

There are some apps that require one or more other apps or processes being added to MagiskHide. So if an app is asking for extra permissions, try hiding the corresponding app/process as well. As an example: for a banking app asking for permissions to make phone calls it might be necessary to add the Phone app as well as the banking app to MagiskHide. Unfortunately it's not necessarily the case that the app or process used for finding root asks for permissions (also see "Figuring out if an app has dependencies, looks for 'sensitive props', Busybox, etc" below).

Sensitive props

Some apps trigger if they find "sensitive props". Also, on some devices SafetyNet triggers if certain props are not set to the expected values. A few props are set to "safe" values by MagiskHide by default. These prop are known to trigger some apps that look for root and "tampered" devices. Currently these are (apart from props for the bootloader state):
ro.debuggable (set to 0 by MagiskHide)
ro.secure (set to 1 by MagiskHide)
ro.build.type (set to user by MagiskHide)
ro.build.tags (set to release-keys by MagiskHide)
ro.build.selinux (set to 0 by MagiskHide)

Some examples of other props to change may include:
ro.build.flavor
ro.build.description
ro.build.fingerprint
ro.bootimage.build.fingerprint
ro.build.oemfingerprint
etc...

Use the command "getprop" (without quotation marks) on the props in a terminal emulator to see what they're set to (see example below). Note that not all props used can be found in build.prop, there's also default.prop, etc.
getprop ro.debuggable

The props can be changed with a Magisk module or with a boot script (don't forget to set the proper permissions for the script to execute) and the resetprop tool.

If you have a ROM (stock is usually a good bet) that can pass SafetyNet or use an app on without modifications, check for props on that ROM that you can change to on the ROM you're having trouble with (also see "Figuring out if an app has dependencies, looks for 'sensitive props', Busybox, etc" below).

Please note that changing prop values may have other consequences for your device than just being able to pass SafetyNet or hide root. If you're experiencing issues after changing prop values, revert them and see if that helps.

Reverting prop values set by MagiskHide

If you for some reason need to reset the prop values that MagiskHide changes (see "Sensitive props" above), you can do this with the Magisk module MagiskHide Props Config. It can also be done by using a boot script that runs the resetprop tool to change back to the desired prop value. Add the following to a file you place in /data/adb/service.d (and don't forget to set the proper permissions for the script to execute):
#!/system/bin/sh
resetprop <property name> <value>

Add whatever property and value you need changed. Changing ro.build.type back to userdebug would look like this:
resetprop ro.build.type userdebug


Busybox

Some apps detect Busybox and see this as a sign of your device being compromised (rooted). Magisk should be able to hide any Busybox installed as a Magisk module. osm0sis has a great Busybox module available in the Magisk repo (install from the Magisk Manager, under "Downloads").

Figuring out if an app has dependencies, looks for "sensitive props", Busybox, etc

It can be tricky figuring out if an app is dependent on another app or process for detecting root, expects certain prop values, doesn't like Busybox or whatever is triggering a root warning within the app. Apart from trying one thing/prop at a time, finding this out could mean you have to decompile the apk to look at the source code (use search), grab a logcat when the app is detecting root, etc.

Detecting apps requiring root

There are apps that detect known apps that require root and refuse to work properly or even start if that is the case. Usual suspects include (but aren't limited to) busybox apps, Xposed installer, root hiding apps, etc.

This can be worked around by uninstalling or possibly freezing (Titanium Backup can do this, among others) the offending root app when you need to use an app detecting root apps and reinstalling/unfreezing it afterwards. Cumbersome, but it might work. There are also some Xposed modules that can hide apps from other apps, but having Xposed installed might cause other issues with tampering detection...







Other things to try


Starting fresh

If you've been trying a lot of things and can't get Magisk to work properly it can be a good idea to start fresh. Start by uninstalling Magisk, flashing a clean boot image and installing Magisk again. If that doesn't work you could try wiping your device and starting out completely clean.

Older versions of Magisk

It is possible that an older version of Magisk may work if the latest does not. This is a last resort and should be considered unsupported. If the latest version of Magisk doesn’t work, but an earlier version does, please help fixing the issue by reporting it with all the necessary details (also see "Asking for help/reporting bugs").

Installation files for earlier releases of Magisk can be found on GitHub. If you need other versions, not available for download, the source code for these can be found in the same place, along with instructions on how to build Magisk.

Please note that there’s no guarantee that an older version of Magisk will work with the current Magisk Manager. Compatible apk's can be found inside the Magisk zip and all Manager releases can be found on GitHub.

Nothing works!

If nothing works and you just can't get Magisk to install/function properly on your device, the best thing you can do if Magisk isn't compatible with your device is to provide as much details as possible and upload logs (recovery log, Magisk log, logcat, whatever is applicable) and a copy of your boot image in the XDA support thread or as an issue on GitHub (also see "Asking for help/reporting bugs").

Canary releases

It's also possible that whatever problem you're facing has been fixed in code, but not yet released. For this you can use the the Canary bleeding edge build. It is a build by topjohnwu that is based on the latest (working) commits from GitHub. Keep in mind that it is a bleeding edge build and may be quite unstable. Only install of you know what you're doing! The Canary Manager is available on GitHub.







Asking for help/reporting bugs


Asking for help

If you can't fix the problem yourself, start by looking in the support thread where you might find that someone else have had this problem as well. Search for your device and/or problem. If you can't find anything (it's a big thread), search again. If you still can’t find anything, provide as much information as possible (in the support thread). For example:







Reporting a bug

When reporting a bug, make sure you have the latest Canary bleeding edge build installed on your device. Otherwise any bug you're reporting may already be fixed upstream. It will also have much more detailed logging enabled (see below).

All bug reports should be made on the the Magisk Github repo. The same tips that are outlined above apply.

Logs

But what if I can't get logs?
Most of the time you can get some kind of log showing what is going on. Keep reading below to see what tools you have at your disposal.

But, if you really cannot get hold of any logs at least try to give as detailed instructions as possible on how to reliably reproduce the issue.

Which log?
Certain issues require different kinds of logs. Here's a list of examples (see further down for details on how to acquire the logs in question), but it's far from a complete list and only meant as an example of what logs may be useful:
















Get the log















Verbose logging
When reporting about issues and bugs, it's useful to have more verbose logging. To get the most information possible, make sure to install the Canary bleeding edge build. It has debug logging active and will show much more useful information. The log is then saved just as the normal Magisk log, described above. When reporting about Magisk bugs, this is a requirement.

The Magisk log is empty

If your Magisk log is empty, it's likely that you have Android logging disabled. Try enabling it.

Could also mean it's faulty somehow. Try grabbing a logcat and see what happens (see above).

It might also be that your kernel/ROM wipes the /cache directory during boot, thus removing the log. See here for details.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki