Root access in Android as of 2018

I already wrote about the topic “rooting of Android” in 2013. Since then the direction of Android itself changed a lot.

Things which where not very popular five years ago are now quite normal: films are being watched on mobile devices with services such as Netflix and games like Pokémon GO generate huge sales (by the end of 2017 about 890 million USD). For the providers of such services it is of course important that the data of the apps is not accessible by third parties – for example to protect DRM mechanisms.

Another area are payment services, such as Google Pay, which got introduced in 2015 – and again, it is important that no third party can access confidential data.


As a protective measure, Google introduced a new mechanism in 2015 called “SafetyNet”. This allows app providers to prevent the installation or use of apps if the system does not meet certain security requirements – for example because root access has been detected or the use a modified version of Android.

You can find a more detailed description in the article series of John Kozyrakis.

However, this also means that the long-established method of “rooting” a device by modifying the system partition and installing tools such as “SuperSU” can no longer be used any more, as many apps may refuse to work then.

Systemless Root

The long-established method of providing root access was to deploy the program /system/bin/su or /system/xbin/su and installing an access control app, such as SuperSU. One of the tests of SafetyNet is therefore to recognize the existence of these programs.

An alternative approach is to modifiy just the boot image but not to change anything in /system. An advantage of this method is that from the perspective of SafetyNet there is no root access and apps that require a successful SafetyNet check remain usable.

Root access with Magisk

The name “Magisk” is an artificial word based on “Magic Mask”. This program combines root access with the enhancements by modules to modify the system without making any changes to /system – like putting a mask onto the system. Added to this is the ability to “hide” the existence of Magisk from apps.

A big advantage compared to SuperSU is the fact that the source of Magisk is available completely on Github. Also see This is also true for the modules for Magisk which you can find at


A prerequisite for the installation of Magisk is a custom recovery, like TWRP, as I described it in my article about CarbonROM on the Sony Xperia Z3 Compact. After downloading the latest version of, it will be installed with TWRP the usual way. As part of the installation, the Magisk installation script modifies the boot image and sets up the “Magisk Manager” app, which is then used to configure it during operation.

If SuperSU had already been installed, it is usually necessary to reinstall the existing CustomROM in TWRP before installing Magisk in order to reliably remove the modifications made by SuperSU. Existing apps and data will not be deleted. The CustomROM must not have integrated root access build in. Alternatively, you can use the methods provided to remove the root access, as in LineageOS, for which a corresponding script for TWRP is offered. If this point is ignored it will be difficult, if not impossible, to achieve a successful SafetyNet check later.

Magisk Manager

Through the app “Magisk Manager” both the root access and the configuration of Magisk and extensions via modules are done.

In the start screen of the app you can see at a glance if you have already installed the latest version of Magisk and have the opportunity to run a SafetyNet exam. The latter requires access to Google components that are not part of Magisk, so the first time you run this test, you must explicitly agree.

The menu provides access to the various parts of the manager, such as root access control or the installation of additional modules.

Modifications for SafetyNet

With the “Magisk Hide” feature in the manager you can hide the existence of Magisk for individual apps. Here you should at least select the Google Play Store and the Google Services Framework.

However, when using a CustomROM, it is very likely that the SafetyNet check still fails at “ctsProfile”. This means that apps which require SafetyNet are not usable. The reason for this is that the device delivers a non-compliant fingerprint of the CustomROM.

A solution for this is the module “MagiskHide Props Config”. Once this module has been installed and the device has been restarted once, you can set a “permitted” fingerprint via a console (optionally with a corresponding terminal app on the device itself or via an ADB shell) with the following commands:


Also see the documentation of the module which also covers additional methods if this step is not enough.

Special issues for TitaniumBackup

If TitaniumBackup shows a warning that the existing SU version may cause problems you can just ignore that and also turn off that warning completeley. All features of TitaniumBackup are still useable.

Leave a public comment

Your email address will not be published. This is not a contact form! If you want to send me a personal message, use my e-mail address in the imprint.