General [Tutorial] [Magisk] Enabling 32-bit Support For Apps

[Bulletro]

Just wanted to say I've been on the January update and just recently moved to the A13 Beta and I've had no problems, I've been on Magisk Delta this entire time, including the update process.

If I understand this correctly, You can install Custom Magisk Delta, but then switch to Magisk or Stock and 32 bit support would remain? even through updates? because the libraries have to just be initially setup because through the update (still staying on Custom Magisk Delta) from January to Beta 32 bit remained I just regularly updated my P7P without wiping, just replacing with the patched init_boot

 

[t3chwizard]

Just wanted to say I've been on the January update and just recently moved to the A13 Beta and I've had no problems, I've been on Magisk Delta this entire time, including the update process.

That gives some hope that it might work. But I don't want to risk it on the off chance it doesn't, so I'm gonna wait for nameless to do their Magisk **pun intended** and go from there

 

[Namelesswonder]

That gives some hope that it might work. But I don't want to risk it on the off chance it doesn't, so I'm gonna wait for nameless to do their Magisk **pun intended** and go from there

I just upgraded from December to January while simulating an issue by installing the update but not flashing the patched Magisk init_boot, and I was able to recover it to get 32-bit apps functional again.

I upgraded to TQ1A.230105.002, didn't flash the patched Magisk init_boot, and let the phone boot. Flashed the patched Magisk init_boot, and 32-bit applications would crash on launch. Zygote32 was running, 32-bit apps could be installed, but 32-bit libraries were not functional and thus 32-bit apps wouldn't launch.
I downloaded TQ1A.230105.002.A1 and patched the init_boot from it, dirty flashed TQ1A.230105.002.A1 and flashed the patched Magisk init_boot before booting and now 32-bit applications are functional again.
Then I could dirty flash TQ1A.230105.002 and use the patched Magisk init_boot I originally created for TQ1A.230105.002 and 32-bit applications were still functional.

It seems that a dirty flash of a different build is capable of getting Android to setup the libraries again? This is something I'll have to test next month as I'll then be testing Android 13 QPR2 Beta 3 so I'll be wiping for best practice and in that time I should see if a wipe is not required when going from stock January -> patched February, or from stock January global -> patched January Telstra with dirty flashes.

So as for you upgrading, it seems like there might be a way to recover if the upgrade fails for whatever reason. I would still recommend backing up your data before doing so, in case things don't go as planned.

General News​

I have gotten around to making some new builds and they are available on my GitHub download repository.

Magisk 32-bit fork​

Notable is that I now have a regular Magisk fork with the patch, so Magisk Delta is no longer the only option. This development is thanks to Magisk switching to LSPlt from libxhook for Zygisk.

The sources for my Magisk 32-bit fork can be found here with the download available from my GitHub download repository.
This fork is tracking beyond Magisk Canary 25206, and is built straight from upstream. It is closer to the unreleased Magisk Canary 25207 than it is to 25206. I have been testing it and have not encountered any problems so far.
I have updated the original post with details on how to switch between my forks, this includes my previous "custom Magisk Delta".

If you are switching from Magisk Delta make sure you aren't using any modules that require early-mount, as I understand there are now a few that do.

Magisk Delta 32-bit fork updated but also deprecated​

@wowkazmir @Bulletro
Also I have updated my Magisk Delta 32-bit fork to the latest upstream, download available from my GitHub download repository.
With the introduction of my regular Magisk fork I am deprecating my Magisk Delta fork as testing both in-depth is something I don't feel like doing.
I am still providing it, and it will continue to be updated for as long as I can easily maintain it, but it will be provided as-is. I can test if it boots and starts the secondary Zygote process, but that is going to be the depth of my testing. Testing additional features for if they are functional is something I will not be providing.

The early-mount feature will still be retained, as anyone not wanting their persist partition being used by modules can run my regular Magisk fork.

Name change for the forks​

