版权声明：本文为 ls9512 原创文章，转载请注明出处！ https://blog.csdn.net/ls9512/article/details/81084356
问题描述
最近公司项目主要面向海外发布，有统计分析的需求，TalkingData 的统计功能稍显薄弱，决定接入 Firebase，应对全球市场。
于是按照 Firebase 官方文档，接入 Unity 版本的的 Firebase SDK，接入过程中也有一些小问题，比如与已经介入的 Admob 和其他中介广告联盟SDK之间的冲突，但这些不是本文的重点，再次不赘述。一番折腾后 Firebase 后台成功接收到了统计数据，接入完成。
第一个项目就这样上线了，然后开始了第二个项目，SDK 的需求是一样的，于是我从项目1中，复制了所有SDK相关文件，放入项目2中，将所有SDK的参数重新配置了一遍，打出APK包，看似一切顺利。
但是将项目2安装到装有项目1的测试机上，安装失败了。
问题分析
APK 安装冲突可能的原因
- 1.包名冲突
AndroidManifest.xml文件中的package属性，以及build.gradle文件中的applicationId属性。 - 2.provider android:authorities 属性冲突
一些SDK的推送服务会需要配置provider属性，android:authorities的值一般为应用包名+.+SDK provider名组成。
冲突排查过程
- 1.检查报名配置
根据上面两个可能冲突的原因，首先将Unity工程导出成Android Gradle工程，确认包名配置，配置是正确的。 - 2.检查 Firebase 配置
Firebase 接入所需要的google-services.json和google-services.xml文件，只有 xml 会作为资源打包，两个项目中的配置都是各自不同的参数，而且资源并不会导致 apk 安装冲突。 - 3.检查 provider android:authorities 配置
Firebase SDK 的文件比较多，但是细看一遍，和 Android 冲突有关的文件并不多。在所有文件中，只有一个AndroidManifest.xml，其中也只配置了 Firebase 的插件包名，并没有找到 provider 相关的值。
那么冲突到底在哪呢，难道不是这两个原因中的某一个引起的，还有其他神秘的原因？
于是我将项目2中的 Firebase SDK 文件进行以下操作：
删除文件1，打包，安装测试，恢复文件1。
删除文件2，打包，安装测试，恢复文件2。
……
删除文件n，打包，安装测试，恢复文件n。
无奈之下通过这种穷举遍历的方法，定位具体的冲突文件。
最终确定冲突文件在这些文件中：
这些文件是通过GoogleMobileAdsPlugin插件，根据Editor/xxxxDependencies.xml文件的配置自动导入到项目中的。看上去都是Google和Firebase的基础库。
这些自动导入的基础库，怎么看都不像是会引起冲突的东西，但删了这些打出的APK就是可以安装的，所以冲突肯定在这些文件中了。于是重复上述步骤，定位到具体的冲突文件com.google.firebase.firebase-common-16.0.0.aar。
解压aar文件，打开其中的AndroidManifest.xml文件，终于看到了期望的内容：
由于为了省事，所有SDK文件都是从项目1中复制过来的，此处的包名依然是项目1的包名，显然这个文件是自动导入的过程中，自动针对项目做了修改重打包，修改这个文件，并覆盖到原aar中，打包，测试，问题解决。
总结
因为偷懒复制了已经接好SDK的工程中的SDK文件到新工程中，导致新工程中的com.google.firebase.firebase-common-16.0.0.aar依旧配了旧工程的包名，最终导致冲突无法安装，可以说是一场闹剧。
Firebase自动导入的库文件，并非原封不动的标准库，在导入过程中正针对项目自动做了参数配置和重打包处理，如果对新项目是按照标准流程进行重新接入，就不会出现这个问题了。
但由于接入的SDK众多，为了方便，还是复制接好的到新工程中更为方便，只是以后都需要记得修改这个文件中的provider android:authorities的属性。