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

Search This thread

Bulletro

Member
Jan 17, 2023
9
3
Hey Namelesswonder, I was just wondering if you had implemented json support yet or if any progress has been made for easy updating and integration with pixel flasher etc. since I saw that you had mentioned it.
 

Namelesswonder

Senior Member
Jan 26, 2014
431
720
Google Pixel XL
Google Pixel 7 Pro
Will you be working on patching the new official magisk release (v26) with 32-bit support?
Yes, this would be awesome and very appreciated. I still have some old games that are 32-bit. Thanks!
It's out now. It wasn't that much of an update since my fork had commits up to March 9th and had the bulk of changes, although stability with Zygisk was improved in later commits since the hooking was refined and has become less crash prone.

Hey Namelesswonder, I was just wondering if you had implemented json support yet or if any progress has been made for easy updating and integration with pixel flasher etc. since I saw that you had mentioned it.
The download repository now has canary and debug channels. Updating should be easier now.

Do you still have to wipe after patching the boot image?
I have this nasty Collect N Win app at http://nycollectnwin.com/android_install.html that doesn't work with 64 bit Pixel 7 Pro. Look forward to Namelesswonder's revised instructions on official Magisk 26001. Thx. I may still pass due to the data wipe requirement
I forgot to update the instructions for the wipeless installing, I'll get them put up in the original post later today. If you're already on the April update then it'll be too late to do wipeless unless Google releases another April build, if not then you'll have to wait until May.

Big Update - Magisk Zygote64_32​

In the making for a bit, haven't had the time lately to put aside for the project, but better late than never.

Magisk Zygote64_32 2ee5dc0f (26101)


Name Change​

The project has been renamed to "Magisk Zygote64_32", since the previous name of "Magisk 32-bit" was ambiguous as to whether it was for 32-bit devices or if it added 32-bit support for multilib Zygote64 devices.​

Update Channels​

The download repository now has the channel JSON files, so updates can now be rolled out via the app.​
Currently it is untested whether the stub is capable of downloading the full app, and whether debug <-> canary channel swaps can be done.​
Because the previous releases forced the update channel to custom the app on preexisting installs will not get updates until you manually change the channel to canary or debug, and you will have to manually update to 2ee5dc0f to restore updating
Currently only the canary and debug channels are active, stable and beta just redirect to canary

Updated to v26.1 (26101)​

Magisk Zygote64_32 2ee5dc0f (26101) is based on 468f3efb

Works on Android 14 Beta 1​

I've been testing it today and so far have not had any problems that would occasionally pop up on the previous release.​
I'll get around to making newer Magisk Delta build at some point, however I'm probably not going to be setting up an update channel for that, nor am I going to be doing much testing on it since I don't have a second device to do development with.
 

Namelesswonder

Senior Member
Jan 26, 2014
431
720
Google Pixel XL
Google Pixel 7 Pro
Wipeless instructions are up in the original post.

Currently if you are on March still then you can easily perform the wipeless upgrade.
If you are on April then you will either have to wait until the May update releases or you can try the downgrade instructions.
If you are on QPR3 or Android 14 then somewhat tough luck, you can try finding an older QPR3/Android 14 DP firmware image to perform the downgrade steps.
Be warned, downgrading can result in data loss, however because March and April are on the same QPR it shouldn't happen. Still, backup your data.

You're essentially flashing the older firmware and patched Magisk for that older firmware, booting, then flashing the newer firmware and patched Magisk for the newer firmware.
 

badabing2003

Recognized Contributor
Sep 17, 2012
2,324
3,308
Thanks for the wonderful work and guide.
on user requests, I'm trying to automate this into PixelFlasher as much as possible (Me too don't actually use any 32 bit apps), I have some questions if you don't mind (and more might come as I get to implement it)

For Wipeless upgrade:

Upgrading Steps:​

