[Factory][MP]Tiffnay包装线出现一台*#06#后显示两个imei 号一样:
下面需要理一理IMEI和MEID的获取流程：
8.0上开始使用HIDL来和RILD进行通讯，
GsmCdmaPhone->
RIL->getDeviceIdentity(obtainMessage(EVENT_GET_DEVICE_IDENTITY_DONE))
->radioProxy.getDeviceIdentity(rr.mSerial)
我们发现通过HIDL的时候传了个mSerial变量，该变量唯一标示一个Request, 变且作为Key值和Requset对应起来，
存储在SparseArray<RILRequest> mRequestList中，
每下发一个Request就会添加到mRequestList中,直到该Request处理完毕，才会从对列里面移除。
我们可以通过mRequestList移除Request的地方追溯获取到的信息是怎么上报上来的
RIL.java:
findAndRemoveRequestFromList
<-
processResponse
<-
分支一：
QtiRIL extends RIL:
qtiProcessResponse
<--
QtiRadioResponse extends IQtiRadioResponse.Stub
<--
responseString
(获取Message将上报的信息发给Phone里面的Handler进行处理,然后调用RIL.qtiProcessResponseDone打印出上面
RILJ : [3792]< RIL_REQUEST_DEVICE_IDENTITY...的信息 #)
<--
getAtrResponse
这条线我们发现QtiRadioResponse是个HIDL Service，最终调用的getAtrResponse肯定是别人获取该Service后主动请求的。
分支二：
OemHookResponse extends IOemHookResponse.Stub：
sendRequestRawResponse
(获取Message将上报的信息发给Phone里面的Handler进行处理，然后调用RIL.qtiProcessResponseDone打印出上面
RILJ : [3792]< RIL_REQUEST_DEVICE_IDENTITY...的信息 #)
这条线我们发现OemHookResponse也是个HIDL Service，最终调用的sendRequestRawResponse肯定是别人获取该Service后主动请求的。
Log分析：
一
05-30 15:36:22.741 3172 3172 D GsmCdmaPhone: [GsmCdmaPhone] PhoneId is 0 respId[0] is 868214030017824 respId[1] is 00respId[2] is 803E52B3respId[3] is A1000060A0029EmImei is 868214030017824mImeiSv is 00mEsn is 803E52B3mMeid is A1000060A0029E
二
05-30 16:55:33.473 10019 10019 D GsmCdmaPhone: [GsmCdmaPhone] PhoneId is 1 respId[0] is 868214030017832 respId[1] is 00respId[2] is 00000000respId[3] is 00000000000000mImei is 868214030017832mImeiSv is 00mEsn is 00000000mMeid is 00000000000000
05-30 16:55:49.687 10593 10593 D GsmCdmaPhone: [GsmCdmaPhone] PhoneId is 1 respId[0] is 868214030017832 respId[1] is 00respId[2] is 00000000respId[3] is 00000000000000mImei is 868214030017832mImeiSv is 00mEsn is 00000000mMeid is 00000000000000
三
05-30 16:56:54.956 11569 11569 D GsmCdmaPhone: [GsmCdmaPhone] PhoneId is 0 respId[0] is 868214030017824 respId[1] is 00respId[2] is 803E52B3respId[3] is A1000060A0029EmImei is 868214030017824mImeiSv is 00mEsn is 803E52B3mMeid is A1000060A0029E
05-30 16:56:55.703 11569 11569 D GsmCdmaPhone: [GsmCdmaPhone] PhoneId is 1 respId[0] is 868214030017832 respId[1] is 00respId[2] is 00000000respId[3] is 00000000000000mImei is 868214030017832mImeiSv is 00mEsn is 00000000mMeid is 00000000000000
四
05-30 16:56:55.711 11569 11569 D GsmCdmaPhone: [GsmCdmaPhone] PhoneId is 1 respId[0] is 868214030017824 respId[1] is 00respId[2] is 803E52B3respId[3] is A1000060A0029EmImei is 868214030017824mImeiSv is 00mEsn is 803E52B3mMeid is A1000060A0029E
从上面log可以看到，二中Phone 1的IMEI即respId[0]本来是868214030017832， 到了四中却变成Phone 0里面的值，
所以明显是上报的信息回调到错误的Phone里面了，原因要不就是Modem上报问题要不就是下发的Request紊乱
该问题研究了两天最终找到原因，
之前出现MEID为空的情况，当两个Phone的MEID都无效的时候会去重新请求MEID信息（IMEI和MEID是一起上报的），在构建下发Request的时候循环的两个Phone是用的同一个Phone里面构建的Message，导致两个Phone的上报信息都跑到了其中一个里面去了。
如下：GsmCdmaPhone.java:
private void reRequestMeid() {
if(PhoneFactory.getPhones() == null) {
Log.e(LOG_TAG, "Impossible, phone is still not inited!");
return;
}
for(Phone phone : PhoneFactory.getPhones()) {
phone.mCi.getDeviceIdentity(obtainMessage(EVENT_GET_DEVICE_IDENTITY_DONE));
//这个地方下发的Message是同一个Phone里的Handler里面构建的
}
}
网友评论