Android Gradle Plug 4.1.0 升级后gradle获取manifest位置失败问题解决

问题背景

项目编译过程中，使用了类似Android Gradle Plugin的gradle插件进行编译，在最终打包apk时，会动态修改manifest文件。

近期发现线上用户有反应升级到以下开发环境后，打包apk后manifest文件中没有应有的任何配置。

Android Gradle Plugin:4.1.0
Gradle:6.5
Android Studio:4.1

确认调查方向

首先要确认清楚到底是上述3个哪个的升级导致的问题。

在本地进行环境升级过程验证了以下结论：

Android Gradle Plugin:4.1.0 强制要求 Android Studio:4.1 + Gradle:6.5。然而 以下环境下打包过程是正常的：

Android Gradle Plugin:4.0.2
Gradle:6.5
Android Studio:4.1

Android Gradle Plugin:4.0.2 是 4.1 的前一个版本，至此可以确认是 Android Gradle Plugin:4.1.0 的升级导致的不兼容问题。

明确了调查的方向，接下来就可以有的放矢了。

调查分析

我们的gradle插件，是通过以下代码获取到manifest文件后做处理的：

new File(output.processManifestProvider.get().manifestOutputDirectory.get().getAsFile(), "AndroidManifest.xml")

其实并非如此简单，只是这一句是最关键的。在gradle插件中增加了一些关键打印语句后，编译过程中得到了以下错误提示：

Could not get unknown property 'manifestOutputDirectory' for task ':app:processDebugManifest' of type com.android.build.gradle.tasks.ProcessMultiApkApplicationManifest

百度了一下，没有任何相关记录，毕竟距离 Android Gradle Plugin:4.1.0 正式发布才过去2个月，只好自给自足。

很明显是读取manifest文件位置的属性失效了，那最直接的方法就是看源码。找到 Android Gradle Plugin:4.1.0 的jar包看看就行。

又是百度一下，很可惜，没有下载地址。

上JCenter找，结果JCenter仓库只更新到2.x版本。

也对，好像是从 Android Studio 3.0 开始，google就将 Android Gradle Plugin 转移至 google() 仓库了，那只能去 google() 仓库找了，一时半会也不知道具体地址，以前的编译过程中也没留意看studio的编译日志输出，当然如果是一个全新工程环境，编译一下，肯定能找到仓库地址的，不过我懒得搞。

先到AS的缓存路径下碰碰运气吧，不过碰运气也得先有个方向，别忘了Android Gradle Plugin的classpath配置：

classpath 'com.android.tools.build:gradle:4.1.0'

果不其然，在以下路径找到了：

/Users/jackie/.gradle/caches/modules-2/files-2.1/com.android.tools.build/gradle

加载过的各种版本都有，直接拿到 4.1.0 的jar包看源码，在 ProcessMultiApkApplicationManifest.class 中找到了以下代码：

File mergedManifestOutputFile = new File(((Directory)getMultiApkManifestOutputDirectory().get()).getAsFile(), 
  FileUtils.join(new String[] { dirName, 
    "AndroidManifest.xml" }));

同时还有一个抽象方法：

public abstract DirectoryProperty getMultiApkManifestOutputDirectory();

看来属性已经变成了 multiApkManifestOutputDirectory。

如果不确定，我们再看看 4.0.2 的源码，在 ProcessApplicationManifest.class 中找到了以下代码：

很明显，在 4.0.2 版本时，获取manifest文件路径的属性确实是 manifestOutputDirectory ，而task本质上是一个 ProcessApplicationManifest 实例，但从 4.1.0 版本开始， task变为 ProcessMultiApkApplicationManifest 的实例，属性变为 multiApkMnifestOutputDirectory 了。

好了，剩下的就是做一下版本兼容了，大功告成。

总结

大部分基于gradle的编译脚本，其工作原理都一样，就是在编写自定义的task、在某个预设的task之前或之后做自定义的特殊处理等等，更高级一点的gradle插件也不例外。

而 Android Gradle Plugin 同样也只是一个Google官方开发的gradle插件，每次升级版本都会伴随着一些“task名变更”、“task处理内容变更”、“task执行顺序变更”等等的更新，这些更新很可能就会影响到我们这些基于其“预置task”做特殊处理的gradle插件，所以大部分版本兼容问题都应该从这个方向出发调查。

另外，有时候Gradle的升级也会带来一些兼容问题。