adnroid gradle4.0以后關於arm64-v8a和armeabi-v7a的兼容性處理問題

android項目開發過程使用到so庫的時候，一般我們都是使用armeabi-v7a版本對應32位系統，arm64-v8a版本對應64位系統；
方法一：使用兩份so好處就是兼顧到了64位的高性能，但是需要兩份so庫就增加apk大小；
方法二：我們只想使用一份so庫去同時兼容32位和64位。下面就是就有兩種方式：
　　　　方式1:只使用armeabi-v7a版本so庫，只有32位機器上可以使用，64位機器上也可以使用，但是就沒有最大化發揮出64位機器的性能了。
　　　　方式2:只使用arm64-v8a版本so庫，64位機器可以使用並且最大化發揮出了64位機器的性能，但是32位機器不能使用直接崩潰。

方法一的配置：

externalNativeBuild {
    cmake {
        abiFilters "armeabi-v7a" ,"arm64-v8a"
    }
}

方法二的配置：

externalNativeBuild {
    cmake {
        abiFilters "armeabi-v7a" //只使用64位
    }
}

externalNativeBuild {
    cmake {
        abiFilters "arm64-v8a" //只使用64位
    }
}

但是，這里有個關於gradle的重大變化：
　　使用方法二的方式1時，也就是只使用armeabi-v7a版本so庫去兼容32位和64位的時候，配置的abiFilters "armeabi-v7a" 在gradle3.x和4.x時有變化。
　　
　　在classpath "com.android.tools.build:gradle:3.1.2" 插入64位機器編譯出來的apk一切正常，含有armeabi-v7a的so庫，並且32和64位機器都可以正常運行。
　　
　　在classpath "com.android.tools.build:gradle:4.0.1" 插入64位機器版本時編譯出來的apk竟然是不含有armeabi-v7a的so庫的，仔細看log也說明了，運行當然崩潰，
　　但是我插入32位機器竟然正常，我擦gradle4.x還會根據插入的機器自動識別位數，所以別再被坑了。還好最后打包出來的是含有armeabi-v7a的so庫的，
　　所以在gradle4.x以上只想使用armeabi-v7a就只能在32位機器上做開發了，哈。