Requisites: current firmware image and firmware image you are upgrading toNote: If you are unrooted and stock then skip to step 4
  1. On your phone uninstall the stock Magisk app. Do not use the uninstall Magisk button from within the app, simply just uninstall the app itself.
  2. Reboot your phone into the bootloader.
  3. Flash the stock init_boot.img for your currently running build version and then boot into Android.
  4. Install the Magisk Zygote64_32 app from my repository.
  5. Copy over the stock init_boot.img for the build version you want to upgrade to onto your phone and patch it in the Magisk app.
  6. Copy the patched Magisk init_boot.img over to your computer
  7. Reboot your phone into the bootloader.
  8. Flash the newer build you want to update to with fastboot --skip-reboot update newer-image-xxx.zip
    • Do not use -w or you will wipe your device.
    • It may be necessary to also update the bootloader and radio beforehand.
  9. Wait for it to finish, then flash the patched Magisk init_boot.img and boot into Android.
    • Flashing init_boot is possible from within fastbootd, so you don't need to reboot to the bootloader.
  10. Install the Magisk Zygote64_32 app from my repository.
  11. Open the Magisk app and finish setup for Magisk.

  • Step 4 install Magisk Zygote64_32 app, and so does step 10, I don't see an uninstall in between, is a reinstall necessary?
  • Step 1 can be performed after step 3 right? there is no absolute need to do it as the first step?
  • Assuming that one has already done this with the previous firmware, and are already on Magisk Zygote64_32 (let's say April release), when it is time to upgrade (let's say to May release), it is not clear to me if a stock init_boot of April firmware needs to be flashed before doing step 5 and the following steps.
    Should the guide add a note that if you are already on Magisk Zygote64_32, skip to step 5?
  • After doing steps 5 - 9 with the May release, and assuming that step 10 is not necessary (app already previously installed), is there still a need for step 11 ?
Thanks
BB
 

Namelesswonder

Senior Member
Jan 26, 2014
431
720
Google Pixel XL
Google Pixel 7 Pro
Thanks for the wonderful work and guide.
on user requests, I'm trying to automate this into PixelFlasher as much as possible (Me too don't actually use any 32 bit apps), I have some questions if you don't mind (and more might come as I get to implement it)

For Wipeless upgrade:


  • Step 4 install Magisk Zygote64_32 app, and so does step 10, I don't see an uninstall in between, is a reinstall necessary?
  • Step 1 can be performed after step 3 right? there is no absolute need to do it as the first step?
  • Assuming that one has already done this with the previous firmware, and are already on Magisk Zygote64_32 (let's say April release), when it is time to upgrade (let's say to May release), it is not clear to me if a stock init_boot of April firmware needs to be flashed before doing step 5 and the following steps.
    Should the guide add a note that if you are already on Magisk Zygote64_32, skip to step 5?
  • After doing steps 5 - 9 with the May release, and assuming that step 10 is not necessary (app already previously installed), is there still a need for step 11 ?
Thanks
BB
  1. Forgot to take out step 10 when I was rewriting them from the wipe installation, it isn't necessary since the app will still be there.
  2. Yes they can be swapped, all that matters is that the device isn't running stock Magisk as it will immediately uninstall the my version since I have signed it with my own keys. I probably should change the package name on mine so there isn't this conflict.
  3. These steps are just installation steps, once installed then you only have to follow the system upgrade or Magisk upgrade steps that are further in the post which are the typical upgrading steps for rooted systems and Magisk. The installation steps are just to get Android to setup the 32-bit libraries, once they are setup they stay so, until a wipe or if the user boots into a different build version of Android without running my Magisk.
  4. For a system that has never run my Magisk then yes step 11 is necessary since it ties the app to the kernel process. This isn't ever needed afterwards.
 

badabing2003

Recognized Contributor
Sep 17, 2012
2,324
3,308
I probably should change the package name on mine so there isn't this conflict.
I was wondering about that, let me know the package name if you ever change it so that I make the necessary adjustments in PF.

These steps are just installation steps, once installed then you only have to follow the system upgrade or Magisk upgrade steps that are further in the post which are the typical upgrading steps for rooted systems and Magisk.

Yep, my bad, seeing Upgrading under Wipeless, I wrongly assumed that those were the upgrade steps for already installed Magisk zygot64_32, I see it now and it's super clear, and no different that normal Magisk. (y)

One other question, is there an easy way to detect if multilib is supported, so that I could warn / block the user from attempting to install this version? Or should I leave it to your app to do that?

Thanks for the feedback.
 
  • Like
Reactions: Namelesswonder

Namelesswonder

Senior Member
Jan 26, 2014
431
720
Google Pixel XL
Google Pixel 7 Pro
I was wondering about that, let me know the package name if you ever change it so that I make the necessary adjustments in PF.



Yep, my bad, seeing Upgrading under Wipeless, I wrongly assumed that those were the upgrade steps for already installed Magisk zygot64_32, I see it now and it's super clear, and no different that normal Magisk. (y)

One other question, is there an easy way to detect if multilib is supported, so that I could warn / block the user from attempting to install this version? Or should I leave it to your app to do that?

