General [Magisk] Magisk Zygote64_32: Enabling 32-bit Support For Apps

[Namelesswonder]

Alright I've found the problem, turns out Mainline updates are the culprit.

However it's a culprit I can't work around.

The issue is that Google Play system updates will only install the relevant parts for whatever ABIs are currently supported on the device. On a stock device that will be only arm64-v8a. The bootloops are because APEXs that contain armeabi-v7a components needed for the 32-bit subsystems to come up aren't available.

I've tried to find a workaround, however Mainline updates can only be rolled back by one version, can only be done by the system, and the rollbacks are only kept around for 14 days. Trying to uninstall APEXs and Mainline updates through the package manager will generally end up with either an unbootable system or if you can get into Android it's unusable.

I've never come across this problem because when I do my testing I don't sign in to a Google account, and Google Play system updates are only installed if you sign into a Google account. Kind of wild that your device will not get somewhat important updates unless you sign into a Google account. If you don't then you'll be using whatever Google has bundled into the Android firmware, which to this day are still only bundling in the October 2022 updates.

If you did a clean install with the mod then you are fine, Google Play system updates will install the 32-bit components. Android system updates with the mod active are also fine, as the 32-bit components are used.

Due to this I will have to retract the wipeless installation steps as they will only work properly for the people that don't sign in to a Google account, which is honestly going to be no-one.

@Enddo Sadly the video you are making will have to use the instructions that involve a wipe.

@badabing2003 PF is going to have to be updated so that if my Magisk isn't detected then installing will require a wipe.

 

[badabing2003]

@badabing2003 PF is going to have to be updated so that if my Magisk isn't detected then installing will require a wipe.

Just to get this right,
When flashing an update, and the selected init_boot if it is patched with Magisk Zygote64_32, I should look for existing rooted Magisk Zygote64_32, if it is not found, I should warn the user that unless they choose wipe, they will have problems, and if they don't choose wipe, PF will abort.
Does that sound right?

 

[Namelesswonder]

Just to get this right,
When flashing an update, and the selected init_boot if it is patched with Magisk Zygote64_32, I should look for existing rooted Magisk Zygote64_32, if it is not found, I should warn the user that unless they choose wipe, they will have problems, and if they don't choose wipe, PF will abort.
Does that sound right?

Yeah that sounds right. If the tool also has the ability to flash Magisk when not performing an update it would also need the same check. As for aborting, that is up to you. Not performing a wipe can work but it's only going to work with the 0.001% of users that don't log into a Google account as Google Play system updates are installed immediately and in the background.

I'm also looking at some point to change the package name so uninstalling stock Magisk isn't required, to help reduce the number of steps. I'll need to do testing though to see if Magisk is capable of updating itself when the package name changes.

 

[Enddo]

Just to be accurate, I suppose you meant bootloader mode right?
You flash init_boot in bootloader mode not user space fastboot.

Your other steps look to be right.
By any chance did you have any Magisk modules installed with your previous Magisk?

the OP mentions that you can flash that file in fastbootd mode. so that is what I tried at first. but fastboot mode is just another name for bootloader mode, right? (if you do adb reboot bootloader, then it just takes you to fastboot mode)

after I was getting the bootloops, I then rebooted out of fastbootd, and back into bootloader mode and tried it that way. but it still resulted in a bootloop for me

and no, no magisk modules installed. as I mentioned, I went from Android 14 beta to the April build of Android 13 (with android flash tool). the only thing I did after that was install the stable build of Magisk (since my viewers are likely to have the official build of Magisk installed). so no, no magisk modules installed on this phone during yesterday's attempts

edit - I see @Namelesswonder figured out the issue. that is interesting to hear about the Mainline updates and the google account (agreed, really strange that Google would restrict this)

thanks for looking into it again. I appreciate the work you've done/you're doing for the community. I should be able to get a video up that mentions the wipe is required and highlight all of the steps involved

 

[Namelesswonder]

the OP mentions that you can flash that file in fastbootd mode. so that is what I tried at first. but fastboot mode is just another name for bootloader mode, right? (if you do adb reboot bootloader, then it just takes you to fastboot mode)

