Android逆向学习02
今天遇到的问题是，把别的代码导入到现有的AS中，由于别的地方的代码中使用的SDK和build-tools版本，与现在AS中已装的SDK和build-tools版本不一致，导致一致有错误。
查看自己AS装的SDK的版本
查看build-tools的版本
在gradle中查看导入的代码使用的SDK和build-tools版本。
gradle：是一个工具，同时它也是一个编程框架。使用这个工具可以完成app的编译打包等工作；
compileSDKVersion属性值，定义程序编译选择哪个Android SDK版本进行检查和警告，
compileSdkVersion顾名思义，就是用来编译源代码所使用的 API 版本。
也就是说在写代码的时候，所引入的 android.jar 的版本。这个只是编译期间使用，并不是真实设备上运行 APK 的 API Version。
现在我们导入到AS中，发现我的电脑上只有SDK28,并且这个版本的hello函数已经没有了，变成了hello(parm,parm1)，那么就会导致编译不通过。
targetSdkVersion代表着目标版本，在编译的时候会将该版本的api编译进apk中。
compileSdkVersion代表着编译的时候，会采用该api的规范进行代码检查和警告，但是并不会编译进apk中。
为什么 compileSdkVersion 并不会影响真实运行的 API Version 呢，因为 android.jar 只是为了让我们写的代码能够成功生成 class 文件，真实运行的其实是设备上 的 ROM 包，我们可以看到 android.jar 有很多类其实就只是一个空方法，并没有具体的实现
buildToolsVersion
顾名思义，就是构建工具的版本。所谓的构建工具其实就是指我们 sdk 下面的 build-tools 目录。
这个 build-tools 里面包含了我们打包构建所需要的一些工具，比如：
- aapt: Android Asset Packaging Tool，也就是资源打包工具，将资源文件打包成 R.java 以及 .arsc资源文件
- aidl: 将 aidl 文件 编译为 java 接口类
- dx: 将 class 文件打包成 dex 文件
- apksigner: 将 打包成的 apk 文件进行签名
- zipalign: 将 签名后的 apk 文件进行 zip 对齐，加快访问速度
buildToolsVersion 就是指定这些构建工具的版本
targetSdkVersion
targetSdkVersion 是 Android 系统提供前向兼容的主要手段。随着 Android 系统的升级，某个系统的 API 或者模块的行为可能会发生改变，但是为了保证老 APK 的行为还是和以前兼容。只要 APK 的 targetSdkVersion 不变，即使这个 APK 安装在新 Android 系统上，其行为还是保持老的系统上的行为，这样就保证了系统对老应用的前向兼容性。
比如有个API在SDK1.0的时候，是一个样子
到了SDK2.0的时候， google 对这个API方法更新了，为了保持兼容性，
就可以在使用的时候，先判断配置的 targetSdkVersion，如果这个版本比较新大于等于 当前的SDK2.0，就调用新的打印方法，否则就用旧的打印方式。
遇到的另一个问题：
AS---->Build---->Make Project 会生成APK，