Thanks for the feedback.
There isn't an easy way to detect if the system is multilib or not, and worse there is no easy way to detect if a system is completely multilib with full coverage.
It would be entirely possible for a device to release with the Zygote process set to be 64-bit only and for it to have a limited amount of 32-bit libraries, meaning that 32-bit apps won't be able to run.

Right now there are testing firmwares for older Pixels that are truly 64-bit only and aren't multilib, but as outlined on the page the Pixel 7 is an outlier and is still multilib.

Really the easiest block to put in would just be to check if device or firmware is a Pixel 7, since as far as I know these are the only devices that have a 64-bit only Zygote and are fully multilib.

I haven't modified the Magisk installer to block other devices, so it actually would have no qualms about running on another device. The modification will have no effect on 64-bit devices that support 32-bit, since they already have the properties set to do so, in fact I'm running my version on my Pixel XL without issue. However on a truly 64-bit only device my Magisk will cause the system to not boot.

The problem that is going to crop up will be later Pixel devices. Potentially even as early as the Pixel 7a or Tablet, Google could decide that they've had enough testing and ship out the firmwares for them with only 64-bit libraries. For the Pixel 8 there will be no way around this anyway since Tensor G3 isn't even going to be able to execute 32-bit instructions.
 
  • Like
Reactions: badabing2003

wowkazmir

Senior Member
Aug 16, 2010
117
18
Thanks for the large update! Trying to avoid a wipe or downgrade, I first attempted to update the app and then use the install directly option. While this probably works just fine I then went ahead and patched the April init_boot file with your latest modifications. I believe flashing it through fastboot could end up being more stable in the long run. Either way, I am able to run 32-bit apps still and just wanted to share this!
 
Last edited:

Superguy

Senior Member
Nov 28, 2007
976
202
Baltimore
Thanks for the wonderful work and guide.
on user requests, I'm trying to automate this into PixelFlasher as much as possible (Me too don't actually use any 32 bit apps), I have some questions if you don't mind (and more might come as I get to implement it)

For Wipeless upgrade:


  • Step 4 install Magisk Zygote64_32 app, and so does step 10, I don't see an uninstall in between, is a reinstall necessary?
  • Step 1 can be performed after step 3 right? there is no absolute need to do it as the first step?
  • Assuming that one has already done this with the previous firmware, and are already on Magisk Zygote64_32 (let's say April release), when it is time to upgrade (let's say to May release), it is not clear to me if a stock init_boot of April firmware needs to be flashed before doing step 5 and the following steps.
    Should the guide add a note that if you are already on Magisk Zygote64_32, skip to step 5?
  • After doing steps 5 - 9 with the May release, and assuming that step 10 is not necessary (app already previously installed), is there still a need for step 11 ?
Thanks
BB
Thanks for this. I hope you can get it to work!

I really want to use Swype (32 bit only) but I find the current methods too complicated. Would be nice if there'd be a way to recompile apps for 64 bit too.
 

badabing2003

Recognized Contributor
Sep 17, 2012
2,324
3,308
Thanks for this. I hope you can get it to work!

I really want to use Swype (32 bit only) but I find the current methods too complicated. Would be nice if there'd be a way to recompile apps for 64 bit too.
App recompilation would have to be made to the specific app developers, as of PixelFlasher, the next version will support installing Magisk zygote64_32, creating a patch with it and flashing.

Please keep in mind that PixelFlasher is primarily for Pixel phone, although most of its features would work for other phones, they remain untested.
 
  • Like
Reactions: supermansaga

thatrunks

Senior Member
Sep 27, 2007
78
40
Zwijndrecht
@Namelesswonder

Thank you so much for this!
I'm using the LineageOS 20 MicroG build (lineage-20.0-20230409-microG-cheetah) from April 9th.
And used the init_boot.img from this version: 13.0.0 (TQ2A.230305.008.C1, Mar 2023) (cheetah-tq2a.230305.008.c1-factory-cefc4e56)

I followed these instructions;

Steps:​

