Interesting finding about 32 bit support

[nullptr_t]

TL;DR: setprop persist.sys.force_32bit_install 1 to enable 32 bit support.

Tried to install a 32 bit app and got INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries. However, since eu rom has tango support, this is weird.
Then I decompiled framework.jar and services.jar and got a even more weird finding:

Over PackageAbiHelperImpl, there is a key method android.os.BUILD.isEnabled32BitTranslate which is

if (!IS_SUPPORT_MI_FAKE_32BIT) {
    return false;
}
if (VERSION.DEVICE_INITIAL_SDK_INT <= 34) {
    return true;
}
return SystemProperties.getBoolean("persist.sys.force_32bit_install", false);

And android.os.BUILD.VERSION.DEVICE_INITIAL_SDK_INT returns property ro.product.first_api_level
On my device (15 Ultra), this property is 32, apparently <= 34, which means isEnabled32BitTranslate should have always returned true.... BUT that's not the case.
Only if I set persist.sys.force_32bit_install, can I install a 32 bit app as expected. This violates the code logic, so there must be something happened.

The only reason I come up with is that system_server gets a different ro.product.first_api_level from other processes (including shell and root user). This is still VERY WEIRD.
Hoping anyone can continue my investigation.

 

[Igor Eisberg]

Nothing to investigate here, really.
"ro.product.first_api_level" for xuanyaun is 35, not 32. We set it to 32 for Play Integrity purposes, but that happens after DEVICE_INITIAL_SDK_INT field has already been set to its original value.
So the missing part to enable 32-bit translation on your device is setting "persist.sys.force_32bit_install" to "true".

 

[nullptr_t]

Nothing to investigate here, really.
"ro.product.first_api_level" for xuanyaun is 35, not 32. We set it to 32 for Play Integrity purposes, but that happens after DEVICE_INITIAL_SDK_INT field has already been set to its original value.
So the missing part to enable 32-bit translation on your device is setting "persist.sys.force_32bit_install" to "true".

Well, I think resetting the property should not happen if eu.xiaomi.module.inject is disabled?

 

[Igor Eisberg]

Well, I think resetting the property should not happen if eu.xiaomi.module.inject is disabled?

The module APK has nothing to do with this prop. It's set by init process.
In any case, I unlocked it without the persist prop check for the next builds, since the switch for it only exists via a dialog in Chinese GetApps.