Android ABI split migrating to App Bundle

Question

I'm planning to migrate from ABI split to App Bundle feature. Currently I'm using this code:

def versionCodesAbi = ['x86': 1, 'x86_64': 2, 'armeabi-v7a': 3, 'arm64-v8a': 4]

    splits {
        abi {
            enable true
            reset()
            include "x86", "x86_64", "armeabi-v7a", "arm64-v8a"
            // "armeabi", "mips", "mips64" last three not needed and not supported currently
            universalApk true
        }
    }

    android.applicationVariants.all { variant ->
        variant.outputs.each { output ->
            def abi = versionCodesAbi.get(output.getFilter(OutputFile.ABI))
            if (abi != null) {
                output.versionCodeOverride =
                        abi * 1000 + variant.versionCode
            }
        }
    }

which gives 4 APKs per ABI (+ universal one). The reason of using this code is to reduce app size, because of PanoWidget (uses NDK) and

renderscriptTargetApi 28
renderscriptSupportModeEnabled true

After removing splits configuration (+4001 to versionCode) and building Bundle I got .aab file, which converted to .apks (using bundletool) contains folder standalones/. Inside I have four "kinds" of APK, for x86, x86_64, armeabi-v7a and arm64-v8a ABIs. Everything looks fine for now.

Now I've noticed that apps code isn't using RenderScript at all, so I think it's redundant to use supportMode and targetApi. I've removed these two lines, tested on devices/emulator, everything works fine. So next I'm producing Bundle and now it doesn't have x86_64 APK version inside .apks archive... Should it be ommitted without RenderScript support? I'm still using VrPanoramaView and it probably have some specific NDK code for every ABI (don't see on GitHub)... Sadly I don't have x86 (32 or 64) device for testing and nom I'm afraid of releasing this Bundle... Am I missing smth, do I even need _64 version?

Pierre · Accepted Answer · 2019-02-13T10:01:33.603

2

Edit:

Removing these two options in the build.gradle will remove the native libraries that were used by RenderScript: librsjni.so and libRSSupport.so. These two libraries will be removed for all ABIs.

Since after disabling RenderScript, you still have 3 ABIs, it looks like your app depends on other libraries which make use of native code, but don't provide the libraries for the x86_64 architecture, which is why the x86_64 directory disappears. This probably means that your app never worked properly on x86_64 before since the x86_64 directory would be loaded by the platform but some native libraries would be missing.

Eventually, you should identify which library brings these native libraries and see if they can also build the 64 bit version, but in the short term, nothing will break since the x86_64 devices also support x86 (32-bit) libraries.

Previous post:

If you have any *.bc files in your APK, the 64-bit libraries are removed from the APKs because those RenderScript files are 32-bit only and cannot be loaded in a 64-bit process.

If you migrate to a more recent version of RenderScript, the *.bc files won't be generated and the 64-bit native libraries will be present again in the APKs. Or if you don't need RenderScript at all, then remove those files completely.

edited Feb 13 '19 at 10:01

answered Feb 11 '19 at 15:32

Pierre

15,865
4
36
50

where should I look for them? I've unpacked some APKs - all contains `libpanorenderer.so` file, but in those with support RenderScript I've found also `librsjni.so`, `librsjni_androidx.so` and `libRSSupport.so` inside `/lib` folder. Thats the main reason of reducing apps weight (~2 Mb), besides that there is a small difference in weight of two files in `/META-INF` and thats all. Even `*.dex` files have exactly same size. I don't see any missing/additional files besides those three above `*.so`s – snachmsm Feb 12 '19 at 07:34
zipinfo app.apk | grep ".bc" -- does that print anything? – Pierre Feb 12 '19 at 09:30
not a single one in both APKs: with `renderscriptSupport` and without. checked `standalone-x86_hdpi` apk. min sdk 15, target/compile 28 – snachmsm Feb 12 '19 at 11:36
Then the problem is probably different. How do generate the .apks file? Do you use bundletool? If so, do you use --device-spec or --connected-device flag? – Pierre Feb 12 '19 at 15:39
`java -jar bundletool-all-0.8.0.jar build-apks --bundle=abc.aab --output=abc.apks --ks=keystore --ks-pass=pass:keypass --ks-key-alias=keyalias --key-pass=pass:keypass` nothing specific for exact device. I'm getting full set of APKs inside *.apks: 4 ABI x 7 densities (`/standalone` folder) or when without renderscript 3 ABI x 7 densities. Both builded as a signed release build type, which have `minifyEnabled` and `shrinkResources` – snachmsm Feb 13 '19 at 07:29
Updated my answer. Have a look, let me know if anything is unclear. – Pierre Feb 13 '19 at 10:01
one and only NDK lib is `com.google.vr:sdk-panowidget:1.170.0`, which adds `libpanorenderer.so` (sources not available). But I've just noticed that this file is missing in any apk for 86_64, with or without renderscript... Is it possible that pretty fresh lib from such a big player doesn't support _64 ABI? Or 3.5 Mb (1.3 packed) file isn't needed on _64? Glad to hear that 64 bit version supports 32 bit, but I'm still curious why this file is missing... (is app even working on _64 device?) – snachmsm Feb 13 '19 at 10:39
Yes, they're not providing the library compiled for x86_64. – Pierre Feb 13 '19 at 22:22
Glad to hear that. I'm accepting your answer, but still curious how do you know? Any internal check or can it be deducted from github/any available source? – snachmsm Feb 13 '19 at 22:46
1

You can look in the AAR they publish in the github project (open it like a zip file), then look in the "jni" directory: https://github.com/googlevr/gvr-android-sdk/blob/master/libraries/sdk-base-1.190.0.aar – Pierre Feb 14 '19 at 09:49
Thanks a lot, now I know everything I needed. Good luck, cheers! :) – snachmsm Feb 14 '19 at 09:51

Android ABI split migrating to App Bundle

1 Answers1