[Magisk] topjohnwu:
2016.11.14 Magisk v9

This release comes with significant updates and changes, doing adjustments to pave the road for the next major update v10: the update with Multirom support!

Please spend some time reading this lengthy release note, the most important information are included in quotes, or bolded and colored in RED.

Also, many other fixes not mentioned here are listed in the changelog.

The End of Cache (post-fs) Modules

This shall be the biggest change for this update. One of Magisk's cool feature is that it can mount files before data and build.prop is loaded (post-fs). Most modules only uses this advantage to modify read-only props (e.g. DPI, fake device model etc.) without modifying build.prop, however with a new tool included in this release (will be introduced in the next section), dealing things in post-fs is not needed anymore.

Instead of having both "Cache Modules" and "Normal Modules" at the same time, confusing both developers and users, creating complexity in module management, the decision is made that "Cache Modules" are no longer supported after this update.

How about some features that require mounting in post-fs mode (known: Changing Boot Animation)? No worries, post-fs mode is still there (as Multirom will depend on this), I only removed the interface for modules.

Magisk v9 will remove all installed cache modules under /cache/magisk, which is the previous path where cache modules locate.

Further more, to push developers to upgrade their cache modules, the latest Magisk Manager (v2.5) will filter out cache modules, which means cache modules available in the Magisk repo are NOT shown under the "Download" section in Magisk Manager.

Cache Module developers please refer to the following instructions to update your current module:

Take a look at the changes in this commit (if you're famlier with git, you can just cherry pick this commit, and deal with some minor merge conflicts)

Check the "resetprop" section to understand how to change props without using a cache module, and update your modules accordingly. For example, if you want to replace the build.prop, you no longer need to enable "automount", or bind mount the file manually in your script, as nothing will load it again.; instead, you should enable post-fs-data script, and read your new build.prop file with proper commands. If you want to change certain prop values, just switch from post-fs script to post-fs-data script, and instead of calling "setprop", please call "/data/magisk/resetprop" to set your props.

Remember to remove the "cacheModule" entry or set to false in the module.prop file, or else your module will never show up in the Magisk Download section in the Magisk Manager!

New Badass Tool - resetprop

To be honest, this tool itself deserves a new thread on XDA, as it is super powerful and super cool.

"resetprop", originally named "xsetprop", was initially developed by [MENTION=2605798]nkk71[/MENTION] to bypass the crazy tough detections for Safety Net. Developers found method to bypass the check by modifying the kernel source code, which served the need but the solution is far from perfect as it requires the source code to be available and kernel compiling.

The tool was originally made to directly modify the system prop database. With seeing the potential of this tool, I contacted [MENTION=2605798]nkk71[/MENTION] and start collaborating together, which brings the original simple tool into a full-fledged, all-in-one prop management tool.

Here are some technical details:

System props are handled by "init", a binary located in the ramdisk which starts right after kernel is loaded. "props" are supposed to only have a single writer, and multiple reader, which means only the process "init" has the full control to the prop database. We modify the props (by calling setprop) through an interface called property_service, which will pass the request to init; property_service also handles the triggering of "events" that should be triggered by a prop change. What read-only props means is that property_service will block all requests for modifying props starting with "ro.", as those props are not allowed to be changed once set. To overcome this difficulty, we can mimic how init behaves by directly modifying the trie structured database. However we will not be able to trigger events, as we completely skipped the property_service part. This might be ideal for SN bypasses, but not applicable for Magisk, as I want to load any prop, which should trigger some events to make some changes. So we went a step further and added a feature to "delete" a system prop! As a result, by directly deleting the prop entry in the database, then send a request to property_service, property_service will accept the request and trigger events if needed.

The tool is originally built with AOSP source, I spent some time to make it much more portable.

Here is the link to the NDK-buildable source of the resetprop used in Magisk: https://github.com/topjohnwu/resetprop

Magisk Hide - Greatly Improved

Another update to pass SN, please grab it before it expires lol

People started to panic when Google device to check boot loader / boot-verity etc. As stated in the previous section, resetprop fixes the issue easily with setting all detecting props to the valid values. However, more detection has been added. One of those is that simply adding Magisk directories into PATH will break Safety Net. Not sure if I should be glad because the word "magisk" is now officially on the tech giant's blacklist......

So in order to hide root (here I'm only referring Magisk phh superuser, as SuperSU users shall always rely on CF's suhide, not MagiskHide), I had to change the way things works.

Development

I added build.sh into the main Magisk repo, you can call the script and it will guide you with help messages.

Custom version names are supported, both in Magisk and Magisk Manager (if using custom name, update will disable)

So feel free to clone the repo and develop Magisk yourself! Pull requests are appreciated!

For Magisk Manager, you can provide translations for the app, just translate the strings, create a pull request, and I'll merge it into the main app, many thanks!

Those Pixels

I stated before that the new Google Pixel devices are using a complete different partition structure, as the ramdisk is now stored along with the system partition, and a kernel modification is inevitable.

Without much surprise, our mighty developer Chainfire had released a systemless root for Pixel devices. What it does in a nutshell is bringing back the ramdisk to the boot image, and still do modifications in the ramdisk (rootfs). However it still requires 1. custom init binary 2. binary patch directly to the kernel. If I decide to use the provided closed source solution, it shall not be difficult to port Magisk to the Pixels and start all the systemless craziness, but still I need an device to test and debug. In addition, I would love to see if I can create an open source tool to achieve similar results to make Pixel (which means maybe all future devices) running Magisk.

But the huge issue is: I live in Taiwan, and there is no sign that the Pixels will be available for purchase here, well at least not possible in 2016.

I could ask my buddy studying in the US to bring me one when he comes back at the Christmas vacations (which is still quite some time from now, but still better late than nothing.....), however the problem is that Pixel XLs (the model I prefer) are currently out of stock on the online Google Store, and I will never know if ordering now will make the package show up in my friend's place in time before he comes back to Taiwan.