Android7.0 Rild工作流程
来源:互联网 发布:linux启动hadoop 编辑:程序博客网 时间:2024/05/18 03:12
点击打开链接
一、基于Rild的通信架构
一般智能手机的硬件架构都是两个处理器:
一个处理器用来运行操作系统,上面运行应用程序,这个处理器称作Application Processor,简称AP;另一个处理负责和射频无线通信相关的工作,叫Baseband Processor,简称BP。
在Android系统中,Rild运行在AP上,它是AP和BP在软件层上通信的中枢。
目前通过Rild,AP和BP的通信方式可以分为两种:
第一种是AP发送请求给BP,BP响应并回复AP。此时,BP通过Rild回复的请求被称为solicited Response。
第二种是BP主动发送信息给AP。在这种情况下,BP通过Rild发送的请求被称为unsolicited Response。
基于Rild进程的整个通信架构,基本上如上图所示。
从图中我们可以看出:
1、android框架部分,是通过Phone进程与Rild进程通信的。它们之间的通信方式采用的是socket。
在前面介绍PhoneApp启动时,我们知道Phone进程中有两个Phone对象。每个Phone对象持有一个socket,与对应的Rild进程通信。因此,我们知道手机中实际上启动了两个Rild进程(双卡手机)。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
我们通过usb连接手机后,通过adb shell进入终端,通过ps和grep命令,可以得到上述结果。
明显可以看到一个Phone进程对应者两个Rild进程;同时Rild进程由init进程加载,Phone进程由zygote进程加载。
2、Rild与BP之间并没有直接通信,而是引入了厂商的动态库。
这种设计应该是为了保证灵活性吧。
用面向对象的思想来看,我们可以认为Rild是一个接口,定义了AP、BP双向通信时需要使用的最基本的函数。不同的厂商都需要满足这个接口,以提供手机最基本的通信功能。
至于具体如何实现,是完全独立和自由的。
二、Rild的启动
在hardware/ril/rild/rild.rc中定义了Rild启动时对应的选项:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 1
- 2
- 3
- 4
- 5
- 6
- 7
在Android 7.0之前的版本中,该文件的内容是被定义在init.rc中的。
到了Android7.0 之后,init.rc文件中的许多内容均被移出,添加到各个进程中。如前面分析Vold进程时,对应的启动文件定义于vold.rc中。
个人猜测这些文件应该会在编译时,重新集成起来,毕竟在在rild对应的Android.mk中增加了下述字段:
- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
目前手边没有Android7.0的机器,还不好验证,以后有机会再做尝试。
init进程根据rild.rc文件启动一个Rild进程,还需要根据厂商定义的rc文件启动另一个Rild进程。
厂商定义的rc文件中,与Rild进程相关的主要内容与rild.rc相似,就是socket名称不同。对于第二个Rild进程,其socket名应该为rild2。
现在我们看看Rild进程的main函数,定义于rild.c中:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
根据Rild的main函数,我们可以看出主要就进行了三件事:启动Event Loop、调用RIL_Init函数和注册库函数。
接下来我们分别分析一下主要事件对应的流程。
1、 RIL_startEventLoop
RIL_startEventLoop定义于hardware/ril/libril/ril.cpp中:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
我们需要跟进eventLoop函数:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
1.1 初始化内部数据结构
我们先看看ril_event_init函数:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
可以看出ril_event_init就是初始化readFds、timer_list、pending_list和watch_table,其中后三种数据结构均是用来存放ril_event的。
根据前文的代码,我们知道Rild的main函数中,通过调用RIL_startEventLoop单独启动了一个线程运行eventLoop,这是一个工作线程。
这个工作线程就是靠ril_event结构体来描述自己需要执行的任务,并且它将多个任务按时间顺序组织起来,保存在任务队列中。
ril_event的数据结构如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
如果从设计模式的角度来理解Rild的工作线程,易于看出,这其实是比较典型的命令模式。
就如同之前博客分析vold进程一样,CommandListener收到数据后,调用对应Command的runCommand方法进行处理。
此处,工作线程收到ril_event后,加入队列中,当需要处理时,调用ril_event对应的处理函数func。
1.2 创建wakeupfd ril_event
工作线程完成数据结构的初始化后,创建了第一个ril_event:
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
从上面的代码可以看出,创建的第一个ril_event的fd为管道的读端、回调函数为processWakeupCallback,同时persist属性为true。
1.3 将创建出的ril_event加入到event队列中
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
1.4 进入事件等待循环中
接下来工作线程进入到事件等待循环中:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
至此,RIL_startEventLoop的工作介绍完毕,虽然还没有实际开始工作,但它搭建出了整个事件的处理框架。这里涉及的代码比较繁杂,我们还是借助于图形总结一下整个过程:
1.4.1 整体架构
如上图所示,Rild的main函数中调用RIL_startEventLoop。在RIL_startEventLoop中创建出工作线程,执行eventLoop函数:
Step 1、利用ril_event_init函数初始化数据结构,主要包括readFds、timer_list、pending_list和watch_table;
Step 2、创建出一个pipe对象;
Step 3、创建s_wakeupfd_event,该event的fd指定为pipe的读端;这个event将被加入到watch_table,同时pipe的读端将被加入到readFds中;注意这个event的persist属性为true,于是将永远存在于watch_table中;
Step 4、调用ril_event_loop开始监听事件的到来。
先在我们结合图形,举几个例子看看,整个事件处理框架是如何工作的。
注意到初始时,timer_list为空,因此ril_event_loop中将不限时地等待readFds。
1.4.2 ril_event加入到timer_list
当其它线程调用ril_timer_add函数(定义于ril_event.cpp中)填加ril_event事件时:
Step 1、新到来的ril_event将按超时时间,由小到大加入到timer_list中;同时,其它线程一般会调用triggerEvLoop,该函数将会向pipe的写端写入数据。
Step 2、于是,pipe的读端将会收到数据;由于初始时pipe读端已经加入到来readFds,因此ril_event_loop将从等待中唤醒。
Step 3、此时,ril_event_loop将执行timer_list和watch_table中存储的事件。注意到在timer_list中,只有超时的事件才会被处理;在watch_table中,只有对应fd已经存入readFds(此时使用的是拷贝对象)的事件才会被执行。
注意到初始时加入watch_table的s_wakeupfd_event,永远满足执行条件;因此,每次ril_event_loop被唤醒时,该事件都被添加到pending_list。
s_wakeupfd_event对应的执行函数,将会清空pipe的buffer。
Step 4、 处理完加入到pending_list中的事件后,ril_event_loop将根据timer_list中事件的超时时间,决定等待readFds的时间。
如果在等待超时之前,没有其它事件到来,那么ril_event_loop将在等待超时后处理timer_list中的事件;否则,仅会处理新到来的事件,不会处理timer_list事件。
1.4.3 ril_event加入到watch_table
当其它线程调用ril_event_add函数(定义于ril_event.cpp中)增加ril_event事件时:
Step 1、当watch_table有空位时,新加入的ril_event将被加入到watch_table中,同时对应的fd被添加到readFds;同时,其它线程可能会调用triggerEvLoop,以唤醒ril_event_loop。
Step 2、 ril_event_loop被唤醒后,并不会执行新加入到watch_table中的ril_event,因为它们的fd才刚被加入到readFds中。
从代码里我们可以看到,ril_event_loop当次循环处理的是readFds的拷贝对应的数据,因此新加入watch_table的ril_event在下次唤醒时才能够被处理。
Step 3、由于加入ril_event对应的fd被加入到readFds中,因此如果对应的fd写入数据时,也会唤醒ril_event_loop。
至此,RIL_startEventLoop的主要流程介绍完毕,可以看到它的主要工作就是启动工作线程,然后等待事件的添加
那么接下来我们可以看看下一个Rild中下一个重要操作,即调用RIL_Init函数。
2、 RIL_Init
RIL_Init定义于动态库中,考虑到厂商的保密性,我们只能分析Android原生的Reference-ril库。
在Android的原生库中,RIL_Init定义于hardware/ril/reference-ril/reference-ril.c中。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
从代码上来看RIL_Init函数比较简单,就干了三件事:保存Rild传入的RIL_Env结构体;创建s_tid_mainloop线程,执行函数为mainLoop;返回RIL_RadioFunctions结构体。
这里需要注意的是:RIL_Env和RIL_RadioFunctions结构体,就是Rild架构中用来隔离通用代码和厂商相关代码的接口。即动态库通过RIL_Env调用Rild中的接口,Rild通过RIL_RadioFunctions调用动态库中的接口。
2.1 通信接口
我们先看看RIL_RadioFunctions结构体:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
这里需要重点关注的函数是onRequest,它被Rild用来向动态库提交一个请求。
Rild架构采用的是异步请求/处理的通信方式,Rild通过onRequest向动态库提交一个请求,然后返回进行自己的工作;动态库处理这个请求,当处理完请求后,通过回调的方式将结果通知给Rild。
我们再来看看RIL_Env结构体:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
在RIL_Env的结构体中,主要需要关注的是OnRequestComplete和OnUnsolicitedResponse。
2.2 mainLoop
动态库的RIL_Init被调用后,将会创建一个工作线程,其运行函数为mainLoop:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
从上面的代码可以看出,mainLoop的工作其实就是初始化并监控AT模块,一但AT模块被关闭,那么mainLoop就要重新打开并初始化它。
2.2.1 at_open
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
在at_open中创建了一个工作线程,运行函数为readLoop:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
从上面的代码,我们知道at_open函数其实就是启动一个工作线程,用于接收AT设备的数据,然后进行处理。
2.2.1 initializeCallback
调用at_open后,main利用RIL_requestTimedCallback向Rild发送一个超时任务。
- 1
- 1
可以看到RIL_requestTimedCallback是一个宏,实际上还是通过RIL_Env中RequestTimedCallback函数发送超时任务。
我们看看ril.cpp中,该函数的实现:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
当Rild中的eventLoop处理该超时任务时,就会回调Reference-ril库中的initializeCallback:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
至此,我们以Reference-ril库为例,分析了RIL_Init函数的基本功能。
如上图所示,RIL_Init的主要工作包括:
1、创建一个mainLoop工作线程,该线程用于完成实际的工作。
2、在mainLoop线程中,通过at_open开启AT模块,同时启动readLoop工作线程。readLoop工作线程负责从AT设备中读取信息,并执行对应的函数调用。
3、调用at_open后,mainLoop线程向Rild进程发送一个超时事件,该事件被Rild处理后,将调用initializeCallback函数。initializeCallback函数,将完成Modem的初始化工作。
其实上,mainLoop可以直接进行Modem初始化的工作;这里发送超时事件给Rild,通过回调进行初始化,可能是为了确保RIL_startEventLoop已经执行成功。
4、mainLoop最后通过waitForClose监控AT模块,一旦AT模块被关闭,mainLoop将重新进行初始化AT模块的工作。
3、RIL_register
现在我们分析一下Rild的main函数中,最后一个关键函数RIL_register:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
从上面的代码可以看出,RIL_register实际就是初始化监听socket所需的参数,然后开始监听socket是否有数据到来。
在前面已经提到过,Android中会创建出两个Rild进程,每个Rild进程均会调用RIL_register函数。
虽然s_registerCalled为一个静态变量,但在进程的维度上,它是私有的。因此,每个Rild进程均会成功调用一次RIL_register。
接下来,我们看看startListen函数:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
3.1 RIL_getRilSocketName
startListen函数中,通过调用RIL_getRilSocketName得到需监听的socket的名称。
- 1
- 2
- 3
- 1
- 2
- 3
RIL_getRilSocketName的内容很简单,就是返回变量rild。
那么rild变量又是何时设置的呢?
对于第一个Rild进程,在ril.cpp中,定义了rild的内容为“rild”。
- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
对于第二个Rild进程,在Rild启动后,对应的main函数中,利用RIL_setRilSocketName修改rild的内容:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
从上面的代码,我们可以看出两个Rild进程确实监听的是不同的socket。
3.2 listenCallback
利用listen函数将Rild变成监听进程后,start_listen通过ril_event_set构造了一个非超时的任务,并利用rilEventAddWakeup将该任务加入到watch_table中。
注意到ril_event的fd为待监听的socket,因此当ril_event被加入到watch_table后,该socket对应的fd将被加入到readFds中。
一旦该socket可读(即客户端connect成功),那么eventLoop中的select函数将会返回,执行listenCallback函数。
实际上,由于该任务的persist属性为false,因此执行完毕后,ril_event将从watch_table中移除,socket对应的fd也将被从readFds中移除。
这表明,Rild进程不会再监听socket对应的connect请求,只支持一个客户端的连接,仅会调用一次listenCallback函数。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
至此,RIL_register的主要工作介绍完毕。从上述分析,我们可以看出RIL_register其实就是创建出与RIL.Java通信的服务端socket,然后监听客户端请求。一旦监听到客户端请求后,利用accept分配出对应的通信用socket。然后,再监听该分配出的socket,以处理客户端发来的数据。
4、 Rild main函数总结
现在我们已经分析完Rild main函数的主要流程了,回过头来看看Rild整体的设计思路:
1、利用RIL_startEventLoop,初始化通信框架。不论是初始化AT设备,还是接收来自RIL.java的请求,都依赖于Rild进程的通信架构,因此在main函数的最开始,对通信框架进行了初始化。
2、利用RIL_Init开启AT设备,并完成modem的初始化。AP侧利用RIL.java下发指令,最终还是需要利用AT传给modem来执行。因此,在通信框架初始化完毕后,首先就要完成AT和modem的配置。
3、利用RIL_register将Rild进程变成服务进程,等待RIL.java中socket的连接;连接成功后,开始处理来自RIL.java的数据。
三、实例分析
我们已经分析了Rild进程的工作,现在来结合数据业务拨号,看看实际过程中,Rild的工作情况。
1、RIL.java
首先,在之前的博客中,介绍数据业务基础类的创建时,我们提到过RIL.java在PhoneFactory的makeDefaultPhone中创建:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
我们看看RIL的构造函数:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
2、 RILReceiver
我们看看RILReceiver相关的函数:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
从RILReceiver的代码可以看出,其主要功能就是完成与Rild进程中server socket的连接,然后接收并处理Rild进程发来的数据。
3、 setupDataCall
之前的博客介绍数据业务拨号流程时,我们知道在DataConnection中,最终将通过调用RIL的setupDataCall函数,将消息发往modem:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
我们看看RILSender:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
4、processCommandsCallback
根据前面对Rild进程的分析,我们知道当Rild进程收到RIL.java中发送来的数据后,将利用processCommandsCallback进行处理:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
上面的代码中,出现了一个s_commands数组,它保存了一些CommandInfo结构,这个结构封装了Rild对AT指令的处理函数。另外,Rild还定义了一个s_unsolResponses数组,它封装了unsolicited Response对应的一些处理函数。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
这里我们重点看一下s_commands数组。
CommandInfo按照requestNumber的先后顺序加入到s_commands中,因此requestNumber就是对应CommandInfo的索引。
我们看看ril_commands.h:
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
在RIL.java中,指定了拨号对应的请求号为RIL_REQUEST_SETUP_DATA_CALL,因此Rild中对应的处理函数为dispatchDataCall。
5、dispatchDataCall
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
6、onRequest
此处,我们以Reference-ril中的onRequest为例,进行分析:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
7、RIL_onRequestComplete
当指令处理完毕后,Reference-ril将调用RIL_onRequestComplete通知RIL.java处理结果。
- 1
- 1
可以看到RIL_onRequestComplete是一个宏,实际上调用的是s_rilenv的OnRequestComplete函数。
在Rild进程的main函数中,调用RIL_Init时传入了s_rilEnv,我们看看ril.cpp中的RIL_onRequestComplete:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
8、processResponse
在前面介绍RILReceiver时,我们知道RILReceiver与Rild连接成功后,将会一直监听发来的数据,并调用processResponse进行处理。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
在理解了Rild搭建的通信架构后,分析底层拨号的流程还是比较简单的。
- Android7.0 Rild工作流程
- Android7.0 Rild工作流程
- Android7.0 Rild工作流程
- Android7.0 Vold 进程工作机制分析之整体流程
- Android7.0 Vold 进程工作机制分析之整体流程
- Android7.0关机流程分析
- Android7.0 启动Launcher流程
- Android7.0 startService流程分析
- Android7.0 系统启动流程---system_server
- Android7.0关机流程分析
- android7.0 wallpaper显示流程
- Android7.0 Doze模式流程
- android7.0拨号流程分析
- Android7.0 编译系统流程分析
- Android7.0 PowerManagerService(4) Power按键流程
- Android7.0 Activity的绘制加载流程
- [Android7.0]开启NFC的流程分析
- Android7.0 编译系统流程分析
- 机器学习中训练集、验证集和测试集的作用
- 【第四届图灵杯A】谷神的赌博游戏
- xpath的用法
- caffe学习笔记9:运行caffe自带的两个例子
- final,this,super,static
- Android7.0 Rild工作流程
- IP字段和tcp字段的解析
- 8、使用setup设置网络
- linux 下 apache启动、停止、重启命令
- GemFire/Geode中的国际化(一)
- 安装VirtualBox的时候遇到的问题
- Spring 深入浅出核心技术(二)
- OpenSSL在使用X25519时的小坑
- 奶牛异或