但是，我们认为全球移动用户从中能获得的潜在利益是值得付出这些努力的。如果你也是一个开发者，并对我们的想法感兴趣，就请再给我们一星期的时间，届时谷歌便能提供 Android GSM了。
这个任务的入口是RIL_Init, RIL_Init首先通过参数获取硬件接口的设备文件或模拟硬件接口的socket. 接下来便新开一个线程继续初始化， 即mainLoop。mainLoop的主要任务是建立起与硬件的通信，然后通过read方法阻塞等待硬件的主动上报或响应。在注册一些基础回调（timeout,readerclose）后。
mainLoop首先打开硬件设备文件，建立起与硬件的通信，s_device_path和s_port是前面获取的设备路径参数，将其打开（两者可以同时打开并拥有各自的reader，这里也很容易添加双卡双待等支持）。
接下来通过at_open函数建立起这一设备文件上的reader等待循环，这也是通过新建一个线程完成， ret = pthread_create(&s_tid_reader, &attr, readerLoop, &attr)，入口点readerLoop。
AT命令都是以\r\n或\n\r的换行符来作为分隔符的，所以readerLoop是line驱动的，除非出错，超时等，否则会读到一行完整的响应或主动上报，才会返回。这个循环跑起来以后，我们基本的AT响应机制已经建立了起来。它的具体分析，包括at_open中挂接的ATUnsolHandler, 我们都放到后面分析response的连载文章里去。
有了响应的机制（当然，能与硬件通信也已经可以发请求了），通过RIL_requestTimedCallback(initializeCallback, NULL, &TIMEVAL_0)，跑到initializeCallback中，执行一些Modem的初始化命令，主要都是AT命令的方式。
AT命令的流程，我们放到后面分析request的连载文章里。这里可以看到，主要是一些参数配置，以及网络状态的检查等。其中最重要的是onRequest域，上层来的请求都由这个函数进行映射后转换成对应的AT命令发给硬件。
rild通过RIL_register注册这一指针。RIL_register中要完成的另外一个任务，就是打开前面提到的跟上层通信的socket接口（s_fdListen是主接口，s_fdDebug供调试时使用）。然后将这两个socket接口使用任务一中实现的机制进行注册（仅列出s_fdListen）ril_event_set (&s_listen_event, s_fdListen, false,
这样将两个Android GSM加到任务一中建立起来多路复用I/O的检查句柄集合中，一旦有上层来的（调试）请求，event机制便能响应处理了。rr是以RIL_REQUEST_DIAL为request号而申请的一个RILRequest对象.这个request号在java框架和rild库中共享（参考RILConstants.java中这些值的由来:)
RILRequest初始化的时候,会连接名为rild的socket（也就是rild中s_listen_event绑定的socket）,初始化数据传输的通道。rr.mp是Parcel对象,Parcel是一套简单的序列化协议,用于将对象（或对象的成员）序列化成字节流,以供传递参数之用。
这里可以看到Android GSM和int clirMode都是将依次序列化的成员.在这之前,rr初始化的时候,request号跟request的序列号（自动生成的递增数）,已经成为头两个将被序列化的成员.这为后面的request解析打下了基础。
【编辑推荐】
