Android GSM 驱动模块详细分析

核心提示：这几个类型的解析都很相仿，通过一定的判断(比较AT头标记等)，Android GSM 驱动模块详细分析(9)，如果是对应的响应，就通过 addIntermediate挂到一个临时结果sp_response->p_intermediates队列里，到这里，我们分析了自动上报与命令响应，如果不是对应响应，那它其实应该

这几个类型的解析都很相仿，通过一定的判断(比较AT头标记等)，如果是对应的响应，就通过 addIntermediate挂到一个临时结果sp_response->p_intermediates队列里。如果不是对应响应，那它其实应该是穿插其中的自动上报，用onUnsolicite来处理。

具体响应，只起一个获取响应信息到临时结果，等待具体分析的作用。无论有无具体响应，最终都得以标准响应handleFinalResponse来完成，也就是接受到OK,ERROR等标准response来结束，这是大多数AT命令的规范。

handleFinalResponse 会设置s_commandcond这一object，也就是at_send_command_full_nolock等待的对象。到这里，响应的完整信息已经完全获得，send command可以进一步处理返回的信息了(临时结果，以及标准返回的成功或失败，都在sp_response中)。

pp_outResponse参数将sp_response返回给调用at_send_command_full_nolock的函数。

继续我们在文章二的分析的话，这个函数其实是requestDial，不过requestDial忽略了响应，所以我们另外看个例子，如requestSignalStrength，命令其实就是前面提到的at+csq：

可以看到确实是通过at_send_command_singleline来进行的操作，response在p_response中。

p_response如果返回失败(也就是标准响应的ERROR等造成)，则通过RIL_onRequestComplete发送返回数据给上层，结束命令。

如果成功，则进一步分析p_response->p_intermediates， 同样是通过at_tok.c里的函数进行分析。并同样将结果通过RIL_onRequestComplete返回。

RIL_onRequestComplete：

RIL_onRequestComplete和RIL_onUnsolicitedResponse很相仿，功能也一致。

通过Parcel来传递回上层，同样是先写入RESPONSE_SOLICITED(区别于 RESPONSE_UNSOLICITED)，pRI->token(上层传下的request号)，错误码(send command的错误，不是AT响应)。如果有AT响应，通过访问pRI->pCI->responseFunction来完成具体 response的解析，并写入Parcel。

然后通过同样的途径：

sendResponse-->sendResponseRaw-->blockingWrite-->write to s_fdCommand

完成最终的响应传递。

到这里，我们分析了自动上报与命令响应，其实response部分，也就告一段落了