自从去年Google扶正了Kotlin，使之成为了Android官方的推荐开发语言，Kotlin便迎来了春天。很多团队/产品也纷纷加入了Kotlin的支持，大厂的应用也很多，社区对Kotlin也是赞不绝口。正在看此文的同学，也相信要么用上Kotlin，要么准备使用Kotlin。

这里，笔者要给大家提个醒：旧项目引入Kotlin，如配置不当，会导致源码泄露！。这意味着我们所做的混淆、加固之类的防护操作都白费了！这可是相当严重的安全问题！

如图。这是笔者在网上闲逛的时候，偶然发现的某应用包内竟然包含了Kotlin的源文件！

妥妥的如假包换的源文件，代码、注释都是全套的。

原因分析

当笔者发现这个情况的时候，内心暗喜：难道笔者不小心挖到了一个Kotlin的大新闻，只要使用了Kotlin，就会被开源？

笔者尝试在本地复现这个场景，但遗憾的是，不管是新版本的Kotlin Plugin还是旧版本的Kotlin Plugin，打出来的包都不包含.kt文件。随后笔者又尝试去应用宝抓取Top50的应用，发现使用了Kotlin的应用虽然多，但也没出现图上的应用一般的代码泄露情况。无法复现，还怎么定位问题的原因？此时陷入了僵局。

后来，笔者查看自家的应用时，发现自家应用引入了Kotlin后，也出现了这样的问题。那这就不是小事了。

排查和定位过程按下不表，直观的结果就是，打出来的APK包里，混入了源代码目录下的.kt源文件。

我们知道，打包过程中，有一个步骤叫做Jar包资源合并，这个步骤会把Jar包内资源合并到一起，打包到apk中。既然APK里包含的.kt文件，那极有可能是合并资源的任务出了问题。

可惜，比对了有问题的项目和正常的项目的build.gradle之后，无奈的发现，即便是同样的Gradle、Kotlin Plugin、build tools版本，同样的配置，依然无法在正常的项目下复现这个问题。

也就说，gradle的Jar包资源合并任务并不是导致问题的元凶。也是，Gradle如果有问题，社区也早就发现了。

但问题还是得解决，既然是资源被合并打包了，那就找方法做指定资源的排除呗。

这部分的工作是由java plugin干的，那就到文档: The Java Plugin里找答案。

首先看到这个任务：

从描述可知，这个任务就是我们要找的，拷贝资源到jar包的资源目录。

再往下看，项目的默认目录结构：

资源目录是放置在src/main/resources，或对应的src/<代码集>/resources目录内。

如果要自定义资源目录的配置，看这个：

也就是说，这个配置指定了代码集的资源目录的位置。它会排除掉目录内的.java文件，其他的插件，也可能从这里移除掉额外的文件类型。

看到这里，大家也差不多明白了吧？

讲道理，默认生成的项目的目录结构中，资源目录和代码目录是区分开的。既然APK里包含了.kt源代码，那必然是资源目录和代码目录是同一个的情况。

由于java plugin默认会移除资源目录内的.java文件，因此，在以往的打包中，源代码能够被安全的移除掉，不至于导致泄露。

而现在，我们引入Kotlin的时候，会依旧保持原有的代码目录结构，此时代码目录中就混入的.kt文件，由于不属于资源剔除的范围，自然就被当做资源文件打包进APK里了。

在出现了源码泄露的应用里，我还发现了.aidl文件，也就是IPC通讯时定义的接口文件。这类文件的泄露也是同样的原因造成的。

至此，这个源码泄露案，也就告破了。

当然，说告破还有点早，毕竟上面给出的是推测，就算是真理，也是需要检验的。

回到自家工程的build.gradle里一查：

android {
    sourceSets {
        main {
            manifest.srcFile 'AndroidManifest.xml'
            java.srcDirs = ['src']
            resources.srcDirs = ['src']
        }
    }
}

果不其然，资源文件所在的目录和源码所在的目录配置成了同一个。

至于出现这个问题原因，笔者反思了一下。这个项目属于比较早期的项目，代码目录结构遵循的是Eclipse时代的规范，后面拥抱变化转Android Studio时，Gradle默认的那套项目布局规范和Eclipse相差较大，为了避免对项目造成大的改动，所以采取了自定义目录配置的做法，用较小的代价，完成了迁移。时过境迁，到了拥抱Kotlin变化的时候，就出问题了。

修复方案

明了问题的所在，定解决方案自然也就方便了：

方案一：直接移除resources.srcDirs = ['src']配置。
方案二：为资源目录增加新的提出类型.kt。
方案三：将资源目录和代码目录区分开来，不再混杂在一起。

这些方案里，方案一有点简单粗暴。对Android项目来说，影响倒还好，因为很多资源都是放在assets目录里，工程内很少会放这种资源文件了。

方案二适用于那些资源文件里除了.kt文件之外，还有别的资源文件的情况，传统java开发可能会有这种场景。

方案三是最稳妥，最合乎规范的推荐做法。将资源和代码分开，使得相关文件在物理上保持了隔离，对整个项目来说，整体结构更加清晰。

对笔者这种情况，更好的方式是做一次项目结构的改造，使之符合Gradle的规范。

但归根结底，这个问题属于技术债务。很多时候，我们在开发的过程中，会为了贪图方便，本着尽可能的减少影响面的想法，采取了一种折中的妥协的做法，度过了一时，但往往就埋下了祸根。

短期内没时间，确实可以这么做，但从长期来看，还是要把债务还上的。只是时间的问题罢了。

最后的最后

最后的最后，建议大家自查一下，避免出现和笔者统一的情况。尤其是那些从Eclipse时代转过来的Android项目！

感谢阅读到最后，希望本文对你有所帮助。如果觉得笔者的文章对你有所帮助，还请给个喜欢/感谢/赞。如有纰漏，也请不吝赐教。欢迎大家留言一起讨论。:-)

后记

本文发出后，有朋友留言，指本文有标题党的嫌疑。恕笔者无法苟同。诚然，如有些朋友所言，不就是自己一个配置错了，关Kotlin什么事情，Kotlin乃无辜躺枪。

但笔者认为，这固然不是编程语言的锅，但却是Kotlin工具链上的Kotlin Plugin没兼顾到这种场景导致的安全漏洞。与之相对的Java Plugin对这种场景就处理得周到得多。

虽然最后笔者将问题的原因归根于项目配置导致的问题，但笔者仍然认为，这种情况的发生，Kotlin Plugin也有一定的责任。完善的工具链，能为开发和使用带来极大的便利，Kotlin Plugin也不例外。笔者在Kotlin接入的配置教程里，看到很多人在宣扬Kotlin的引入很方便，方便的背后，却可能会不小心带来这么大的安全隐患，笔者认为，是很有必要提醒使用了Kotlin的各位的。

另外，安全问题的产生，往往都是小细节上的失误导致的，而失误，往往来自于人。爱因斯坦这样说道：“只有两种事物是无穷尽的——宇宙和人类的愚蠢”。

能遇上这个问题的项目，基本都是从Eclipse时代过来的，这样的项目，其具有的价值，料想是不言而喻的。笔者看到，有的同学认为，源码泄露就泄露，爱谁看谁看。个人认为，这是对项目的一种不负责任。

以上。

再更新

之前的标题《使用Kotlin或导致源码泄漏！》，评论指出有蹭热度的嫌疑，参考了承香墨影的推送，改成《配置不当，或导致Kotlin源码泄漏！》，更直观和开门见山。:-)