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

[androidoverapple1]

The 32-bit apps are back!​

screen-20221120-112309

Watch "screen-20221120-112309" on Streamable.

streamable.com

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​

Spoiler

All files are hosted at my download repository

Magisk 32-bit:​

Recommended:​

Release Build 3876edac-32bit​

​

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

Debug Build 3876edac-32bit​

​

Magisk Delta 32-bit:​

For Advanced Users:​

Release Build df91d360-delta-32bit​

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

Debug Build df91d360-delta-32bit​

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

Spoiler

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

Spoiler

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​

Spoiler

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​

Spoiler

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​

Spoiler

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​

Spoiler

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]

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.

Anyone that updated their platform tools and needs to downgrade can use these links.

Windows

https://dl.google.com/android/repository/platform-tools_r33.0.3-windows.zip

Mac

https://dl.google.com/android/repository/platform-tools_r33.0.3-darwin.zip

Linux

https://dl.google.com/android/repository/platform-tools_r33.0.3-linux.zip

 

[Bulletro]

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.

 

[t3chwizard]

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]

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.

 

[Bulletro]

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?

 

[badabing2003]

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?

Sorry to hear that,
You should definitely go hard after them and demand that it is serviced under warranty.

 

[t3chwizard]

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]

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]

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.

Spoiler: Old Release Notes

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.

 

[Bulletro]

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]

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]

Random question, but does this patch negatively impact battery life at all? I was wondering about it a few days ago

 

[t3chwizard]

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

 

[Namelesswonder]

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.

 

[Kalanyr]

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.

 

[Lughnasadh]

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.

34.0.1 is not working properly. Stick with 33.0.3 for now.

 

[huskydg]

Don't use Delta, it's deprecated, use the regular 32-bit fork

Where did i say that?

 

[t3chwizard]

Where did i say that?

I was referring to the OP's 32-bit patch for Delta which was deprecated last I checked. He recommends against it as it modifies the persist partition.

 

[Kalanyr]

34.0.1 is not working properly. Stick with 33.0.3 for now.

Thanks.