Android推送通知点击后部分用户场景无法正常跳转拉起应用的排查求助

代码层面可直接定位的硬伤 #

• 通知渠道配置完全不符合系统规范
  代码中NotificationCompat.Builder传入的渠道id是空字符串""，后续创建NotificationChannel用的也是同一个空id。安卓8.0以上系统要求所有通知必须绑定非空、合法的通知渠道id，在小米、华为、OPPO等深度定制的国产ROM上，空渠道id的通知会被系统判定为配置异常，点击时不会触发绑定的PendingIntent逻辑，只会自动清除通知。且代码每次收到消息都重复创建同id的渠道，本身没有实际作用——系统对已存在的通知渠道不会覆盖修改配置。
• 缺少安卓12强制要求的PendingIntent权限声明
  当前构建PendingIntent仅使用了PendingIntent.FLAG_UPDATE_CURRENT，未适配安卓12的规则：当应用targetSdk版本>=31时，所有PendingIntent必须显式声明FLAG_IMMUTABLE或FLAG_MUTABLE，否则PendingIntent会创建失败，点击通知时自然无法拉起Activity，仅触发setAutoCancel(true)的逻辑清除通知。
• 通知ID设计不合理
  所有通知都使用固定的notifyID0，搭配通知组功能使用时，后发的通知会直接覆盖之前通知的PendingIntent；且系统折叠通知组时生成的总通知没有配置跳转逻辑，用户点击折叠的组通知时就会出现无跳转、仅清除通知的问题。
• 存在直接导致逻辑中断的笔误bug
  解析notificationType的代码中，三目运算符的取值分支错误引用了未定义的messageBody对象，正确逻辑应该是从remoteMessage中取值。一旦走到这个分支，代码会直接抛出空指针异常中断，后续构建通知、绑定PendingIntent的逻辑根本不会执行，最终发出的通知是系统兜底的无跳转通知。

针对「长时间未打开应用触发异常」的排查方向 #

• 不要只排查原生Doze模式的影响，重点关注国产ROM的后台管控规则：很多国产系统会对长时间未被用户主动启动的应用，触发“后台拉起拦截”机制——即使通知本身配置正常，系统也会判定后台应用拉起Activity的行为违规，直接拦截跳转请求，仅自动清除通知。这个逻辑和原生Doze的触发条件完全独立，因此手动强制切换原生Doze模式无法复现问题。
• 排查FCM消息类型的影响：如果应用在后台、被杀死的状态下，收到的是FCM服务端下发的带notification字段的通知消息，系统会直接在后台完成通知渲染，根本不会走到代码中自定义的onMessageReceived逻辑。此时系统默认绑定的跳转Intent如果因为应用启动配置问题、系统拦截规则无法正常拉起，就会出现点击无响应的问题。只有纯data字段的消息，才会触发客户端的onMessageReceived自定义逻辑。

对应的落地解决方案 #

• 修复代码层面的硬伤
  • 给通知渠道设置固定的非空id（比如统一使用"home_notification_channel"），渠道创建逻辑放到Application的初始化流程中执行，不要每次收消息时重复创建；构建通知时统一传入这个固定的渠道id，不要传空值。
  • 适配安卓12的PendingIntent规则：构建PendingIntent时，根据系统版本拼接对应flag——安卓12及以上版本，在原有FLAG_UPDATE_CURRENT的基础上追加FLAG_IMMUTABLE（不需要外部修改Intent内容时优先用这个flag，安全性更高）。
  • 修复笔误bug：将代码中错误引用的messageBody替换为实际的remoteMessage对象，避免逻辑中断。
  • 给每条通知分配唯一的notifyID，避免通知互相覆盖；如果使用通知组功能，要给折叠后的组通知单独配置ContentIntent，不要漏设跳转逻辑。
• 适配国产ROM的后台管控规则
  • 引导用户将应用加入系统的“后台启动白名单”“通知权限白名单”，避免应用长时间未启动时被系统拦截拉起请求。
  • 测试时不要仅模拟原生Doze场景，要重点模拟应用被系统杀死、长时间不主动打开的状态，在不同品牌的定制ROM上验证跳转逻辑，覆盖用户实际遇到的异常场景。
• 优化FCM消息下发逻辑
  尽量所有推送都使用纯数据消息（data only）格式，所有通知渲染、PendingIntent绑定逻辑都在客户端的onMessageReceived中完成，避免系统兜底渲染通知时因为配置不兼容导致跳转失效。

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