Reboot and voila. Pixel Launcher replaces Google Now Launcher in the live system parition via bind mount.

Of course Magisk could handle this pretty easily as well, but I'm not going to start distributing Google app APKs in Magisk modules.

Also, to follow up on the idea of having the renamed busybox zip functionality work to uninstall when flashed in Magisk Manager, this isn't possible because Manager renames the zip to only install.zip when it copies it to a temp directory for processing. Just use Magisk Manager itself to uninstall, being the more obvious choice of method.

After that it's all pretty similar except you need to have magisk.img, magisk_merge.img and, for BINDSBIN SuperSU, supersu_is_here added for detection, specify a module name for Magisk (must match what's in the also-required module.prop), and then some generalization is possible using variables:

Naturally if you use File-Based Encryption your recovery will need to be able to support FBE to have detection of paths like /data/adb/su/supersu_is_here work, but for recoveries that don't (*cough* Nexus 5X) SuperSU does handily include a merge mode for anything under /data/supersu_install but since there's no way to detect whether a SuperSU installation is otherwise present without digging into the boot.img I didn't bother trying to leverage this feature to directly work around broken FBE in recovery.

The best way to work around it in those situations is to flash SuperSU first; it'll create /data/supersu_install/supersu_is_here and then all the above script will work. FlashFire also works as an alternative to recovery altogether.

I work on these projects in my limited time off, so if you like the progress I'm making, or enjoy anything else I've done on xda, please do hit the donate link from my profile. Thanks for your support!

Edit: To the 6 users who downloaded the Nexus Media and Adreno zips so far, I've reuploaded them; I had a broken test version of the su.d script in there instead of the final, working one. All is well now.

Hi,
I know shell scripts a bit but I find difficult to understand what these lines do.

Can you please explain them?

Ultimately what they do is look to see if the zygote process is running. If yes set BOOTMODE to true. If no set it to false.

ps is the 'process status' command. It returns a list of running processes with information about them, for purposes here only the name is relevant.

Sidenote: the busybox version of ps (which is what runs within TWRP) is more full featured than the toybox version. One example - toybox version won't accept the '-A' parameter. I think the only thing it does accept is a pid.

For more information on ps check Google. Try 'ps command Linux' or 'ps man page'. For now just know it returns a list of processes, by default ones which belong to the user running the command.

So the output from ps is passed to grep which checks the output for 'zygote' (which is the "master" process when you boot), this output is then passed to fgrep again to remove any lines with 'grep' in them.

Next the return code from the grep is checked. If return code is 0 (&& test) set BOOTMODE to true. If not 0 (|| test) set to false.

The second line starts by testing the value of BOOTMODE. If it's false it runs the 'ps -A' command, tests further for zygote, sets to true if found.

As noted above this second line won't really do anything because 'ps -A' will throw an error in a booted system since toybox will reject it. But what I described is the intent.

Hope this helps. If you have a specific question about part of this then ask.

XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality.Are you a developer? | Terms of Service