一个不识卡问题分析。

终端从recovery模式开机，carrierconfig 的app数据获取失败。导致qcril 无法获取CarrierConfigLoader。

请recovery相关同事看看。

 

具体分析如下:

从ril 看 ril一直没有初始化成功。导致phone anr，然后重启phone 重新初始化ril。循环往复。

疑点多的一行log如下:

04-08 15:27:47.437 16578 16618 D QtiRadioIndication: [0]Constructor: 
04-08 15:27:47.638 14958 14993 W CarrierConfigManager: Error getting config for subId -1 ICarrierConfigLoader is null

RIL 无法获取ICarrierConfigLoader。

 

从system log看,carrierconfig 的app数据recovery失败。（还有很多其他应用的数据也是recovery失败的。）

04-08 15:27:20.535 14366 14448 D PackageManager: Recovery failed!
04-08 15:27:20.535 14366 14448 E PackageManager: Failed to create app data for com.android.carrierconfig.overlay.common, but trying to recover: com.android.server.pm.Installer$InstallerException: android.os.DeadObjectException
04-08 15:27:20.536 14366 14448 W PackageManager: com.android.server.pm.Installer$InstallerException: android.os.DeadObjectException
04-08 15:27:20.536 14366 14448 D PackageManager: Recovery failed!

 

//

更新:
现在还没有解决。
不是recovery模式开机。log中recovery模块确实有问题。
如果关注不识卡这个问题本身。就是因为phone重启。

phone重启因为连ril的Radio服务超时。
at android.os.HwBinder.getService(Native method) 
at android.hardware.radio.V1_0.IRadio.getService(IRadio.java:40) 
at com.android.internal.telephony.RIL.getRadioProxy(RIL.java:369) 

看起来是radio slot2 服务确实没有起来。
04-08 15:27:24.391 14942 14942 I ServiceManagement: getService: Trying again for android.hardware.radio@1.0::IRadio/slot2... 
04-08 15:27:25.392 14942 14942 I ServiceManagement: getService: Trying again for android.hardware.radio@1.0::IRadio/slot2... 
04-08 15:27:26.393 14942 14942 I ServiceManagement: getService: Trying again for android.hardware.radio@1.0::IRadio/slot2... 
04-08 15:27:27.396 14942 14942 I ServiceManagement: getService: Trying again for android.hardware.radio@1.0::IRadio/slot2...
 
为何radio slot2没有起来。需要将qcril的log打印到radio log中分析。否则这部分的开机过程log在modem log中看不到。

phone crash，和rild crash本身都是会被自动拉起的。
但是ril中的radio服务有异常却没有重新被拉起的流程。这个可以优化，增加健壮性。

从modem log来看，插拔卡qcril 的log打印正常。看起来qcril的问题就是在于radio slot2服务为何挂了，或者一开始就没有成功建立。

但是这不一定是qcril本身有问题。因为每次出问题时，tombstones log都是满满的10个。只能抓10个。每次都抓满了。里面是各种内存相关的error fatal。所以根源可能还是系统的稳定性。当时的内存管理出问题了。

要排除这部分问题就需要版本中把ASAN 的debug消息打开。

总之解决起来比较棘手。需要专门的版本来进行压力测试复现分析。