请求GCM Token时抛出Java.io.IOException: RST问题求助

碰到这种GCM突然在Oreo设备上抛IOException: RST的情况，我之前也帮同行排查过几次，结合你的场景（OnePlus3 Oreo、编译SDK25、Firebase功能正常），给你几个针对性的解决思路：

1. 最根本的方案：立刻迁移到FCM #

GCM早在2019年就被Google弃用了，现在官方已经逐步停止对GCM的服务支持，Oreo及以上系统对旧GCM的兼容性越来越差。你已经集成了Firebase且运行正常，完全可以把GCM的token获取逻辑切换到FCM：

• 替换原有的InstanceID.getToken调用为FCM的协程方式获取token（更符合Kotlin的最佳实践）：

  // 在协程作用域中调用
  val token = FirebaseMessaging.getInstance().token.await()
  

• 确认你的google-services.json配置正确（既然Firebase其他功能正常，这一步应该没问题）。

2. 适配Oreo的后台运行限制 #

Oreo引入了严格的后台执行限制，哪怕你的代码不在主线程，如果是在后台服务里触发GCM token请求，系统可能会限制网络访问或者直接中断进程，导致TCP连接重置（也就是你看到的RST错误）：

• 如果token请求是在后台服务中触发的，把普通Service换成JobIntentService，它能更好地适配Oreo的后台规则；
• 尽量把token刷新逻辑放在应用前台时触发（比如用户打开APP的时机），前台应用的网络访问不会被系统限制。

3. 排查OnePlus定制ROM的特殊限制 #

OnePlus的Oreo ROM有自己的后台管理机制（比如“电池优化”“应用速冻”），很可能会阻断GCM的网络请求：

• 进入手机设置 → 电池 → 电池优化 → 找到你的应用，设置为不优化；
• 检查“后台活动”权限，确保应用允许在后台运行；
• 把应用从“应用速冻”列表中移除（如果有这个功能的话）。

4. 临时缓解：添加重试逻辑 #

如果暂时没法立刻迁移到FCM，可以给token请求加个指数退避的重试机制，因为RST错误有时候是临时的网络波动或者服务端瞬时问题：

fun requestTokenWithRetry(context: Context, maxRetries: Int = 3): String? {
    var retryCount = 0
    while (retryCount < maxRetries) {
        try {
            val instanceID = InstanceID.getInstance(context)
            return instanceID.getToken(
                context.getString(R.string.gcmSenderId),
                GoogleCloudMessaging.INSTANCE_ID_SCOPE,
                null
            )
        } catch (e: IOException) {
            retryCount++
            if (retryCount == maxRetries) throw e
            // 指数退避，避免频繁重试
            Thread.sleep(1000L * retryCount)
        }
    }
    return null
}

不过这只是临时方案，长远来看还是迁移到FCM最稳妥。

5. 升级编译SDK版本到26及以上 #

虽然你还没完成Oreo适配，但至少把编译SDK版本升级到26（Oreo对应的SDK版本），系统会认为应用对Oreo有基础适配，减少一些兼容性限制。升级后注意检查权限、后台服务等方面的兼容性问题。

总结一下，最靠谱的解决办法是迁移到FCM，毕竟GCM已经被淘汰，后续还会出现更多兼容性问题；再配合Oreo的后台适配和OnePlus的ROM设置，应该能彻底解决这个RST异常。

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