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

Search This thread

androidoverapple1

New member
Feb 26, 2023
3
0

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 QPR1 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 Android 13 QPR2/3 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. There is no graphics layer yet.

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.

However two solutions have been brought forward:

The first solution is thanks to ThomasKing2014, he has created Pixel 7 32-bit helper which is a modified Magisk that changes magiskinit to modify /vendor/build.prop early in boot​

The patch he has created has been the start for this. The patch gets applied to Magisk and modifies magiskinit so that during boot Magisk will modify /vendor/build.prop with the values for the properties needed. magiskinit continues with initialization, hands off to the stock init which then reads ro.zygote to determine what Zygote rc file to load.
Then Zygote64 and Zygote32 are started.

The second solution is thanks to @huskydg for Magisk Delta which is a Magisk fork that implements many additional features​


Currently I have repositories set up with rebased patches and modified versions of Magisk and Magisk Delta using the patch.​



Forewarning​

Currently, a wipe is required to get the modification to work fully.

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.
It's a strange thing. If first boot is with Zygote64, then immediately rebooting to use Zygote64_32 will appear to work, but things are subtly broken in the background as only a few libraries don't have their 32-bit counterparts loaded. This gets exacerbated with preexisting systems, where lots of libraries have been used and their 32-bit counterparts are never discovered when switching to Zygote64_32. Ends up resulting in things like boot hangs or even the boot process aborting very early.


Magisk Delta uses persist on the Pixel 7 and allows modules to write to it

The persist partition is used by Magisk Delta to hold the early-mount.d directory for it's early-mount feature.
Modifying persist has an inherent dangerous aspect due to the fact it is unique to each device. Corruption or modification of the calibration data in the partition can result in causing functions of your device to fail.
Magisk Delta is not doing this inherently on all devices, this is actually because the Pixel 7's persist is the only partition that is not encrypted, is not checked by AVB, and is available early in the boot process. This is actually an extension of the functionality from stock Magisk, as stock Magisk is trying to do the same thing to store SELinux policy rules.


Thus I recommend using my Magisk 32-bit fork instead. However if you need Magisk Delta for it's features then it is best practice before installing Magisk Delta to make a backup of your persist. There will be steps on how to do that before installing Magisk Delta.

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.

This modification is not 'install and forget'​

Like with using custom kernels requiring you to keep on making sure verity and verification are off, this modification requires that you keep a finger on the pulse for any news or updates. You're essentially on the bleeding edge now. The hammer could drop next month and the update is true 64-bit without multilib. Performing an update and forgetting to flash the patched Magisk could require you to wipe your device.


Download Links​

All files are hosted at my download repository

Magisk 32-bit:​

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 going to be doing a flashing wipe on your device, to guarantee that you start with a reproducible blank slate.​
Copy init_boot.img out from image-xxx.zip​

Backup your data
At the moment a wipe is required, so perform two backups: with Google Backup or your favorite backup app and a manual backup of any files.​

With my Magisk 32-bit fork (Recommended)

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

Direct download link for my Magisk 32-bit APK


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 32-bit 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 --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
  10. Flash the patched Magisk init_boot.img and boot into Android.
  11. Complete the setup wizard as normal
  12. Do not open the Magisk stub (the default Android icon), install the Magisk 32-bit app from my repository.
  13. 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 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.

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 --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
  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.
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​