I have slightly modified the names of the forks to differentiate them a bit further. Currently the names are not very descriptive as to what changes they carry, so probably next month I'm thinking about renaming the forks to Magisk Zygote64_32 and Magisk Delta Zygote64_32, since they would then be a bit more descriptive as to what they are intended to do: enable the Zygote64_32 service.

Update Repository​

Coinciding with the name change next month will be the introduction of updates back into the apps. It'll be a good time as any to make the Magisk stub functional again and allow you to get notifications of any new releases via the app rather than from the thread.

January Update​

Yes, both forks work fine on the January update.
I'm going to presume they work fine on Android 13 QPR2 Beta 2 as it's just a feature update, I'll be doing testing on next month when QPR2 Beta 3 releases.

 

[t3chwizard]

I just upgraded from December to January while simulating an issue by installing the update but not flashing the patched Magisk init_boot, and I was able to recover it to get 32-bit apps functional again.

I upgraded to TQ1A.230105.002, didn't flash the patched Magisk init_boot, and let the phone boot. Flashed the patched Magisk init_boot, and 32-bit applications would crash on launch. Zygote32 was running, 32-bit apps could be installed, but 32-bit libraries were not functional and thus 32-bit apps wouldn't launch.
I downloaded TQ1A.230105.002.A1 and patched the init_boot from it, dirty flashed TQ1A.230105.002.A1 and flashed the patched Magisk init_boot before booting and now 32-bit applications are functional again.
Then I could dirty flash TQ1A.230105.002 and use the patched Magisk init_boot I originally created for TQ1A.230105.002 and 32-bit applications were still functional.

It seems that a dirty flash of a different build is capable of getting Android to setup the libraries again? This is something I'll have to test next month as I'll then be testing Android 13 QPR2 Beta 3 so I'll be wiping for best practice and in that time I should see if a wipe is not required when going from stock January -> patched February, or from stock January global -> patched January Telstra with dirty flashes.

So as for you upgrading, it seems like there might be a way to recover if the upgrade fails for whatever reason. I would still recommend backing up your data before doing so, in case things don't go as planned.

General News​

I have gotten around to making some new builds and they are available on my GitHub download repository.

Magisk 32-bit fork​

Notable is that I now have a regular Magisk fork with the patch, so Magisk Delta is no longer the only option. This development is thanks to Magisk switching to LSPlt from libxhook for Zygisk.

The sources for my Magisk 32-bit fork can be found here with the download available from my GitHub download repository.
This fork is tracking beyond Magisk Canary 25206, and is built straight from upstream. It is closer to the unreleased Magisk Canary 25207 than it is to 25206. I have been testing it and have not encountered any problems so far.
I have updated the original post with details on how to switch between my forks, this includes my previous "custom Magisk Delta".

If you are switching from Magisk Delta make sure you aren't using any modules that require early-mount, as I understand there are now a few that do.

Magisk Delta 32-bit fork updated but also deprecated​

@wowkazmir @Bulletro
Also I have updated my Magisk Delta 32-bit fork to the latest upstream, download available from my GitHub download repository.
With the introduction of my regular Magisk fork I am deprecating my Magisk Delta fork as testing both in-depth is something I don't feel like doing.
I am still providing it, and it will continue to be updated for as long as I can easily maintain it, but it will be provided as-is. I can test if it boots and starts the secondary Zygote process, but that is going to be the depth of my testing. Testing additional features for if they are functional is something I will not be providing.

The early-mount feature will still be retained, as anyone not wanting their persist partition being used by modules can run my regular Magisk fork.

Name change for the forks​

I have slightly modified the names of the forks to differentiate them a bit further. Currently the names are not very descriptive as to what changes they carry, so probably next month I'm thinking about renaming the forks to Magisk Zygote64_32 and Magisk Delta Zygote64_32, since they would then be a bit more descriptive as to what they are intended to do: enable the Zygote64_32 service.

Update Repository​

Coinciding with the name change next month will be the introduction of updates back into the apps. It'll be a good time as any to make the Magisk stub functional again and allow you to get notifications of any new releases via the app rather than from the thread.

January Update​

