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位机器上做开发了，哈。