after I was getting the bootloops, I then rebooted out of fastbootd, and back into bootloader mode and tried it that way. but it still resulted in a bootloop for me

and no, no magisk modules installed. as I mentioned, I went from Android 14 beta to the April build of Android 13 (with android flash tool). the only thing I did after that was install the stable build of Magisk (since my viewers are likely to have the official build of Magisk installed). so no, no magisk modules installed on this phone during yesterday's attempts

edit - I see @Namelesswonder figured out the issue. that is interesting to hear about the Mainline updates and the google account (agreed, really strange that Google would restrict this)

thanks for looking into it again. I appreciate the work you've done/you're doing for the community. I should be able to get a video up that mentions the wipe is required and highlight all of the steps involved

There's two implementations of the fastboot protocol, one that runs in the bootloader (fastboot) and one that runs in the recovery (fastbootd).

Fastboot inside the bootloader has almost full permissions, is able to control device unlock state, along with being able to manipulate most protected partitions like the bootloader itself.
Because of Android rapidly growing in size Google had to change how devices are partitioned, as the partition table is set at the factory and the system partitions have to be oversized to account for the growth of later Android versions.

The solution is dynamic partitions, which put the common system partitions (system, vendor, product, odm) inside a single partition (the super partition) and then use device-mapper in Linux to mount them as logical partitions. This allows for the partitions to be arbitrarily resized, and only the super partition needs to be oversized. Google set the size of the super partition on the Pixel 7 to about 8GiB. However because the system partitions are now logical partitions only understood by Linux they can't be written to by the bootloader.

Fastbootd runs inside the recovery, and the recovery is a stripped down Android. It's called "userspace fastboot" as it's running as a process under Linux (thus fastboot daemon). Due to this it's able to mount and interact with the logical partitions, allowing it to carry out the latter half of the flashing process. It doesn't implement all the functions of the fastboot protocol, so can't change device unlock state and because you're already booted some partitions can't be manipulated.

 

[Dynarenji]

Can you tell me what games are giving you issues so I can test. It's possible some games may not work as Android doesn't guarantee full compatibility with all old apps, especially if they use hidden methods or use APIs in unintended ways. However, games force closing may be indicative of an incomplete install. If you can get a logcat of attempting to launch the app that would be helpful. As for my Magisk Delta fork, I'm waiting for it to be rebased on Magisk v26.1 which should be sometime soon, at which point I can then update my fork. I can't guarantee that my fork will work on May, but it did work on February/March back when I released it.

The patched init_boot is fine, it is identical to what I was using.
The steps you took appear fine. I'll be recording my steps and output to see if there is any difference.

well it;s modded game for guardian tales, the modder only support 32-bit so i can't update my firmware, i tried and it's become mess up and in the end i need to reset my pixel 7 pro....

 

[Enddo]

Alright I've found the problem, turns out Mainline updates are the culprit.

@Enddo Sadly the video you are making will have to use the instructions that involve a wipe.

I think you said you'll be changing your version of Magisk to use a different package name, which would reduce the number of steps involved in the way to install/set it up.

So I'll wait for that update to be released and you revise your instructions so I don't end up publishing a tutorial video that gets outdated too quickly

Thanks for the work you've put into this mod, I've been getting tons of requests on my channel for how to enable 32-bit support for the Pixel 7 / Pixel 7 Pro

 

[Alitheia]

Thanks this clarifies the bootloop issues that I was having. I am signed in to a Google account. I have no wish to wipe, so I guess I'm stuck on 64-bit for a while. Hopefully, Google will make some changes to this.

 

[yurishouse]

Any plan for updates on this yet? There's a couple revisions of magisk alpha/canary since last release.

 

[badabing2003]

Any plan for updates on this yet? There's a couple revisions of magisk alpha/canary since last release.

As far as I know they are both at version 26.1
or to be precise, canary 26101
Unless updates are being released without version increments, I see this to be at par.

 

[t3chwizard]