Either of my Magisk 32-bit 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! That flag 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 [icode[fastbootd[/icode]


Magisk Upgrade Instructions​

Either of my Magisk 32-bit forks

  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 32-bit 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 32-bit 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​

Usually there is a "carrier specific" firmware that can be downloaded each month. These are not truly "carrier specific", they can be ran just fine, download whatever is available for the monthly update you are running.​
Follow the system update instructions using the new firmware you downloaded.​
After performing the steps and booting you can then repeat the steps but this time use the firmware you originally wanted to run.​

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.​
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 32-bit 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.​

I booted with the patch, but then accidentally flashed over init_boot, 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 try the troubleshooting method above.that uses a different build of the update.​

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.​


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​
Can i get some help i keep running into this problem:
C:\Users\Gogop\Desktop\platform-tools>fastboot --skip-reboot -w update image.zip
--------------------------------------------
Bootloader Version...: cloudripper-1.0-9288096
Baseband Version.....: g5300g-220923-221028-B-9229469
Serial Number......
--------------------------------------------
extracting android-info.txt (0 MB) to RAM...
Checking 'product' OKAY [ 0.000s]
Checking 'version-bootloader' OKAY [ 0.000s]
Checking 'version-baseband' OKAY [ 0.000s]
Setting current slot to 'b' OKAY [ 0.117s]
extracting boot.img (64 MB) to disk... took 0.145s
archive does not contain 'boot.sig'
Sending 'boot_b' (65536 KB) OKAY [ 2.088s]
Writing 'boot_b' OKAY [ 0.161s]
extracting init_boot.img (8 MB) to disk... took 0.016s
archive does not contain 'init_boot.sig'
Sending 'init_boot_b' (8192 KB) OKAY [ 0.257s]
Writing 'init_boot_b' OKAY [ 0.016s]
extracting dtbo.img (16 MB) to disk... took 0.036s
archive does not contain 'dtbo.sig'
Sending 'dtbo_b' (16384 KB) OKAY [ 0.515s]
Writing 'dtbo_b' OKAY [ 0.039s]
archive does not contain 'dt.img'
extracting pvmfw.img (1 MB) to disk... took 0.002s
archive does not contain 'pvmfw.sig'
Sending 'pvmfw_b' (1024 KB) OKAY [ 0.032s]
Writing 'pvmfw_b' OKAY [ 0.005s]
archive does not contain 'recovery.img'
extracting vbmeta.img (0 MB) to disk... took 0.000s
archive does not contain 'vbmeta.sig'
Sending 'vbmeta_b' (12 KB) OKAY [ 0.000s]
Writing 'vbmeta_b' OKAY [ 0.003s]
extracting vbmeta_system.img (0 MB) to disk... took 0.000s
archive does not contain 'vbmeta_system.sig'
Sending 'vbmeta_system_b' (4 KB) OKAY [ 0.001s]
Writing 'vbmeta_system_b' OKAY [ 0.003s]
extracting vbmeta_vendor.img (0 MB) to disk... took 0.000s
archive does not contain 'vbmeta_vendor.sig'
Sending 'vbmeta_vendor_b' (4 KB) OKAY [ 0.000s]
Writing 'vbmeta_vendor_b' OKAY [ 0.004s]
extracting vendor_boot.img (64 MB) to disk... took 0.143s
archive does not contain 'vendor_boot.sig'
Sending 'vendor_boot_b' (65536 KB) OKAY [ 2.069s]
Writing 'vendor_boot_b' OKAY [ 0.162s]
extracting vendor_kernel_boot.img (64 MB) to disk... took 0.110s
archive does not contain 'vendor_kernel_boot.sig'
Sending 'vendor_kernel_boot_b' (65536 KB) OKAY [ 2.066s]
Writing 'vendor_kernel_boot_b' OKAY [ 0.155s]
extracting super_empty.img (0 MB) to disk... took 0.000s
extracting product.img (2778 MB) to disk... took 7.526s
extracting system.img (841 MB) to disk... took 2.387s
extracting system_dlkm.img (0 MB) to disk... took 0.000s
extracting system_ext.img (356 MB) to disk... took 1.017s
extracting system_other.img (24 MB) to disk... took 0.079s
extracting vendor.img (636 MB) to disk... took 1.678s
extracting vendor_dlkm.img (40 MB) to disk... took 0.081s
archive does not contain 'vendor_other.img'
Sending sparse 'super' 1/1 (4194303 KB) FAILED (Sparse file is too large or invalid)
fastboot: error: Command failed
 

Namelesswonder

Senior Member
Jan 26, 2014
432
724
Google Pixel XL
Google Pixel 7 Pro
Can i get some help i keep running into this problem:
C:\Users\Gogop\Desktop\platform-tools>fastboot --skip-reboot -w update image.zip
--------------------------------------------
Bootloader Version...: cloudripper-1.0-9288096
Baseband Version.....: g5300g-220923-221028-B-9229469
Serial Number......
--------------------------------------------
extracting android-info.txt (0 MB) to RAM...
Checking 'product' OKAY [ 0.000s]
Checking 'version-bootloader' OKAY [ 0.000s]
Checking 'version-baseband' OKAY [ 0.000s]
Setting current slot to 'b' OKAY [ 0.117s]
extracting boot.img (64 MB) to disk... took 0.145s
archive does not contain 'boot.sig'
Sending 'boot_b' (65536 KB) OKAY [ 2.088s]
Writing 'boot_b' OKAY [ 0.161s]
extracting init_boot.img (8 MB) to disk... took 0.016s
archive does not contain 'init_boot.sig'
Sending 'init_boot_b' (8192 KB) OKAY [ 0.257s]
Writing 'init_boot_b' OKAY [ 0.016s]
extracting dtbo.img (16 MB) to disk... took 0.036s
archive does not contain 'dtbo.sig'
Sending 'dtbo_b' (16384 KB) OKAY [ 0.515s]
Writing 'dtbo_b' OKAY [ 0.039s]
archive does not contain 'dt.img'
extracting pvmfw.img (1 MB) to disk... took 0.002s
archive does not contain 'pvmfw.sig'
Sending 'pvmfw_b' (1024 KB) OKAY [ 0.032s]
Writing 'pvmfw_b' OKAY [ 0.005s]
archive does not contain 'recovery.img'
extracting vbmeta.img (0 MB) to disk... took 0.000s
archive does not contain 'vbmeta.sig'
Sending 'vbmeta_b' (12 KB) OKAY [ 0.000s]
Writing 'vbmeta_b' OKAY [ 0.003s]
extracting vbmeta_system.img (0 MB) to disk... took 0.000s
archive does not contain 'vbmeta_system.sig'
Sending 'vbmeta_system_b' (4 KB) OKAY [ 0.001s]
Writing 'vbmeta_system_b' OKAY [ 0.003s]
extracting vbmeta_vendor.img (0 MB) to disk... took 0.000s
archive does not contain 'vbmeta_vendor.sig'
Sending 'vbmeta_vendor_b' (4 KB) OKAY [ 0.000s]
Writing 'vbmeta_vendor_b' OKAY [ 0.004s]
extracting vendor_boot.img (64 MB) to disk... took 0.143s
archive does not contain 'vendor_boot.sig'
Sending 'vendor_boot_b' (65536 KB) OKAY [ 2.069s]
Writing 'vendor_boot_b' OKAY [ 0.162s]
extracting vendor_kernel_boot.img (64 MB) to disk... took 0.110s
archive does not contain 'vendor_kernel_boot.sig'
Sending 'vendor_kernel_boot_b' (65536 KB) OKAY [ 2.066s]
Writing 'vendor_kernel_boot_b' OKAY [ 0.155s]
extracting super_empty.img (0 MB) to disk... took 0.000s
extracting product.img (2778 MB) to disk... took 7.526s
extracting system.img (841 MB) to disk... took 2.387s
extracting system_dlkm.img (0 MB) to disk... took 0.000s
extracting system_ext.img (356 MB) to disk... took 1.017s
extracting system_other.img (24 MB) to disk... took 0.079s
extracting vendor.img (636 MB) to disk... took 1.678s
extracting vendor_dlkm.img (40 MB) to disk... took 0.081s
archive does not contain 'vendor_other.img'
Sending sparse 'super' 1/1 (4194303 KB) FAILED (Sparse file is too large or invalid)
fastboot: error: Command failed
Download an older version of platform tools, 34.0.0 is bugged.

 
  • Like
Reactions: Homeboy76

Bulletro

Member
Jan 17, 2023
9
3
Can i get some help i keep running into this problem:
C:\Users\Gogop\Desktop\platform-tools>fastboot --skip-reboot -w update image.zip
--------------------------------------------
Bootloader Version...: cloudripper-1.0-9288096
Baseband Version.....: g5300g-220923-221028-B-9229469
Serial Number......
--------------------------------------------
extracting android-info.txt (0 MB) to RAM...
Checking 'product' OKAY [ 0.000s]
Checking 'version-bootloader' OKAY [ 0.000s]
Checking 'version-baseband' OKAY [ 0.000s]
Setting current slot to 'b' OKAY [ 0.117s]
extracting boot.img (64 MB) to disk... took 0.145s
archive does not contain 'boot.sig'
Sending 'boot_b' (65536 KB) OKAY [ 2.088s]
Writing 'boot_b' OKAY [ 0.161s]
extracting init_boot.img (8 MB) to disk... took 0.016s
archive does not contain 'init_boot.sig'
Sending 'init_boot_b' (8192 KB) OKAY [ 0.257s]
Writing 'init_boot_b' OKAY [ 0.016s]
extracting dtbo.img (16 MB) to disk... took 0.036s
archive does not contain 'dtbo.sig'
Sending 'dtbo_b' (16384 KB) OKAY [ 0.515s]
Writing 'dtbo_b' OKAY [ 0.039s]
archive does not contain 'dt.img'
extracting pvmfw.img (1 MB) to disk... took 0.002s
archive does not contain 'pvmfw.sig'
Sending 'pvmfw_b' (1024 KB) OKAY [ 0.032s]
Writing 'pvmfw_b' OKAY [ 0.005s]
archive does not contain 'recovery.img'
extracting vbmeta.img (0 MB) to disk... took 0.000s
archive does not contain 'vbmeta.sig'
Sending 'vbmeta_b' (12 KB) OKAY [ 0.000s]
Writing 'vbmeta_b' OKAY [ 0.003s]
extracting vbmeta_system.img (0 MB) to disk... took 0.000s
archive does not contain 'vbmeta_system.sig'
Sending 'vbmeta_system_b' (4 KB) OKAY [ 0.001s]
Writing 'vbmeta_system_b' OKAY [ 0.003s]
extracting vbmeta_vendor.img (0 MB) to disk... took 0.000s
archive does not contain 'vbmeta_vendor.sig'
Sending 'vbmeta_vendor_b' (4 KB) OKAY [ 0.000s]
Writing 'vbmeta_vendor_b' OKAY [ 0.004s]
extracting vendor_boot.img (64 MB) to disk... took 0.143s
archive does not contain 'vendor_boot.sig'
Sending 'vendor_boot_b' (65536 KB) OKAY [ 2.069s]
Writing 'vendor_boot_b' OKAY [ 0.162s]
extracting vendor_kernel_boot.img (64 MB) to disk... took 0.110s
archive does not contain 'vendor_kernel_boot.sig'
Sending 'vendor_kernel_boot_b' (65536 KB) OKAY [ 2.066s]
Writing 'vendor_kernel_boot_b' OKAY [ 0.155s]
extracting super_empty.img (0 MB) to disk... took 0.000s
extracting product.img (2778 MB) to disk... took 7.526s
extracting system.img (841 MB) to disk... took 2.387s
extracting system_dlkm.img (0 MB) to disk... took 0.000s
extracting system_ext.img (356 MB) to disk... took 1.017s
extracting system_other.img (24 MB) to disk... took 0.079s
extracting vendor.img (636 MB) to disk... took 1.678s
extracting vendor_dlkm.img (40 MB) to disk... took 0.081s
archive does not contain 'vendor_other.img'
Sending sparse 'super' 1/1 (4194303 KB) FAILED (Sparse file is too large or invalid)
fastboot: error: Command failed
I was using platform tools 34.0.0 and got the exact same error, it corrupted and bricked my phone (also in this bug report in the comments shows another person whos phone also got bricked). Were you able to get it working and phone working using 33? If so how since I'm partially stuck with an unbootable phone.
 
Last edited:

t3chwizard

Senior Member
Jul 20, 2013
1,648
360
Asus Transformer TF300T
LG Optimus G Pro
Just for reference I would not flash any microg Gapps replacement magisk modules (specifically avoid the one called Foundation), it made my phone unable to boot (said pixel is starting) and I had to wipe the phone and do a factory reset to get it usable again. Even flashing the factory update didn't make it work again, I think the foundation module deleted some critical system apps that make it unable to recover.
 

badabing2003

Recognized Contributor
Sep 17, 2012
2,337
3,351
I was using platform tools 34.0.0 and got the exact same error, it corrupted and bricked my phone (also in this bug report in the comments shows another person whos phone also got bricked). Were you able to get it working and phone working using 33? If so how since I'm partially stuck with an unbootable phone.
It depends on what you mean by bricked.
It means has different meaning to different people.
If you can get into bootloader mode, then it's not bricked and should be recoverable by flashing stock image with proper Android platform tools.
A true bricked is when the phone does not respond to anything, it can't get into bootloader or recovery mode.
Bootloop is not a brick.
 
  • Like
Reactions: Slim2none4u

Bulletro

Member
Jan 17, 2023
9
3
It depends on what you mean by bricked.
It means has different meaning to different people.
If you can get into bootloader mode, then it's not bricked and should be recoverable by flashing stock image with proper Android platform tools.
A true bricked is when the phone does not respond to anything, it can't get into bootloader or recovery mode.
Bootloop is not a brick.
I mean it's true bricked, as in can't get into bootloader, phone won't respond or turn on or anything. Do you know if it would fall under warranty?
 

t3chwizard

Senior Member
Jul 20, 2013
1,648
360
Asus Transformer TF300T
LG Optimus G Pro
I had a similar error to the sparse file too large at some point, but it was because I was trying to do `fastboot flash update image.zip` instead of `fastboot update image.zip`. I was also able to get into bootloader afterwards so I'm not sure what is going on with the device of the guy who claims he bricked his phone. I'm also not sure which version of platform tools I'm using but I'll probably stick to it to avoid this issue. Also make sure you have a solid connection from the computer to the phone during flashing and aren't using any wires that may have a loose connection to avoid any corruption that could happen due to disconnection while flashing.
 

Namelesswonder

Senior Member
Jan 26, 2014
432
724
Google Pixel XL
Google Pixel 7 Pro
I mean it's true bricked, as in can't get into bootloader, phone won't respond or turn on or anything. Do you know if it would fall under warranty?
If the usual method of holding down the power button for a full minute or power button + volume down for a full minute doesn't work then you're going to have to try to get it replaced.
At the moment nobody knows how to force the phone out of emergency download mode when it gets stuck in it.

It's dumb that Google is still offering r34.0.0 of platform-tools, they've even mentioned an r34.0.1 that fixes the problem but the latest download is still only r34.0.0.
 

Namelesswonder

Senior Member
Jan 26, 2014
432
724
Google Pixel XL
Google Pixel 7 Pro

Update News​

Magisk 32-bit b27e4930-32bit (25210)

An hour after I pushed out the last update the navigational issues in the app were resolved. This version is based off of fe6b658c.

There's no changes outside of the app, so updating the Magisk in the init_boot is not necessary, although because of the version change the app will give the option to.

Magisk 32-bit b8989a16-32bit (25210)

New version is up that is based off of 1a164679.
It aligns with canary 25210, however includes the latest commits that have fixed Magisk on Android 14 Developer Preview 2.

I tested it and it works on A14 DP2, however that was with a dirty flash update from DP1. I don't know if it is functional after a clean flash.

Known issue is that the patching/flashing log window can't be backed out of in the app, just close and reopen it if you need to do something else in Magisk before rebooting.
 
Last edited:

Bulletro

Member
Jan 17, 2023
9
3
If the usual method of holding down the power button for a full minute or power button + volume down for a full minute doesn't work then you're going to have to try to get it replaced.
At the moment nobody knows how to force the phone out of emergency download mode when it gets stuck in it.

It's dumb that Google is still offering r34.0.0 of platform-tools, they've even mentioned an r34.0.1 that fixes the problem but the latest download is still only r34.0.0.
Great news, I was able to get a replacement (not from google but the 3rd party I bought it from since I am in an unsupported country) after almost 6+ hours on phone arguing over it. I was able to get the GE2AE Model too so I get mmwave + sub 6ghz so everything is great, it should arrive tomorrow.

From what I know if anyone else bricks their phone through the bug of r34.0.0 it should be fully under warranty, since most 3rd party's are providing support and so is first party google. Funny part is that after I warranty'd they updated their policies to add if "You have used a computer to flash, update, or modify the software on the phone it voids the warranty"
 

freddienuxx

Senior Member
Dec 11, 2012
1,696
343
Google Pixel 6 Pro
Hey guys I'm using rice droid for 7pro and the 32bit magisk delta not working anymore did fresh install no dice. And what I usually do is delete the og Delta reboot install 32deltamagisk and works. But this time no dice. Any help would be appreciated. I need my Quickpic/gallery mod lol
 

t3chwizard

Senior Member
Jul 20, 2013
1,648
360
Asus Transformer TF300T
LG Optimus G Pro
Hey guys I'm using rice droid for 7pro and the 32bit magisk delta not working anymore did fresh install no dice. And what I usually do is delete the og Delta reboot install 32deltamagisk and works. But this time no dice. Any help would be appreciated. I need my Quickpic/gallery mod lol

Don't use Delta, it's deprecated, use the regular 32-bit fork
 
  • Like
Reactions: freddienuxx

Namelesswonder

Senior Member
Jan 26, 2014
432
724
Google Pixel XL
Google Pixel 7 Pro
Random question, but does this patch negatively impact battery life at all? I was wondering about it a few days ago
Technically yes, since there will be another process running, but in practice it should be negligible. For the most part less than 0.1% of the battery usage in a 100% to 0% run on battery could be attributed to the 32-bit zygote process. The 32-bit zygote process does nothing, and simply holds a small amount of memory to be used for starting 32-bit apps. Really it uses less battery than the 64-bit zygote process, since that has every single app on the phone that is 64-bit being forked off of it (the only non-64-bit apps on your phone are going to be 32-bit apps you sideload), and it has to keep a larger JVM on standby.

My phone has had an uptime of 8 days and the total CPU time used by the processes are 28 seconds for zygote64 and 12 seconds for zygote.

You can check how much CPU time and other things are being used by the zygote processes with this command as root.

ps -p $(pgrep -f '^zygote') -o 'PID,NAME,BIT,%CPU,TIME+,SHR,RES,%MEM'


However, CPU time is fundamentally flawed because the frequency could be anything while the task is being executed, so the following command as root will print the time the process spent at that frequency for that node of CPUs in 10-millisecond units.

for PID in $(pgrep -f '^zygote'); do echo "$(cat /proc/$PID/cmdline):"; cat /proc/$PID/time_in_state; echo; done

For me on my phone after 8 days, and using the longest time spent at a frequency that isn't a low power frequency, zygote64 has held the A55s at 1.8GHz for 4 seconds, the A78s at 2.3GHz for 2.2 seconds, and the X1s at 2.85GHz for 0.78 seconds. For the 32-bit zygote process it has held the A55s at 1.2GHz for 1.1 seconds, the A78s at 1.5GHz for 0.2 seconds, and the X1s at 2.85GHz for 0.8 seconds

That cumulative amount of time spanning over 8 days is practically nothing, when in comparison the screen will burn more energy when at high brightness in one second.

The only concern is going to be installing old 32-bit apps that could act up and consume resources in the background.

Hey guys I'm using rice droid for 7pro and the 32bit magisk delta not working anymore did fresh install no dice. And what I usually do is delete the og Delta reboot install 32deltamagisk and works. But this time no dice. Any help would be appreciated. I need my Quickpic/gallery mod lol
It could be a problem with RiceDroid and my Delta fork being somewhat outdated now, but I can't point to anything without logs.

I would recommend just running my regular Magisk fork.

At some point this weekend I might look into building a newer version of Delta, somewhat inconveniently Delta switched to doing only source archive releases.
 
  • Like
Reactions: freddienuxx

Kalanyr

Member
Oct 7, 2020
13
6
So platform-tools 34.0.1 is out, has anyone verified that it is no longer bugged ? I'm on 33.0.3 so checking if I should update.
 

Top Liked Posts

  • 2
    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.
  • 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
    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.
    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
    when it was done flashing, I stayed in fastbootd mode and flashed the patched boot_init.img file (for may).
    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?
  • 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.