WARNING! 配置不当，或致使Kotlin源码泄漏！

自从去年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变化的时候，就出问题了。

修复方案

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

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

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

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

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

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

但归根结底，这个问题属于技术债务。不少时候，咱们在开发的过程当中，会为了贪图方便，本着尽量的减小影响面的想法，采起了一种折中的妥协的作法，度过了一时，但每每就埋下了祸根。

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

最后的最后

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

感谢阅读到最后，但愿本文对你有所帮助。若是以为笔者的文章对你有所帮助，还请给个喜欢/感谢/赞。若有纰漏，也请不吝赐教。欢迎你们留言一块儿讨论。:-)

后记

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

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

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

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

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

以上。

再更新

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