Note: If you already have backed up your persist partition then you can skip steps 4 to 7.
  1. Install my Magisk Delta 32-bit app, it may be installed alongside stock Magisk without issue as it has a different package name.
  2. Copy over the stock init_boot.img to your phone and patch it in the Magisk Delta 32-bit app.
  3. Copy it back over to your computer
  4. Enter a root shell via either method
    • adb
      • adb shell
      • su
        • You will need to approve the attempt on your phone
    • Terminal emulator
      • su
  5. Run the following command:
    • dd if=/dev/block/by-name/persist of=/sdcard/persist.img
  6. Copy persist.img over to your computer, keep it safe, keep it in multiple places.
    • This is not the Google Pixel 7 persist image, this is uniquely your phone's persist image.
  7. Reboot phone to bootloader

    SKIPPED STEP 8 AND 9
  8. Flash and wipe via fastboot --skip-reboot -w update image-xxx.zip.
  9. Wait for it to finish, then reboot back into the bootloader either on the device or with fastboot reboot bootloader
    SKIPPED STEP 8 AND 9
  10. Flash the patched Magisk init_boot.img and boot into Android.
  11. Complete the setup wizard as normal
  12. Install my Magisk Delta 32-bit app.
  13. Open the Magisk app and finish setup for Magisk.

Every 32 bits app are installing and working, especially the older ones I used and couldn't install. Even Flappy Bird. Was looking for a donate button to support you for this great fix.
 
Last edited:

Superguy

Senior Member
Nov 28, 2007
976
202
Baltimore
App recompilation would have to be made to the specific app developers, as of PixelFlasher, the next version will support installing Magisk zygote64_32, creating a patch with it and flashing.

Please keep in mind that PixelFlasher is primarily for Pixel phone, although most of its features would work for other phones, they remain untested.
Oh I'm on a pixel. My thoughts were actually 2 separate thoughts.

I didn't expect PF to be able to recompile anything, just that it would be cool if apps could be recompiled so such hacks wouldn't be necessary.
 
  • Like
