记一次sharedUserId引起的友盟推送无效问题

记一次sharedUserId引起的友盟推送无效问题

一、项目背景

应用于车载设备的广告终端App，集成于系统应用apk；有新的产品需求，初期调研时使用友盟推送sdk，在手机端以及在普通apk模式的时候，接入推送正常无误；后续直接开发对应推送业务逻辑，直到QA测试阶段，发现问题；

二、问题描述

• 作为普通apk时，AndroidManifest中配置和普通手机apk模式一样，接入友盟sdk，6.2.x，也是最新版了（2021/04/26）按照官方文档，接入正常，服务端发送推送（通知，消息，透传）都是可以的。

• 将apk改为系统rom签名的，同时配置AndroidManifest中android:sharedUserId="android.ui.system"之后，也就是将app和系统应用一个权限了。

  此时，运行apk，友盟的进程 :channel是存活的，但是后端推送消息，无法接收到，不论是友盟官方推送，还是api调用方式，都无效；

  • 同时会有warn警告日志Calling a method in the system process without a qualified user，这个是ContextImpl中警报的，可查看源码，（2280行，似乎是）并没有return拦截掉流程，也就是说，这个warn不会影响运行；
  • 上述警告的原因在于，系统uid的应用自身调用activity、service、broadcast的时候，会有这个警报；经自写demo测试，会出现这个警报问题，但不影响程序。
  • 上一条中，如果service、receiver等尚未启动过，则其他进程调用是无效的；这个是核心！

三、问题分析排查

如上定位问题概述，是由于apk配置了sharedUserId引起友盟推送sdk收不到消息，内部核心实质很难排查，友盟的sdk是混淆的，调试起来相当费时；

断断续续一周多，都在反复验证和调试定位问题，可以大致结论：

• 友盟推送sdk（项目所指版本）在sharedUserId模式下，App运行起来后，其后台的长链接是通的，推送下发的指令信息应该也是到达sdk终端的；
• sdk终端内部会解析信息，有专门的service服务，receiver来重构解码后的数据给客户端apk；
• 经反复对比排查验证试验，上一条所指解析数据的receiver或service应该是没有启动成功（在sharedUserId模式下），所以其他进程调用该服务也是无效的。（见第二条的最后一个点描述）

四、问题解决方案

1. 经对比，腾讯推送无此问题，可以替换业务方案；

2. 变相的，复杂的解决方案

   1. 创建一个非sharedUserId的sub apk，集成友盟的推送，并处理相关消息指令
   2. 主apk与sub可以用进程间通信aidl或者广播也行，交换信息，使得主apk响应到推送指令

   副作用，这样就要考虑把sub及时启动，并设法保持存活进程；（可通过主apk的启动调用，定时轮训存活状态等）；

   如此对比直接内嵌sdk来说，业务复杂，推送到达率不能保证了。

3. 类似于上一条，sub apk也是集成友盟推送sdk，主apk也集成，并且推送消息逻辑在主apk内完成；

   要求点，sub中的友盟推送的service和receiver指定的process为单独的，而非:chanel带冒号的那种子进程；

   主Apk中的友盟推送service和receiver也是指定process和sub的一样；

   这样启动sub就会启动推送process，也变相启动了主apk的推送process，就能接受不了到信息了。（原因在第二条的最后一点）

后记：如上仅为指定友盟推送sdk的版本，在特定rom上，作为系统应用apk的场景下遇到的问题；分析排查的原因总结，也未必抓住了问题的本质核心。这里作为笔记，以留后验。