我写了款依赖检查的插件

写这款工具主要是看了优酷的几篇 向工程腐化开炮 的系列文章，觉得其中的几个点可以通过依赖检查的方式提前找到问题，所以着手找了几个点写了下，并输出 report html 方便查看。

一、检查

目前该检查工具提供了 5 项内容的检查：

• so 文件检查
• 64 位 so 未适配检查
• 更安全的导出组件检查
• 未匹配的权限检查
• uses-sdk 检查

1、so 文件检查

so 文件检查可以分析出依赖里面包含了多少个 so 文件，并且展示 so 大小，做这个可以辅助 apk 包体积优化来提前分析，哪些 so 文件过大，并且这个 so 文件属于哪个依赖，然后根据依赖找到开发责任人进行沟通，如下是检查结果展示：

2、64 位 so 未适配检查

Google Play 自 2019 年 8 月 1 日起就强制应用必须支持 64 位 架构，但国内的应用市场会相对应的滞后：

对于我们工具的检查，只需要遍历获取 32 位 so 的文件名称，然后去查下这个文件在 64 位的目录下存不存在，如果存在，说明该 so 支持，反之不支持，检测效果如下:

3、更安全的导出组件检查

在 Android 12 的适配中，如果 activity、received 和 service 有使用 intent-filter，则必须显示申明 exported 的值，否则应用将无法在搭载 Android 12 或更高版本的设备上进行安装。工具检测效果如下：

4、未匹配的权限检查

在我们的应用开发中，会对所有的权限申明进行管控，每个敏感权限的申请都需要经过团队的把关，也即意味着权限不能乱申请和乱用。所以，我们需要事先申明好一份白名单配置，在检查依赖的过程中，如果依赖中的 AndroidManifest.xml 申明的权限不在这个白名单中，则会提示该依赖使用了白名单之外的敏感权限，需要进行确认。工具检测效果如下：

5、uses-sdk 检查

manifest 中一些全局性配置，对 apk 安装和运行时行为具有重要影响，最为典型的就是 minSdkVersion和 targetSdkVersion，一旦非预期变更被带到线上，后果不堪设想。

检查工具会检查如果与白名单的配置不一致，则会输出结果：

二、使用

如果想体验 demo 的话，可以直接执行命令：

./gradlew checkDependency -Pbuild=debug

他会在 build 的 checkPlugin 目录输出 html 报告文件，用浏览器打开即可预览:

当然，你也可以直接查看 demo 输出的报告，我已经给仓库开通了 github pages，html 浏览地址为 mrwangqi.github.io/pluginDemo/

1、接入

尝试过几次在 jitpack 发布 gradle 插件，经常会报莫名的错误，所以，就不打算对外发布插件了，如果想用到自己项目的话，可以发布到 maven local，展开 task 点击 publish 发布到本地：

然后在在自己项目的 build.gradle 中配置 mavenLocal 镜像源和依赖，示例如下：

buildscript {
    repositories {
        ...
        // 配上本地 maven 源
        mavenLocal()
    }
    dependencies {
        classpath "com.android.tools.build:gradle:7.0.4"
        // 依赖 check 插件，版本号可以发布本地 maven 之前修改
        classpath "com.github.MRwangqi:checkPlugin:1.0.0"
    }
}
复制代码

然后在 app 工程的 build.gradle 中依赖插件，并且在工程下面配置白名单文件：

plugins {
    id 'com.android.application'
    // apply check 插件
    id 'checkPlugin'
}
check{
    // 配置白名单
    manifestWhiteFile="ManifestWhite.xml"
}
复制代码

ManifestWhite.xml 文件如下：

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.codelang.includebuildingdemo">
    <!--  插件会读取 uses-sdk ，如果分析出的依赖不等于 targetSdk 或是如果不等 minSDK 则会输出分析-->
    <uses-sdk android:minSdkVersion="14" android:targetSdkVersion="30" />
    <!--  插件会读取 uses-permission ，如果分析出的依赖权限不在下面则会输出分析-->
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
</manifest>
复制代码

2、使用

执行命令模板如下：

./gradlew checkDependency -Pbuild=${build variant}

要执行的 build variant 可以在 Android studio 中查看：

比如我们要检查 debug 的依赖分析，则命令如下：

./gradlew checkDependency -Pbuild=debug

当然，也可以直接使用如下命令进行检查，插件默认的 build variant 是 debug

./gradlew checkDependency

三、原理

原理很简单，就是从 configurations 中拿到继承自 implements 的 CompileClassPath configuration，然后通过 asPath 方法拿到所有依赖缓存到本地的路径，然后解析依赖拿到文件和内容进行分析，然后产出报告，具体可以查看源码。

四、总结：

基于工程腐化系列的文章其实可以做很多的检查，比如混淆章节中：

layout 中引用不存在的 class 需要进行检查，而且在 apk 编译过程中，并不会引发构建失败，但依然会生成相对应的keep规则，并且这个layout 一旦在运行时被“加载“，那么会引发 Java 类找不到的异常

其他的实现就交给大家自己发挥实现了，最后附上源码地址：

github.com/MRwangqi/pl…

向工程腐化开炮系列：

• 向工程腐化开炮 | proguard治理
• 向工程腐化开炮 | manifest治理
• 向工程腐化开炮 | Java代码治理
• 向工程腐化开炮｜资源治理