Yes, both forks work fine on the January update.
I'm going to presume they work fine on Android 13 QPR2 Beta 2 as it's just a feature update, I'll be doing testing on next month when QPR2 Beta 3 releases.

I'll admit I don't really know the difference between vanilla magisk and magisk delta, but it seems promising to be able to use something closer to vanilla magisk with the 32-bit patch. Sounds like great news, looking forward to the new updates!

 

[Iven321]

Hi, I was using the customized magisk delta recommended by you before, but there is a problem with delta, the magisk hide function is not compatible with the font module, so I plan to change to the new method you currently recommend, from the customized magisk delta Switching to the customized version magisk 32-bit, what do I need to do?

 

[t3chwizard]

Hi, I was using the customized magisk delta recommended by you before, but there is a problem with delta, the magisk hide function is not compatible with the font module, so I plan to change to the new method you currently recommend, from the customized magisk delta Switching to the customized version magisk 32-bit, what do I need to do?

I would just wait a few days or a week or however it takes for nameless to finish testing the new methods and go from there. That way you don't have to redo anything if things change at all

 

[nomfway]

Additionally if you are switching between my Magisk Delta 32-bit and Magisk you should flash your backed up persist.img

Just wondering, what is the ideal time to flash the backed up persist.img? After flashing the patched init_boot.img or at any time that is simply before rebooting the phone to set up Magisk 32bit support?

 

[t3chwizard]

Just wondering, what is the ideal time to flash the backed up persist.img? After flashing the patched init_boot.img or at any time that is simply before rebooting the phone to set up Magisk 32bit support?

On first setup I believe you're supposed to do it before you boot the phone after skipping the reboot and flashing the new update on fastboot. At least that's what I tried to update to other builds and it didn't work.

 

[Namelesswonder]

Just wondering, what is the ideal time to flash the backed up persist.img? After flashing the patched init_boot.img or at any time that is simply before rebooting the phone to set up Magisk 32bit support?

Just flash it at the same time you're flashing the Magisk 32-bit init_boot when making the switch from Magisk Delta, or at any time after.
You don't even need to do it if: your device is working fine or you never installed any modules that used the feature. Your device in this state just has a couple extra empty directories on the partition.
Flashing the backup is a catch-all as not everyone is going to know what modules may or may not have used early-mount, they might potentially leave the partition with unused files or in an unknown or possibly corrupted state. It's just to bring the partition back to a known good state after it's been modified.

On first setup I believe you're supposed to do it before you boot the phone after skipping the reboot and flashing the new update on fastboot. At least that's what I tried to update to other builds and it didn't work.

No, the only time you should be flashing a persist backup is when you're no longer using Magisk Delta or the sensors or other components on your device are not functioning.

You especially don't want to be doing it while still using stock Magisk Delta + early-mount modified vendor build.prop (the setup the requires you to manually copy files to the persist partition).

Flashing the backup is restoring the partition back to the state at when you made the backup.

Flashing the partition when using my Magisk fork: no effect on 32-bit support.
Flashing the partition when using my Magisk Delta fork: if you have any modules that use early-mount then you've just wiped any files they put there, other than that no effect on your 32-bit support.
Flashing the partition while using stock Magisk Delta and modified vendor build.prop: you've just wiped the modified vendor build.prop and now when you boot your device it won't start the secondary Zygote process, and thus no 32-bit support.

 

[t3chwizard]

Just flash it at the same time you're flashing the Magisk 32-bit init_boot when making the switch from Magisk Delta, or at any time after.
You don't even need to do it if: your device is working fine or you never installed any modules that used the feature. Your device in this state just has a couple extra empty directories on the partition.
Flashing the backup is a catch-all as not everyone is going to know what modules may or may not have used early-mount, they might potentially leave the partition with unused files or in an unknown or possibly corrupted state. It's just to bring the partition back to a known good state after it's been modified.


No, the only time you should be flashing a persist backup is when you're no longer using Magisk Delta or the sensors or other components on your device are not functioning.