Reactions: badabing2003

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    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.
    2
    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.
    2
    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
    1
    I use custom kernels.

    Also thought they were required for the safety next fixes to Wallet would work?
    Custom kernel - Yes
    USNF - No
    1
    I went through the upgrading steps outlined in the OP and ran into a bootloop with my pixel 7 Pro
    not sure how I messed this up

    at first I thought it was because of the version of ADB that I had installed. since I was getting an error saying archive does not contain 'vendor_other.img'

    but even after downgrading platform tools to 33.0.3, and trying again, I got the same error
    i then tried to use the android flash tool to manually flash the May security update (updating from April using the steps in the OP)

    and then pressing the volume down button after it completes (so it doesn't boot into android). but when I flash the magisk_patched file from the modified version of magisk (Magisk Zygote64_32) linked here - https://github.com/Namelesswonder/magisk-files

    that is where I run into the bootloop. I patched the init_boot.img file from the May update and was flashing that with fastboot. but that's what makes me go into a bootloop

    when I flash the stock may init_boot.img file, it booted up like normal. so I'm at a loss as to what is going on
  • 29

    The 32-bit apps are back!​

    Synopsis​

    The Pixel 7 line is Google's first "64-bit only" phones, along with being the highest profile release of a 64-bit only device so far. The device uses the Tensor G2 (GS201), which is a close descendant of the Tensor (GS101) from the Pixel 6 line. So close, that the only major change was swapping out the ARM Cortex-A76 cores for ARM Cortex-A78 cores. The SoC still has full 32-bit support.

    This was seemingly done at the last minute to get the ball rolling on switching Android to becoming 64-bit only at some point in the future. That future might be soon for other currently supported Pixel phones as the Android 13 QPR1 Beta includes optional firmware images that are 64-bit only. Given that it is currently optional on QPR1, there is a chance that at the earliest Android 14 will be 64-bit only across all supported Pixels, with a slimmer chance that it will be 64-bit only for AOSP also.

    The three items that are of importance are AArch32, what Zygote services are set to start, and whether the build supports multilib.

    AArch32​

    Is a mode starting with ARMv8 that provides support for the 32-bit ARM ABIs: armeabi and armeabi-v7a. An ABI is what defines how software is to be built and ran for specific instruction sets.​
    AArch32 is not required to be supported with ARMv9-A architectures, which would be processors starting with ARM Cortex-X2/X3/A715. These processors support AArch64 only.​
    The ARM Cortex-A510 is currently the only ARMv9-A processor that supports AArch32. This combination of processors (X2/X3/A715 with A510) results in asymmetric 32-bit support. This is the likely reason for Google expediting these changes. It is speculated that the Cortex-A520 will not support AArch32, which would put a stop to native 32-bit support completely for future devices.​
    Tensor G2 cores are still on ARMv8-A and thus still support AArch32.​

    Zygote​

    Is a service that handles creating VMs for starting applications, and is responsible for allowing resources to be shared to reduce memory bloat from duplication. There are two Zygote services, Zygote64 and Zygote (colloquially referred to as Zygote32). Each handle a "warm" VM that is preloaded with libraries, which gets cloned for starting an application. This is done via copy-on-write, which means a copy is only made and occupies memory when attempting to modify a resource. The untouched copies all point back to the original, saving memory.​
    Without Zygote32, 32-bit applications can't be started. Without Zygote64, 64-bit applications can't be started.​
    Having multiple Zygote processes is referred to as "Zygote64_32"​

    Multilib​

    Is a scheme that allows for 32-bit and 64-bit libraries to reside on the same device. This is required to support running 32-bit applications on 64-bit devices. Android has it's own implementation that differs from most Linux distributions, which may also differ between each other.​
    Obviously, without 32-bit libraries (or inversely without 64-bit libraries), a build does not support multilib.​
    Somewhat important to note is that the 64-bit only QPR Beta images for the Pixel 4a to 6 are true 64-bit only, they do not support multilib. However, as noted here by Google, the Pixel 7 is 64-bit only but does support multilib.

    The support matrix is as follows:
    Phone + SoC, Build
    SoC AArch32 Support
    Zygote Property
    Multilib
    32-bit Support?​
    Pixel 6 with Tensor​
    Yes​
    Zygote64_32​
    Yes​
    Native
    Pixel 6 with Tensor, 64-bit Only Build​
    Yes​
    Zygote64​
    No​
    Not Possible*​
    Pixel 7 with Tensor G2​
    Yes​
    Zygote64​
    Yes​
    With Modification
    Pixel 7 with Tensor G2, 64-bit Only Build**​
    Yes​
    Zygote64​
    No​
    Not Possible*​
    Phone with AArch64-only ARMv9-A​
    No​
    Zygote64​
    No​
    Not Possible***​
    * If no multilib build is also available. It may be possible with extensive work to use Treble to bring 32-bit libraries forward, assuming Android 14+ doesn't remove AArch32 and Zygote32. Emulation could be a possibility but has not been done yet.
    ** Build does not exist yet. It may be realized with a QPR build or it may be done with Android 14 instead.
    *** Emulation could be a possibility but has not been done yet. Currently just the Pixel 6 and 7 have KVM built-in, but the Pixel 7 is the only one with it on by default.

    This means that with the right changes 32-bit support can be enabled and used if 32-bit libraries are on the device and the SoC supports AArch32.


    Modifications​

    The changes required are as follows:

    ro.zygote=zygote64_32
    ro.vendor.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
    ro.vendor.product.cpu.abilist32=armeabi-v7a,armeabi
    Genuinely that simple, property changes. Because the libraries are already in the firmware images it is just the need to instruct Android to use them.
    Zygote64_32 refers to starting Zygote64 as the primary process, then starting Zygote32 as the secondary process. With this in place 32-bit applications can be installed and ran as 32-bit libraries are now able to be loaded.

    The changes that need to be done are to either be applied to /vendor/build.prop, or done with init.rc modifications, or applied in some way before init.rc is read.

    The last point is the critical issue that has halted this: there has not been any easy way to set properties very early in the boot process outside of simply just modifying the file on the partition.
    This can't be done easily due to dynamic partitions requiring a custom super partition, and with the larger issue being AVB.
    Luckily we can patch Magisk to do these changed early enough in the boot process.


    Forewarning​

    A wipe is required

    I do not know exactly why, but when a device is first booted with only Zygote64 it can't be switched over to use Zygote64_32. For some reason the 32-bit libraries inside APEXs are not discovered and loaded by Zygote32.

    Support for custom ROMs is not guaranteed

    It may or may not work. As a matter of fact, doing this modification isn't necessary as custom ROMs could implement this change themselves.
    It is known that the modification does work on LineageOS.

    I have not tested all 32-bit applications

    I don't actually use any 32-bit apps. I have done testing with a few 32-bit apps I've gotten from APKMirror. So no, I don't know if your Instagram mod is working. I don't see any reason why it wouldn't.


    Download Links​

    All files are hosted at my download repository

    Magisk Zygote64_32:​

    Recommended:
    If you are having troubles and need to produce logs:​

    Magisk Delta 32-bit:​

    For Advanced Users:

    If you are having troubles and need to produce logs:​


    Installation Instructions​

    General Prerequisites:​

    A working platform-tools environment
    platform-tools 33.0.3 is required with the Pixel 7​
    The version you are running can be checked with adb --version and fastboot --version
    If you need assistance then read this thread by @roirraW "edor" ehT.​
    Tools like PixelFlasher can be used, just read into how to use it.​
    The factory image for the firmware version you are running or plan to run
    Part of the steps are requires the firmware for your phone, you can download it from here..​
    Copy init_boot.img out from image-xxx.zip inside the firmware archive.​

    Backup your data
    A wipe is required.​

    With my Magisk Zygote64_32 fork (Recommended)

    Magisk Zygote64_32 with the rebased patch by me.​

    Direct download link for my Magisk Zygote64_32 APK

    Installation with Wipe

    Steps:​

    Note: If you are unrooted and stock then skip to step 4​
    1. On your phone uninstall the stock Magisk app
      • Do not use the uninstall Magisk button from within the app, simply just uninstall the app itself
    2. Reboot your phone into the bootloader
    3. Flash the stock init_boot.img for your version and then boot into Android
    4. Install the Magisk Zygote64_32 app from my repository
    5. Copy over the stock init_boot.img to your phone and patch it in the Magisk app
    6. Copy the patched Magisk init_boot.img over to your computer
    7. Reboot your phone into the bootloader
    8. Flash and wipe via fastboot -w flash init_boot magisk_init_boot.img
    9. Complete the setup wizard as normal
    10. Install the Magisk Zygote64_32 app or use the Magisk stub to download the full app from your phone
      • Stub will not be available until the next reboot after finishing the setup wizard
    11. Open the Magisk app and finish setup for Magisk

    Attempt to install and run a 32-bit application. If you are unable to, then verify that you used my Magisk Zygote64_32 app to patch your init_boot.img and that you flashed it to your phone. You will have to perform the steps including the wipe over again.

    With my Magisk Delta 32-bit fork (Not Recommended For General Use, Advanced Users Only)

    Magisk Delta 32-bit with the rebased patch by me.​

    Direct download link for my Magisk Delta 32-bit APK


    Warning:

    Magisk Delta will mount the persist partition for it's early-mount feature, meaning that modules using early-mount could inadvertently fill up the partition, leading to possible corruption.​
    The steps will take you through creating a backup of the partition to restore if you ever need to.​

    Prerequisites:​

    You need to already have root with Magisk so you can backup the persist partition

    Steps:​

    Note: If you already have backed up your persist partition then you can skip steps 4 to 7.​
    1. Install my Magisk Delta 32-bit app, it may be installed alongside stock Magisk without issue as it has a different package name.
    2. Copy over the stock init_boot.img to your phone and patch it in the Magisk Delta 32-bit app.
    3. Copy it back over to your computer
    4. Enter a root shell via either method
      • adb
        • adb shell
        • su
          • You will need to approve the attempt on your phone
      • Terminal emulator
        • su
    5. Run the following command:
      • dd if=/dev/block/by-name/persist of=/sdcard/persist.img
    6. Copy persist.img over to your computer, keep it safe, keep it in multiple places
      • This is not the Google Pixel 7 persist image, this is uniquely your phone's persist image
    7. Reboot phone to bootloader
    8. Flash and wipe via fastboot -w flash init_boot magisk_init_boot.img
    9. Complete the setup wizard as normal
    10. Install my Magisk Delta 32-bit app
    11. Open the Magisk app and finish setup for Magisk
    Attempt to install and run a 32-bit application. If you are unable to, then verify that you used my Magisk Delta 32-bit app to patch your init_boot.img and that you flashed it to your phone. You will have to perform the steps including the wipe over again.


    System Upgrade Instructions (Post Mod Installation)​

    Either of my Magisk Zygote64_32 forks

    1. Extract the init_boot from image-xxx.zip of the firmware you want to upgrade to
    2. Patch it in the Magisk app that you are using
    3. Copy the patched Magisk image back over to your computer
    4. Reboot your phone into fastboot
    5. Update the bootloader and radio if necessary
    6. fastboot --skip-reboot update image-xxx.zip
      • No -w it will wipe your userdata partition
    7. Wait until it is finished
      • Don't boot the phone into Android
    8. Flash the patched Magisk init_boot.img
      • This can be done from inside fastbootd


    Magisk Upgrade Instructions​

    Magisk Zygote64_32 via app

    Update normally as you would, by installing the update in the app.

    Magisk Zygote64_32 or Magisk Delta 32-bit manually​

    1. Unhide the Magisk app if you are currently hiding it
    2. Download and install the latest APK for the 'flavor' you are using from my repository
      • It may be required that you uninstall the app if Android won't let you upgrade it
    3. Perform a direct install from the install menu
    4. Reboot

    Changing Between My Magisk Forks​

    1. Download and install the app you want to switch to from my repository
      • Uninstalling the previous Magisk app is not necessary
    2. Copy the stock init_boot.img for your system version over to your phone
    3. Patch it in the Magisk app you want to switch to
    4. Copy the patched Magisk image back over to your computer
    5. Reboot your phone into fastboot
    6. Flash the patched Magisk init_boot.img
      • If moving from Magisk Delta 32-bit to Magisk Zygote64_32 then at the same time you can flash your backed up persist fastboot flash persist persist.img
    7. Remove the other Magisk app
    8. Finish setup in the remaining Magisk app.


    Uninstallation Instructions​

    My Magisk Zygote64_32 fork

    Flash the stock init_boot.img

    My Magisk Delta 32-bit fork

    1. Flash the stock init_boot.img
    2. fastboot flash persist persist.img

    Manual method on phone if without original persist image​

    1. Uninstall all Magisk modules, they will clean up any files they put into early-mount.d
    2. Enter a root shell via either method
      • adb (heavily preferred)
        1. adb shell
        2. su
        3. You will need to approve the attempt on your phone
      • Terminal Emulator
    3. Navigate to the persist mount
      • cd $(magisk --path)/.magisk/mirror/persist/
    4. Remove the directory early-mount.d
      • rm -ir early-mount.d
        • You will be prompted for each removal and descending into directories, respond with y to approve the action
    5. Can now reboot and flash stock init_boot


    Troubleshooting​

    Stuck at boot animation or bootlooping​

    Restore stock init_boot.​
    Grab a logcat with adb to determine what the problem may be.​
    You might not have wiped your device.​

    Booted after installing new Android update but forgot to flash Magisk​

    Run through the installation instructions again, you will have to wipe your device.​

    Unable to install 32-bit apps​

    Run getprop ro.zygote; getprop ro.vendor.product.cpu.abilist; getprop ro.vendor.product.cpu.abilist32
    If the values do not match these then the modification was not applied.​
    zygote64_32
    arm64-v8a,armeabi-v7a,armeabi
    armeabi-v7a,armeabi

    32-bit apps force close​

    This only happened in my testing when I did a first boot with Zygote64 and then installed the modification to use Zygote64_32. Wipe your device or perform the wipeless installation instructions.​
    It is possible the app may just have issues, or will not work because of missing libraries.​

    Clobbered the persist partition​

    Follow the uninstall steps for Magisk Delta, easiest to use the fastboot steps.​
    If you didn't backup your persist partition, then RIP.​


    Questions​

    Will I have to wipe on every system update?​

    I'm glad to say no.​
    I've tested with my Magisk Delta 32-bit, going from October -> November, while keeping Zygisk/MagiskHide enabled along with the Magisk app being hidden.​
    I also tested December -> January with my Magisk Zygote64_32 and even swapping to my Magisk Delta 32-bit in the process without issue.​

    Can I take OTAs instead of flashing factory images?​

    I would heavily recommend against doing so, however I have done Android 14 Beta 1 to Beta 1.1 on device and it works.​

    I booted with the patch, but then accidentally flashed over init_boot without changing to a different build version, what do I do?​

    Simply just flash the patched Magisk image back over. I've tested it, 32-bit applications are still kept, and I haven't encountered any issues once I flashed the patched Magisk image back onto it.​
    If this was because of an update then follow the installation instructions, you will have to wipe your device.​

    Will my persist partition be destroyed?​

    You shouldn't have to worry about that, a backup persist image will be able to completely restore it. Just don't install modules that will attempt to install more than 32MB of data to the earlymount.d folder.​


    Thanks To​

    Thomas King for Pixel 7 32-bit Helper
    @huskydg for Magisk Delta and letting me know about the Zygisk implementation maru
    5ec1cff for maru
    @nickelnine for bringing attention to Pixel 7 32-bit Helper​
    Posters in the thread for helping me debug the issues that have come up.​
    5
    Wipeless instructions are up in the original post.

    Currently if you are on March still then you can easily perform the wipeless upgrade.
    If you are on April then you will either have to wait until the May update releases or you can try the downgrade instructions.
    If you are on QPR3 or Android 14 then somewhat tough luck, you can try finding an older QPR3/Android 14 DP firmware image to perform the downgrade steps.
    Be warned, downgrading can result in data loss, however because March and April are on the same QPR it shouldn't happen. Still, backup your data.

    You're essentially flashing the older firmware and patched Magisk for that older firmware, booting, then flashing the newer firmware and patched Magisk for the newer firmware.
    4
    Will you be working on patching the new official magisk release (v26) with 32-bit support?
    Yes, this would be awesome and very appreciated. I still have some old games that are 32-bit. Thanks!
    It's out now. It wasn't that much of an update since my fork had commits up to March 9th and had the bulk of changes, although stability with Zygisk was improved in later commits since the hooking was refined and has become less crash prone.

    Hey Namelesswonder, I was just wondering if you had implemented json support yet or if any progress has been made for easy updating and integration with pixel flasher etc. since I saw that you had mentioned it.
    The download repository now has canary and debug channels. Updating should be easier now.

    Do you still have to wipe after patching the boot image?
    I have this nasty Collect N Win app at http://nycollectnwin.com/android_install.html that doesn't work with 64 bit Pixel 7 Pro. Look forward to Namelesswonder's revised instructions on official Magisk 26001. Thx. I may still pass due to the data wipe requirement
    I forgot to update the instructions for the wipeless installing, I'll get them put up in the original post later today. If you're already on the April update then it'll be too late to do wipeless unless Google releases another April build, if not then you'll have to wait until May.

    Big Update - Magisk Zygote64_32​

    In the making for a bit, haven't had the time lately to put aside for the project, but better late than never.

    Magisk Zygote64_32 2ee5dc0f (26101)


    Name Change​

    The project has been renamed to "Magisk Zygote64_32", since the previous name of "Magisk 32-bit" was ambiguous as to whether it was for 32-bit devices or if it added 32-bit support for multilib Zygote64 devices.​

    Update Channels​

    The download repository now has the channel JSON files, so updates can now be rolled out via the app.​
    Currently it is untested whether the stub is capable of downloading the full app, and whether debug <-> canary channel swaps can be done.​
    Because the previous releases forced the update channel to custom the app on preexisting installs will not get updates until you manually change the channel to canary or debug, and you will have to manually update to 2ee5dc0f to restore updating
    Currently only the canary and debug channels are active, stable and beta just redirect to canary

    Updated to v26.1 (26101)​

    Magisk Zygote64_32 2ee5dc0f (26101) is based on 468f3efb

    Works on Android 14 Beta 1​

    I've been testing it today and so far have not had any problems that would occasionally pop up on the previous release.​
    I'll get around to making newer Magisk Delta build at some point, however I'm probably not going to be setting up an update channel for that, nor am I going to be doing much testing on it since I don't have a second device to do development with.
    4
    Dumb questions:
    - Does this support Pixel 7 Pro?
    Well the thread is in the Pixel 7 Pro forum, the post is completely full of direct references to the Pixel 7 Pro, the intro video was recorded on a Pixel 7 Pro, and the download page makes reference to that it enables 32-bit support on the Pixel 7. So I'd say yes. :)
    - Does this required to wipe after flashing patched init_boot.img with custom Magisk, I have rooted phone with default Magisk now?
    You do need to wipe the phone after flashing the custom Magisk image, just use fastboot -w as-is.
    You can try without a wipe but the majority of the time it will just bootloop. You will have to either flash back to the stock or your previous init_boot if you don't want to wipe your data or use the above fastboot command to continue with using the custom Magisk.
    - Are we able to enable Zygisk after flashing patched init_boot.img?
    If you need Zygisk, which you will need for Universal SafetyNet Fix, then yes.



    Some short news on the custom Magisk Delta fork.​

    Upstream Magisk Delta just removed maru, which isn't that great for us. :(

    For now my fork still works and will continue to have maru so we can continue to use Zygisk, however I do have a solution going forward:

    I'm just going to be creating a stock Magisk fork with the maru patches going forward.​

    This solves the issue of earlymount.d tainting the persist partition, however for the people that do use that feature I'm sorry but you are going to have to limited support. For now the custom Magisk Delta fork can still be used until it no longer works or Magisk gets a large enough update to necessitate moving. Keeping up with rebasing the maru patches onto Magisk Delta is going to get more difficult as time moves on, so it will just be easier to just use stock Magisk with the maru patches and my patch.

    This does mean that stock Magisk Delta will pose issues with Zygisk as it doesn't have maru, so I can't recommend using it going forward.

    My time frame for getting the new custom Magisk fork out will be sometime next week or the week after. Right now there isn't any pressing matters to get it out the door quickly as everything is still fine, but it's something I'm going to have to do sooner rather than later.