采用Amazon版ExoPlayer 2.12.1替代谷歌版的相关技术疑问

编译Android项目时遇到以下错误：

Could not find com.google.android.exoplayer:exoplayer-core:2.12.1
Could not find com.google.android.exoplayer:exoplayer-ui:2.12.1

数月前本地有缓存时编译正常，项目已稳定维护多年，Gradle配置如下：

buildscript {
    repositories {
        jcenter()
        maven {
            url 'https://maven.google.com/'
            name 'Google'
        }
        google()
    }
}

allprojects {
    repositories {
        jcenter()
        google()
        maven { url 'https://jitpack.io' }
    }
}

经排查问题源于jcenter仓库废弃，且无法升级到google()仓库可用的2.13.x版本。在查找替代方案时，发现Amazon的包中存在对应版本的exoplayer-core和exoplayer-ui，添加以下依赖后编译正常：

implementation 'com.amazon.android:exoplayer-core:2.12.1'
implementation 'com.amazon.android:exoplayer-ui:2.12.1'

现咨询以下问题：

• 这种处理方式是否恰当？
• 使用Amazon包有哪些潜在影响？
• 改用后项目是否需修改？
• 该包是否为未修改的原版ExoPlayer 2.12.1？

1. 处理方式是否恰当？ #

这是临时可行的应急方案，在无法升级版本、jcenter无法访问的前提下，能快速解决编译阻塞问题。但并非长期最优解，第三方分发包存在后续维护断更的风险。

2. 使用Amazon包的潜在影响 #

• 维护断更风险：该包并非ExoPlayer官方团队维护，后续若出现Android版本兼容问题、依赖冲突等情况，无法获得官方技术支持，且可能不再更新适配。
• 依赖冲突隐患：如果项目中其他依赖依赖于com.google.android.exoplayer下的包，Gradle会将Amazon版本视为完全不同的库，可能引发类重复或依赖不一致的问题。
• 信任与安全风险：虽Amazon分发渠道可靠性较高，但毕竟非官方源，存在包被篡改的理论风险（概率极低）。

3. 改用后项目是否需要修改？ #

如果项目代码仅通过包名导入使用ExoPlayer类（无硬编码全类名），则无需修改代码——该包的类结构、包名和原版ExoPlayer 2.12.1完全一致，仅groupId变更。

若代码中存在硬编码com.google.android.exoplayer相关全路径的场景（比如反射调用），则需对应修改为com.amazon.android.exoplayer，否则会触发ClassNotFound异常。

4. 该包是否为未修改的原版ExoPlayer 2.12.1？ #

是的，Amazon的这个包是原版ExoPlayer 2.12.1的未修改分发版本。Amazon在维护Fire TV生态时，会同步分发部分Android官方库的稳定版本，仅变更groupId重新发布，代码内容和官方原版完全一致，可通过对比sources.jar与官方源码验证。

内容的提问来源于stack exchange，提问作者Jack