You especially don't want to be doing it while still using stock Magisk Delta + early-mount modified vendor build.prop (the setup the requires you to manually copy files to the persist partition).

Flashing the backup is restoring the partition back to the state at when you made the backup.

Flashing the partition when using my Magisk fork: no effect on 32-bit support.
Flashing the partition when using my Magisk Delta fork: if you have any modules that use early-mount then you've just wiped any files they put there, other than that no effect on your 32-bit support.
Flashing the partition while using stock Magisk Delta and modified vendor build.prop: you've just wiped the modified vendor build.prop and now when you boot your device it won't start the secondary Zygote process, and thus no 32-bit support.

Sorry I read his message early in my day and didn't see it clearly. I was referring to when you're supposed to flash the patched init_boot.img file and not the backup persist. Apologies for the confusion

 

[nomfway]

Flashing the backup is a catch-all as not everyone is going to know what modules may or may not have used early-mount

Indeed, I have no idea which modules I use rely on early-mount, so just in case it is safer to flash the persist.img as well yeah?

 

[nomfway]

I flashed both persist.img and the newly patched init_boot.img by Magisk 32-bit fork, my phone has successfuly booted up!

 

[wowkazmir]

I just upgraded from December to January while simulating an issue by installing the update but not flashing the patched Magisk init_boot, and I was able to recover it to get 32-bit apps functional again.

I upgraded to TQ1A.230105.002, didn't flash the patched Magisk init_boot, and let the phone boot. Flashed the patched Magisk init_boot, and 32-bit applications would crash on launch. Zygote32 was running, 32-bit apps could be installed, but 32-bit libraries were not functional and thus 32-bit apps wouldn't launch.
I downloaded TQ1A.230105.002.A1 and patched the init_boot from it, dirty flashed TQ1A.230105.002.A1 and flashed the patched Magisk init_boot before booting and now 32-bit applications are functional again.
Then I could dirty flash TQ1A.230105.002 and use the patched Magisk init_boot I originally created for TQ1A.230105.002 and 32-bit applications were still functional.

It seems that a dirty flash of a different build is capable of getting Android to setup the libraries again? This is something I'll have to test next month as I'll then be testing Android 13 QPR2 Beta 3 so I'll be wiping for best practice and in that time I should see if a wipe is not required when going from stock January -> patched February, or from stock January global -> patched January Telstra with dirty flashes.

So as for you upgrading, it seems like there might be a way to recover if the upgrade fails for whatever reason. I would still recommend backing up your data before doing so, in case things don't go as planned.

General News​

I have gotten around to making some new builds and they are available on my GitHub download repository.

Magisk 32-bit fork​

Notable is that I now have a regular Magisk fork with the patch, so Magisk Delta is no longer the only option. This development is thanks to Magisk switching to LSPlt from libxhook for Zygisk.

The sources for my Magisk 32-bit fork can be found here with the download available from my GitHub download repository.
This fork is tracking beyond Magisk Canary 25206, and is built straight from upstream. It is closer to the unreleased Magisk Canary 25207 than it is to 25206. I have been testing it and have not encountered any problems so far.
I have updated the original post with details on how to switch between my forks, this includes my previous "custom Magisk Delta".

If you are switching from Magisk Delta make sure you aren't using any modules that require early-mount, as I understand there are now a few that do.

Magisk Delta 32-bit fork updated but also deprecated​

@wowkazmir @Bulletro
Also I have updated my Magisk Delta 32-bit fork to the latest upstream, download available from my GitHub download repository.
With the introduction of my regular Magisk fork I am deprecating my Magisk Delta fork as testing both in-depth is something I don't feel like doing.
I am still providing it, and it will continue to be updated for as long as I can easily maintain it, but it will be provided as-is. I can test if it boots and starts the secondary Zygote process, but that is going to be the depth of my testing. Testing additional features for if they are functional is something I will not be providing.

The early-mount feature will still be retained, as anyone not wanting their persist partition being used by modules can run my regular Magisk fork.

Name change for the forks​

