-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Magisk as a module #14
Comments
I wholeheartedly agree with this:
|
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. |
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 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. |
Super easy, see my comment on #509 |
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. |
Another solution has materialised that integrates Magisk while signing and retains avb: https://gist.github.com/mohrezaei/fe76ab2091e834b6edb2ab9f11e31c07 |
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. |
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. |
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: 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. |
Yes, I'm closing this as I open this, to document why it won't work.
It's simply not feasible easily.
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.
The text was updated successfully, but these errors were encountered: