使用SMS Retrieval API读OTP偶发ReceiverCallNotAllowedException崩溃排查

线上崩溃表现 #

收集到的致命异常栈如下：

Fatal Exception: android.content.ReceiverCallNotAllowedException: BroadcastReceiver components are not allowed to register to receive intents
   at android.app.ReceiverRestrictedContext.registerReceiver(ReceiverRestrictedContext.java:141)
   at android.app.ReceiverRestrictedContext.registerReceiver(ReceiverRestrictedContext.java:130)
   at xxxxx.z$d.invoke(z.java:10)
   at kotlin.concurrent.ThreadsKt$thread$thread$1.run(ThreadsKt.java:2)

业务场景说明 #

开发者在应用中集成Google官方短信检索能力实现OTP验证码自动填充功能，整体逻辑设计为：当短信检索能力触发成功回调后，动态注册广播接收器接收短信检索结果。该功能在日常本地测试场景下运行完全正常，但通过Firebase崩溃收集、Google Play控制台上报的线上数据显示，部分用户场景下会触发上述栈对应的致命异常。
当前排查遇到的难点是：崩溃日志中无明确的自身业务代码调用链，无法直接定位根因，不确定问题是否出在广播注册的逻辑本身。
当前使用的广播注册代码片段如下：

val intentFilter = IntentFilter()
intentFilter.addAction(SmsRetriever.SMS_RETRIEVED_ACTION)
activity.applicationContext.registerReceiver(this, intentFilter)
val client = SmsRetriever.getClient(activity.applicationContext)
client.startSmsRetriever()

崩溃根因分析 #

这个异常的核心触发逻辑是：执行registerReceiver时使用的Context是系统标记为不允许动态注册广播的受限Context，结合代码和崩溃栈对应，常见触发原因有两个：

• 执行广播注册时所在的线程不是应用主线程：从崩溃栈可以看到，当前调用链是从Kotlin创建的子线程触发的，系统要求所有和动态广播注册相关的操作必须在应用主线程完成，这类跨线程的调用在低版本系统、部分厂商定制ROM上会直接触发权限校验，抛出受限异常
• 持有的Context引用已经失效：如果是在延迟执行的逻辑、子线程任务中触发广播注册，之前持有的activity引用可能已经因为页面销毁、配置变更被系统替换成了ReceiverRestrictedContext代理对象——哪怕你链式调用了applicationContext，在这个代理类的实现里，返回的依然是受权限限制的Context，没法正常执行动态注册操作

可落地的解决方案 #

• 优先在应用启动阶段就持有全局唯一的Application实例，所有广播注册逻辑都直接从这个全局实例获取Context，不要从可能已经被回收的Activity引用里链式获取Application Context，从根源避免拿到受权限限制的代理Context
• 所有动态广播的注册、反注册操作全部切换到应用主线程执行，不要在子线程直接调用registerReceiver接口
• 在执行注册逻辑前增加前置状态校验：如果当前持有的Activity已经处于finishing、销毁状态，直接跳过当前的广播注册流程，不要硬执行系统API
• 可以优化整体实现逻辑：短信检索能力本身提供了专属的状态监听回调接口，完全可以不用手动注册动态广播接收检索结果，直接通过API的监听通道获取验证码内容，从根源上规避动态广播注册带来的各类兼容性问题

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