I have slightly modified the names of the forks to differentiate them a bit further. Currently the names are not very descriptive as to what changes they carry, so probably next month I'm thinking about renaming the forks to Magisk Zygote64_32 and Magisk Delta Zygote64_32, since they would then be a bit more descriptive as to what they are intended to do: enable the Zygote64_32 service.

Update Repository​

Coinciding with the name change next month will be the introduction of updates back into the apps. It'll be a good time as any to make the Magisk stub functional again and allow you to get notifications of any new releases via the app rather than from the thread.

January Update​

Yes, both forks work fine on the January update.
I'm going to presume they work fine on Android 13 QPR2 Beta 2 as it's just a feature update, I'll be doing testing on next month when QPR2 Beta 3 releases.

I appreciate you taking the time to explain your choices and for putting the effort into maintaining the 32 bit-helper. I have restored my original persist and flashed the custom original magisk. I'd be more than happy to keep testing this as it seems 32 bit apps will still be used for some time to come.

 

[bao_gg]

Thanks OP for making 32-bit apps available on Pixel 7 again.
I plan to use OP recommended Magisk 32-bit fork. The phone has bootloader unlocked with stock ROM on Jan update. Some confusions:
1, Do I still need to do step 3 "flash the stock init_boot.img" because the phone is already on stock?
2, What does step 8 "Flash and wipe via fastboot --skip-reboot -w update image-xxx.zip" mean? Is this "image-xxx.zip" the stock factory image zip file?
3, We "install the Magisk 32-bit app from my repository" on step 4 already, do we need to do step 12 "Do not open the Magisk stub (the default Android icon), install the Magisk 32-bit app from my repository" again?
4, After step 10 "Flash the patched Magisk init_boot.img and boot into Android", has the phone been rooted?
5, Does your Magisk support LSposed module (Zygisk version) so that I can install AOSP mods later?
6, How to backup my phone's persist partition although I do not use Magisk Delta fork? Just in case.
Sorry for so many dumb questions.

 

[t3chwizard]

Thanks OP for making 32-bit apps available on Pixel 7 again.
I plan to use OP recommended Magisk 32-bit fork. The phone has bootloader unlocked with stock ROM on Jan update. Some confusions:
1, Do I still need to do step 3 "flash the stock init_boot.img" because the phone is already on stock?
2, What does step 8 "Flash and wipe via fastboot --skip-reboot -w update image-xxx.zip" mean? Is this "image-xxx.zip" the stock factory image zip file?
3, We "install the Magisk 32-bit app from my repository" on step 4 already, do we need to do step 12 "Do not open the Magisk stub (the default Android icon), install the Magisk 32-bit app from my repository" again?
4, After step 10 "Flash the patched Magisk init_boot.img and boot into Android", has the phone been rooted?
5, Does your Magisk support LSposed module (Zygisk version) so that I can install AOSP mods later?
6, How to backup my phone's persist partition although I do not use Magisk Delta fork? Just in case.
Sorry for so many dumb questions.

1. If you haven't rooted it yet with Magisk and have booted the device previously you probably are going to need to flash the stock ROM again right before you flash the patched init_boot.img (I could be mistaken though so some clarification from @Namelesswonder would be good here). You are probably going to need to root it with regular magisk, patch the init_boot.img and then wipe the device then flash the patched init_boot.img (unless someone here can upload a patched init_boot.img for you for whatever build you want to run) and you could just try flashing that (but you will probably need to wipe the device before flashing the patched init_boot.img).

2. Step 8 which talks about "image.xxx.zip" is referring to a zip file within the stock update zip you would download from Google for your device.

3. I am not sure about this step so some clarification from @Namelesswonder about the Magisk stub would be best here.

4. After you flash the patched init_boot.img the phone should be rooted, just make sure not to boot it until you have flashed the patched init_boot.img or you will have to wipe the device and start over if you boot

5. His Magisk fork is a fork of regular Magisk so it definitely supports Zygisk unless indicated otherwise, plus even his Delta fork worked with Zygisk for me so I would imagine it does (but again some clarification from @Namelesswonder would probably be best here).

