7

I have an android APK that use a native library (snappydb). The native libraries takes a lot of spaces, so I want to keep only the snappydb for armeabi-v7a architectures?

I know it's not 100% safe to remove snappydb for other architectures, so my question is: how unsafe it is? (how many devices/users will I lost?)

Just for reference, the minimal sdk version that my app support is 16 (JELLY_BEAN).

huangcd
  • 2,369
  • 3
  • 18
  • 26
  • Your question isn't really clear—your wording is imprecise and unclear. Do you mean that you only want to compile and bundle `snappydb` for armeabi-v7a, and not include the same lib for other architectures? What do you mean 'remove other native libs'—what other libs? – Laogeodritt Jul 14 '15 at 06:50
  • Sorry for the inconvenience, I mean not include `snappydb` for other architectures. – huangcd Jul 14 '15 at 06:52
  • I'll leave this as a comment because I can't give a well-supported answer. To my knowledge, almost all Android devices are ARMv5 or ARMv7 (not sure how many are v5). There are a couple x86 (Intel) tablets as of last year, and I think a few MIPS devices started coming our years ago, but I don't hear about them much and to my knowledge they're not popular. I'd be surprised if non-ARM is more than 5-10% market share (but again, this is anecdotal, I don't have any data right now). Note however that some of the x86 devices are Samsung devices. – Laogeodritt Jul 14 '15 at 07:07
  • @Laogeodritt sounds reasonable, thank your for the information. So it looks like if I keep armeabi-v7a, armeabi, x86, most of the devices will be covered? – huangcd Jul 14 '15 at 09:13
  • You cannot attach a debugger to a running APK with armeabi-v7a architecture in Android Studio 2.2. It simply won't work. – IgorGanapolsky Sep 02 '16 at 19:20

2 Answers2

2

I suggest using Gradle's productFlavors to produce different APKs per ABI, as some ABI may include some assembly code optimization (SSE4, SSE5, Arm Neon etc,)

android {
    ...

    flavorDimensions "abi", "version"

    productFlavors {
        freeapp {
            flavorDimension "version"
            ...
        }

        x86 {
            flavorDimension "abi"
            ...
        }
    }
 }

Or if you're using the experimental Gradle plugin 'com.android.tools.build:gradle-experimental:0.1.0'

android.productFlavors {
        create ("arm7") {
            ndk.abiFilters += "armeabi-v7a"
        }
        create ("arm8") {
            ndk.abiFilters += "arm64-v8a"
        }
        create ("x86-32") {
            ndk.abiFilters += "x86"
        }
        // for detailed abiFilter descriptions, refer to "Supported ABIs" @
        // https://developer.android.com/ndk/guides/abis.html#sa
        // build one including all productFlavors
        create("fat")
    }
Nabil Hachicha
  • 216
  • 1
  • 4
  • Very true. The cost of jiggling with few architectures is minimal, but otherwise for some users there is no way to use the app. – Alex Cohn Jul 14 '15 at 19:40
  • @nabil-hachicha different APKs per ABI is a indeed a good solution for Google Play. However for other market that doesn't support multiple apk, it seems hard to figure out a way to distribution the my app correctly. And update is also tough problem – huangcd Jul 15 '15 at 02:53
0

You will probably not gain too much from arm-v7a optimization, and currently there is no compelling reason to include 64-bit build. But MIPS and X86 owners will thank you if you keep their devices covered.

Alex Cohn
  • 56,089
  • 9
  • 113
  • 307
  • Hi Alex, what do you mean 'not gain too much from arm-v7a optimization' ? – huangcd Jul 15 '15 at 02:48
  • Normally, native code compiled for **armeabi** will run fine on devices that support **armeabi-v7a**, but not otherwise. Number crunching algorithms may be much more efficient when compiled for **armeabi-v7a**, but this is much less relevant for database library. – Alex Cohn Jul 15 '15 at 15:06