Am I correct in my understanding that it is not advisable to update to the May Security patch from any prior version with the 32-bit Magisk fork (I am still on the February security update) as it can cause a bootloop?

This is just what I have gathered from reading replies from about May 6th or so

 

[badabing2003]

Am I correct in my understanding that it is not advisable to update to the May Security patch from any prior version with the 32-bit Magisk fork (I am still on the February security update) as it can cause a bootloop?

This is just what I have gathered from reading replies from about May 6th or so

Not sure where you gathered that.
If you are already on Magisk Zygisk64_32 then as far as I understand wipe will not be required, as upgrade wise there shouldn't be any issues, you just have to make sure (if you're doing it manually) you modify the flash_all script and don't let it reboot to system when it is done flashing, so that you can flash patched boot with Zygisk64_32.
@Namelesswonder can chime in if I'm off track.

 

[t3chwizard]

Not sure where you gathered that.
If you are already on Magisk Zygisk64_32 then as far as I understand wipe will not be required, as upgrade wise there shouldn't be any issues, you just have to make sure (if you're doing it manually) you modify the flash_all script and don't let it reboot to system when it is done flashing, so that you can flash patched boot with Zygisk64_32.
@Namelesswonder can chime in if I'm off track.

Alright thanks, I could have been confused but I'll wait for @Namelesswonder to verify because I'd rather be safe than sorry and end up having to clean flash

 

[badabing2003]

@Namelesswonder
Have you checked if going the Full OTA route of patching would make a difference in the sense of avoiding a wipe?

 

[Namelesswonder]

Any plan for updates on this yet? There's a couple revisions of magisk alpha/canary since last release.

As far as I know they are both at version 26.1
or to be precise, canary 26101
Unless updates are being released without version increments, I see this to be at par.

Got busy the last few weeks, I'll work on testing a newer version end of this week. I build off of head rather than the commit at which the latest canary was built, so my release is closer to 26102 than 26101.

Am I correct in my understanding that it is not advisable to update to the May Security patch from any prior version with the 32-bit Magisk fork (I am still on the February security update) as it can cause a bootloop?

This is just what I have gathered from reading replies from about May 6th or so

It's no problem to update, I've been doing so on Android 14 with almost no issue. The only problem I had was taking a couple OTAs after having disabled AVB, which wasn't a problem my Magisk, just a problem with OTAs and messing with AVB.

@Namelesswonder
Have you checked if going the Full OTA route of patching would make a difference in the sense of avoiding a wipe?

I'll have to look into it, looks interesting.

 

[t3chwizard]

It's no problem to update, I've been doing so on Android 14 with almost no issue. The only problem I had was taking a couple OTAs after having disabled AVB, which wasn't a problem my Magisk, just a problem with OTAs and messing with AVB.

Thanks a bunch, I'll probably update to the latest Android 13 security patch today

 

[Namelesswonder]

Updated Magisk will be out sometime within the next couple days after I do more testing.

Changing the package name may or may not happen, as it's going to require manual intervention and patching a stock init_boot to flash.
The full app will download and install the updated package, but because of the package name change it'll be installed as a separate app. Because of how Magisk works the new package won't have root permissions, requiring the aforementioned manual patch and flash to begin using it.
Surprisingly stub app didn't care about the package name changing when updating, and appearing to work just fine, but when direct installing to then update the Magisk daemon it led to an unbootable system.
I'll have to find out why that happened, to figure out if it was the stub becoming broken in the update or if the newest Magisk commits break direct install.

So far the newest commits past 26102 don't appear to overtly break anything, but if things are then I'll instead base the new version on 26102.

 

[t3chwizard]

Thought I'd post an update. I was able to update from the February security patch to the May security patch on my Pixel 7 with no issues yesterday. I didn't even disable zygisk, lsposed or any magisk modules. It just worked. Thanks a bunch for the continued support of this magisk fork

 

[Lok980]

May I ask how could I see the spoiler content??

 

[badabing2003]

May I ask how could I see the spoiler content??

You seem to be a new user, perhaps there is a minimum post count or another criteria before you can click to view.