6. Regardless if you use Magisk Delta fork or not the steps to backup your persist partition are identical. Just run the script to use it.

This was a lot so if anyone can correct any mistakes I made please do so

 

[t3chwizard]

@Namelesswonder If we are currently on the deprecated 32-bit Magisk Delta fork (say November build) can we just install the apk for your new 32-bit Magisk Fork, patch the init_boot.img for the January build using your new 32-bit Magisk Fork and then update (without wiping) and flash the patched January init_boot.img to update?

 

[Namelesswonder]

Thanks OP for making 32-bit apps available on Pixel 7 again.
I plan to use OP recommended Magisk 32-bit fork. The phone has bootloader unlocked with stock ROM on Jan update. Some confusions:
1, Do I still need to do step 3 "flash the stock init_boot.img" because the phone is already on stock?
2, What does step 8 "Flash and wipe via fastboot --skip-reboot -w update image-xxx.zip" mean? Is this "image-xxx.zip" the stock factory image zip file?
3, We "install the Magisk 32-bit app from my repository" on step 4 already, do we need to do step 12 "Do not open the Magisk stub (the default Android icon), install the Magisk 32-bit app from my repository" again?
4, After step 10 "Flash the patched Magisk init_boot.img and boot into Android", has the phone been rooted?
5, Does your Magisk support LSposed module (Zygisk version) so that I can install AOSP mods later?
6, How to backup my phone's persist partition although I do not use Magisk Delta fork? Just in case.
Sorry for so many dumb questions.

1. If you're stock then you can skip it.

2. image-xxx.zip would be the system image zip from inside the factory image zip.
You don't need to actually do that if you are stock, just run fastboot -w instead.

3. Yes, because you've just wiped your device, and I haven't set up my repository JSON files yet so the stub app can't automatically download the full app.

4. Yes, but the full app needs to be installed so you can authorize root access.

5. Yes, my forks have no changes to the core functionality of Magisk, so all modules are supported.

6. As root dd if=/dev/block/by-name/persist of=/sdcard/persist.img

@Namelesswonder If we are currently on the deprecated 32-bit Magisk Delta fork (say November build) can we just install the apk for your new 32-bit Magisk Fork, patch the init_boot.img for the January build using your new 32-bit Magisk Fork and then update (without wiping) and flash the patched January init_boot.img to update?

Yes, that's fine. Just make sure you are following the system upgrade instructions and using the fastboot option to not automatically reboot after flashing the system image.

 

[t3chwizard]

Yes, that's fine. Just make sure you are following the system upgrade instructions and using the fastboot option to not automatically reboot after flashing the system image.

Alright I'll give it a try today probably and see how it goes. If it goes wrong can I just flash the old update without wiping then flash the old 32-bit Magisk Delta init_boot.img after restoring the persist backup? (if I even need to restore persist since the new 32-bit Magisk Fork doesn't even touch it).

 

[Namelesswonder]

Alright I'll give it a try today probably and see how it goes. If it goes wrong can I just flash the old update without wiping then flash init_boot.img after restoring the persist backup?

In theory dirty flashing older factory images is possible, but your mileage may vary. Since you would be going from A13 QPR1 to A13 it might work, but the further apart the releases are the less chance it will work.

Just make sure if you do need to flash back to an old version that you are also flashing the bootloader and radio too, and that you have a patched init_boot for that version.

 

[t3chwizard]

In theory dirty flashing older factory images is possible, but your mileage may vary. Since you would be going from A13 QPR1 to A13 it might work, but the further apart the releases are the less chance it will work.

Just make sure if you do need to flash back to an old version that you are also flashing the bootloader and radio too, and that you have a patched init_boot for that version.

Yea forgot about the bootloader/radio etc, but it would have reminded me when flashing because it doesn't let you flash without the minimum version from what I saw last time. I'll probably try to go to from November to December first maybe if January doesn't work but I'll see how it goes.