MTK 通话记录分析

 

前阵子发现了一个通话记录相关的奇怪问题：

当通话记录超过20个，且穿插拨打电话本中的号码时，通话记录会出问题，表现为在通话记录中的名字与其号码不相符合，
结果是 在通话记录中拨号时拨的是其它号码，与名字不符。
经过反复试验，发现规律为：当通话记录中的记录超过10个时，
拨打第11个号码，会自动将原来第1个记录的号码修改为第11个的号码，
拨打第12个号码，会自动将原来第2个记录的号码修改为第12个的号码，
拨打第13个号码，会自动将原来第3个记录的号码修改为第13个的号码，
依此类推。

下面贴一下通话记录相关的代码分析：

进入EntryIdleScreen()
进入后，调用：mmi_idle_set_handler
该函数调用SetKeyHandler(CHISTGetCallLogBySENDKey, KEY_SEND1, KEY_EVENT_DOWN);
CHISTGetCallLogBySENDKey进入后，调用mmi_chist_pre_entry_all_call_list
该函数调用
*type = mmi_chist_action_log_type_all;
mmi_chist_add_action(3, (void*) type, (mmi_chist_action_func_ptr) mmi_chist_read_call_log, (mmi_chist_action_cbk_ptr) mmi_chist_pre_entry_all_call_list_cbk);
这里牵涉到几个函数：
1.mmi_chist_add_action
2.mmi_chist_read_call_log这个函数会调用
ReqReadDialedNum(); ReqReadMissedNum(); ReqReadRecvdNum();
以ReqReadDialedNum为例，会发个消息出去获取已拨电话记录，消息响应函数为RspReadDialedNum
在这个函数中循环调用到
CHISTExtractPSCallLog(&chis_p->dialedCalls[chis_p->nDialedCalls], &rsp->list[index]);
chis_p->nDialedCalls++;
读取出每一个电话记录。
CHISTExtractPSCallLog这个函数将获取到的电话簿（rsp->list）的姓名和号码转成合适的编码放到chis_p->dialedCalls这个全局变量中。
3.mmi_chist_pre_entry_all_call_list_cbk这个函数会调用EntryCHISTViewMixedCallList，为最终的显示界面函数。
显示时会读取chis_p这个全局变量中的内容，show函数为ShowCategory184Screen

以上为读取和显示通话记录，下面是写：
在有了一个新的通话记录，比如说拨出电话挂断后，会调用srv_ucm_log_call_history函数，
进入后，调用CHISTLogDialedCall
进入后，调用
mmi_chist_add_action(1, (void*) call_log, (mmi_chist_action_func_ptr) mmi_chist_write_dialed_call, (mmi_chist_action_cbk_ptr) mmi_chist_write_call_log_cbk);
其中mmi_chist_write_dialed_call调用ReqWriteCallLog(call, PHB_LND);
进入后，将call信息以消息形式发送出去

设置MMI的消息响应函数为RspWriteNum，响应后，调用RspWriteDialedNum(info);
这个函数主要是进行一些MMI相关的处理，并没有进行通话记录保存的工作。

———————————————————————————-
于是从另一个方向进行查找：
通过nvram找到phb_write_ln_to_nvram函数，是写通话记录到nvram的函数，这个函数被phb_write_ln_handler调用，
而phb_write_ln_handler函数被phb_main函数调用，phb_main函数中的代码都是通过消息响应的方式执行，
在代码中不能找到phb_main被调用的地方，在lis文件中查找，找到
l4_create.obj(i.process_ilm) refers to phb_main.obj(i.phb_main) for phb_main
这一部分的处理被L4层封装起来了，应该是L4层收到请求后，发送消息到PHB。通过trace，在ReqWriteCallLog之后，mmi_chist_update_call_log_after_write之前，会调用到phb_write_ln_handler。

通过trace，在phb_write_ln_handler这个函数中，调用到函数phb_update_ln，进入后，调用到phb_ln_renew_entry1 和phb_ln_renew_entry2，
经过trace，发现，拨打通话记录的前十位的号码，会调用phb_ln_renew_entry1，拨打后10位的号码，会调用phb_ln_renew_entry2。
phb_ln_renew_entry1和phb_ln_renew_entry2这两个函数的入口为更新的通话记录的index和内容，以及原来的通话记录列表，是属于收到消息后的处理函数。

比较25平台和53平台的phb_update_ln函数，发现53平台的多了两句这样的语句：
kal_mem_cpy((kal_uint8*) record0->array[i].addr_bcd, (kal_uint8*) entry->addr_bcd, MAX_CC_ADDR_LEN);
kal_mem_cpy((kal_uint8*) record0->array[i - PHB_MAX_LN_ENTRIES].addr_bcd, (kal_uint8*) entry->addr_bcd, MAX_CC_ADDR_LEN);
将其去掉后，问题解决。