Add Magisk as a module

[samueldr]

Yes, I'm closing this as I open this, to document why it won't work.

It's simply not feasible easily.

• Way to build Magisk into a ROM via aosp build process topjohnwu/Magisk#509 (comment)
• AOSP Build requirements? topjohnwu/Magisk#2144 (comment)

It is built with the expectation that it is self-installing on-device. Integrating Magisk in the ROM would require a major fork to Magisk until they start supporting such a scheme upstream.

Doing so would be possible by forking Magisk and doing hard work to stay compatible, but it's not a simple integration.

For what it's worth, its whole way of working runs counter to doing custom builds. It may be worthwhile to rather investigate doing implementing whatever you intended to use Magisk as a more integrated build step.

[danielfullmer]

I wholeheartedly agree with this:

For what it's worth, its whole way of working runs counter to doing custom builds. It may be worthwhile to rather investigate implementing whatever you intended to use Magisk as a more integrated build step.

[Atemu]

A thought just crossed my mind on this, couldn't you just add Magisk after the android build?

Would it be possible to create an OTA package which first installs the actual OTA zip and then follows it with the Magisk zip for example? Or perhaps even just letting the Magisk installer run on the system image and repackage it.

This way we wouldn't have to include Magisk in the AOSP build process and could enable it without a rebuild.

[danielfullmer]

So, I know very little about Magisk, so realize that everything I am about to say could be wrong:

But I believe this project attempted to do something like that: https://github.com/CaseyBakey/chaosp
The build script is based on RattlesnakeOS's tempates with some modifications. See the add_magisk() function in build.sh. It looks like they try to modify the target-files after building.

However, I still think the "right way" to make modifications to the OS is directly in the source tree before building. That way, at the very least, you retain all the benefits of verified boot. The other reason you might want to use Magisk would be to pass Safetynet with a modified OS. It seems unlikely that this will work in the long-term, as Google is likely to (in the process of?) add(ing) a remote hardware/software attestation requirement for passing safetynet.

[Geofferey]

Super easy, see my comment on #509
topjohnwu/Magisk#509 (reference)

[danielfullmer]

This could be a good candidate for an "external module" (https://docs.robotnix.org/development.html#external-modules), since I don't think it should be included in the robotnix repository.

[Atemu]

Another solution has materialised that integrates Magisk while signing and retains avb: https://gist.github.com/mohrezaei/fe76ab2091e834b6edb2ab9f11e31c07

[Atemu]

I've been trying my hand at this and made some progress a few days ago: Atemu@ab2c1c4

I need to figure out how exactly the script needs to be touched to work as intended though.

I've now re-discovered this issue and @Geofferey's links: https://github.com/sfX-android/android_vendor_extendrom Geofferey/omni_device_oneplus_oneplus8t@20b4502

It honestly seems simpler to just run the patcher inside a Nix derivation to me though which is why I'll try pursuing this first.

[Atemu]

Success! #266

This gets us into the state where Magisk is installed but the app still prompts for "additional setup" upon the first boot as if we installed via recovery for some reason.

I thought patching the boot image directly didn't have that limitation? Odd. This is more than acceptable however.

[Atemu]

Apparently the additional setup thing is about the magisk binaries being present on the system in a non-volatile magisk dir as checked by this function:

https://github.com/topjohnwu/Magisk/blob/5885b8c20d555dbde3c3d3c9c605fcb438a906a6/scripts/app_functions.sh#L13-L26

That doesn't look like anything we could reasonably fix. I guess we could create some sort of service to bake into the ROM which installs these to the right place or something but that sounds hacky and upstream should probably just re-engineer this.