1
votes

Looks like Build.CPU_ABI is deprecated in favor of Build.SUPPORTED_ABIS. However, how do I find out the ABI that is currently being used by my app?

For example, my tablet supports x86 first and armeabi-v7a next. However, the native library that is packaged is in lib/armeabi-v7a directory. There is no lib/x86 directory in the apk. If I had no native libraries at all, the device would have used x86 ABI. However, given that the native library is present and is only armeabi-v7a type, the app has to fall back to armeabi-v7a ABI.

So how do I programatically determine which ABI my app is currently running in? Does Build.SUPPORTED_ABIS automatically reorder the list? Regards.

2
Perhaps there's a better way, but you could have a function in your native code that uses the cpufeatures library and maps that information to one of the ABI names.Michael

2 Answers

3
votes

Use this in java

System.getProperty("os.arch")

or in c++

 char arch_info[11] = "";

    // checking if CPU is of ARM family or not
    if (android_getCpuFamily() == ANDROID_CPU_FAMILY_ARM) {
        strcpy(arch_info, "ARM");

        // checking if CPU is ARM v7 or not
        uint64_t cpuFeatures = android_getCpuFeatures();
        if ((cpuFeatures & ANDROID_CPU_ARM_FEATURE_ARMv7) != 0) {
            strcat(arch_info, " v7");

            // checking if CPU is ARM v7 Neon
            if((cpuFeatures & ANDROID_CPU_ARM_FEATURE_NEON) != 0) {
                strcat(arch_info, "-neon");
            }
        }
    }
2
votes

The following is not documented, so you might not want to rely on it, but I've verified it on an arm64-v8a device running API level 25.

Despite being deprecated, Build.CPU_ABI returns exactly what you've asked for: the ABI of the running app.

On the other hand, Build.SUPPORTED_ABIS returns the device's global preference order. Neither its order nor its content is affected by the running app.