Android RIL开发介绍

更新时间:2023-08-12 02:50:45 阅读: 评论:0

Android RIL开发介绍
------------------海信移动技术公司第三研究所陈泽元20130314
篇前语
RIL(Radio Interface Layer)的设计目的,就是为了将modem功能抽象出来,使其不会因不同的modem而做重大的颠覆性修改和调试。它提供了AP与modem 之间通讯的桥梁,在保证AP与modem正常有效通讯的同时,尽可能的简化AP 与modem之间的交互。
RIL将用户所需要用到的各种功能抽象成对应的RIL request和unsolicited command,最终转换成3GPP标准的AT命令,交由modem处理,并将处理结果返回给UI。
AT命令通常被用作与第三方modem通讯的一个非常有效的方式,当第三方模块无法轻易的移植到某个平台上或仅提供库文件、二进制文件使用时,通常会使用AT命令来与模块进行交互,以实现相应的功能。AT命令在3GPP中都有相
关规定,能够支持modem的各种功能,个人理解,实际它上就是modem各种
功能的抽象,提供与外界通讯的接口。(实际上,我们也可以根据AT命令的格式,自己进行扩展,应用
于非无线通讯的第三方交互中,比如PC客户端与某模块之间的通讯,或某两个PC应用程序之间的通讯,都是可以的,关键就看你如何理解,如何定义,如何抽象出你的AT命令了)。
AT命令按照请求方式分为两种:一种是主动请求命令,称作request AT command;另外一种是非请求时的modem上报命令,称作unsolicited AT command。
在Android平台中,RIL已被模块化,包含三部分:RILD、libril和Vendor RIL。
本篇的目的就是讲解Android平台这三个模块相关的重点概念和关键点,同时对扩展新的一个RIL request的处理和新的unsolicited AT command的处理做个
prompting介绍,适合于刚接手RIL开发的工程师以尽快的熟悉自己的开发工作。
英语短语
一、Android RILD介绍
RILD是一个开机启动的后台服务进程,在中定义。当系统起来后,init 进程在解析中的rvice时,就会启动并加载RILD进程,同时创建两个名为rild和rild-debug的socket。RILD作为该socket的服务器端运行,等待客户端RILJ的连接。Android的socket通讯是基于linux的socket,在linux socket基础上做了一层封装,供Java层调用。
RILD在中的启动:
rvice ril-daemon /system/bin/rildredcircle
class late_startlandway
socket rild stream 660 root radio
socket rild-debug stream 660 radio system
ur root
solanagroup radio cache inet misc audio sdcard_rw
RILD进程启动后,主要做以下几件事情:
(1) 依次通过dlopen()和dlsym()来找到Vendor RIL链接库,并调用RIL_Init()来初始化RIL和modem (将在后面Vendor RIL中讲解)
(2) 调用RIL_startEventLoop()创建一个独立线程,在该线程中建立一个基于pipe的多I/O复用的RIL消息队列处理机制,并进入ril_event_loop()循环,lect pipe中的fd来处理各个RIL消息(将在libril中讲解)
(3) 调用RIL_register()监听客户端的socket连接,一旦发现有客户端连接成功,将进入processCommandsCallback()循环,不断读取来自客户端的request数据并分发处理。
其中,(1)将进入Vendor RIL;(2)和(3)将进入libril,而RILD在处理完这三件事情后,就没有任何工作了,将在代码
while(1) {
南昌西点培训班有哪些
sleep(0x00ffffff);
}
中一直sleep()下去。
下面对RILD所做的三件事情做个较详细的介绍:
(1) 加载Vendor RIL链接库
Vendor RIL库有两种方式可以指定:
①在中通过-l参数指定,如:
rvice ril-daemon /system/bin/rild -l /system/lib/libreference-ril-gsm.so
②在system.prop中通过rild.libpath来指定,如:
rild.libpath=/system/lib/libreference-ril-gsm.so
另外,在modem通讯时,必须指定通讯的端口,用于AT命令通讯,也有两种方式可以指定通讯端口:
①在中通过-d参数指定,如:
rvice ril-daemon /system/bin/rild -l /system/lib/libreference-ril-gsm.so -- -d
/dev/ttyS0
②在system.prop中通过rild.libargs来指定,如:
rild.libargs=-d /dev/ttyS0
Vendor RIL库是通过接口dlopen()来加载的,dlHandle = dlopen(rilLibPath, RTLD_NOW);加载后,将通过代码rilInit = (const RIL_RadioFunctions *(*)(const struct RIL_Env *, int, char **))dlsym(dlHandle, "RIL_Init");来找到接口RIL_Init(),并在接下来调用该接口(funcs = rilInit(&s_ril
Env, argc, rilArgv);),从而让Vendor RIL进行RIL及modem相关的一系列初始化动作,为接下来的AT通讯做好准备,这部分内容将在Vendor RIL部分重点讲解。
值得重点提到的一点是,在RIL_init()调用处理结束后,会返回
RIL_RadioFunctions的一组函数指针,其中最为核心接口是onRequest(),用于AT request的处理。该组函数指针将由RIL_register()传递到libril中,在处理AT request 时,及时调用onRequest()将来自RILJ的request转换成AT命令,并发送给modem 进行处理。
(2) 启动RIL消息队列处理机制
RIL消息队列机制的启动位于RIL_startEventLoop(),它内部将启动一个独立
线程并进入eventLoop(),开始消息的循环处理。
而在eventLoop()内部,创建了一个pipe,这是I/O多路复用处理RIL消息队列的核心。每种RIL_event,都将与一个fd一一对应,每个fd都有一个回调函数与其绑定,即每一种RIL_event都有一个handler与其对应,该handler就是在添加RIL_event时,调用ril_event_t()所绑定的回调函数。当有新的一种RIL_event 需要处理时,会首先调用ril_event_t()将event与回调函数绑定,然后调用rilEventAddWakeup()将其加入watch_table待处理事件链表中,并将其fd放入readfs集中,等待pipe的
lect调度,一旦得到调度,就会依次调用processReadReadies(&rfds, n)和firePending()对该event进行处理。
实现RIL消息队列处理最核心的接口有:(I/O多路复用机制)
RIL_startEventLoop():启动RIL消息队列循环机制的总入口。
eventLoop():启动一个独立线程,用来处理RIL消息队列中的各个消息,并在其中创建一个pipe,这是设计I/O多路复用机制处理RIL_event的核心。
ril_event_loop():实现RIL_event的处理,当有fd准备好时,lect将得到
返回。(后续流程是:找到一个准备好的fd,将其对应的event取出并通过该event 早先绑定的回调函数进行处理,处理完毕,该event将移除出pending_list队列。)rilEventAddWakeup():将调用ril_event_add()向watch_table中加入等待处理的RIL_event,同时还会调用triggerEvLoop()向pipe中写入一个空格字符,目的是让ril_event_loop()中的lect能够得到一次执行,这样新加入的RIL_event
就可以得以被pipe跟踪。
processTimeouts():处理timer_list中做过延迟的RIL_event,将其转移到pending_list中,等待处理。
像有些internal事件在调用RIL_requestTimedCallback()后,就会被放入该队列中。典型的,比如:当处理来自RILJ的某个request时,当前RIL不满足处理条件,则会调用该接口。开机SIM卡未初始化好时,RIL就会调用该接口,过一段时间来检查一次SIM是否ready,从而processReadReadies():将watch_table中待处理的RIL_event转移到pending_list中,表示已经准备好了,可以处理了。
firePending():处理pending_list队列中的已经准备好的RIL_event,通过回
学日语的网站
调函数来处理该event,处理完毕,就清除出队列。
(3) 监听来自客户端的socket连接
监听客户端的socket连接,是RIL_event的一种,即s_listen_event,绑定的回调函数是listenCallback()。当发现有客户端连接时,事件s_commands_event
就会被加入RIL消息队列,该事件就是不停的从socket读取来自客户端的数据(即RILJ的request请求)。在rild socket中交互的数据,不管是客户端发给服务器端的request,还是服务器端应答的respon,或者服务器端主动上报的unsolicited 数据,都是序列化后的字节流数据(通过Parcel进行数据的字节化处理)。
RILD在做完这三件事情后,任务就完成了,剩下的工作交由libril和Vendor RIL 负责。
libril负责socket数据的通讯,将RILJ的request请求通过dispatchFunction()
分配给Vendor RIL的onRequest()处理,流程由此转入VendorRIL;Vendor RIL在处理完后,将调用RIL_onRequestComplete(),将respon数据交给libril,流程又由此转入libril。它是整个RIL处理流程的核心部分。libril部分与modem无关,Android平台已经做得很好了,更换不同厂家、不同制式的modem,该部分也无需修改。
Vendor RIL负责具体处理RILJ的request,以及主动上报的AT命令。它是用来辅助libril的,处理AT命令相关以及与modem进行通讯。根据不同的modem,来对该模块进行定制。由于modem的不同,这部分内容是需要我们独立维护,并且改动最大的。
二、Android libril介绍
Android libri的代码实现位于/hardware/ril/libril文件夹下的ril.cpp和
ril_event.cpp文件。
libril是Android RIL的核心,从RILD的main()接口,可以看出,libril提供的主要功能分布在两个接口内:
一个是RIL_startEventLoop()接口,另一个是RIL_register()接口。
RIL_startEventLoop()方法所提供的功能就是启用eventLoop线程,开始执行RIL消息队列。
RIL_register()方法的主要功能是启动名为rild 的监听端口,等待java客户端通过socket进行连接,一旦连接上,RIL将通过接口processCommandsCallback(),不断的从socket端口,以非阻塞的方式读取来自RILJ的request请求。
由于这部分基本上是以回调函数的流程来处理的,所以此处不讲解代码的处理流程,而是着重梳理流程处理中的关键变量和环节。
1、关于libril中RIL消息队列所涉及的几个RIL_event说明(这是RIL的真正核心,看看Android是如何来设计这个框架的:多路I/O复用机制. 每种RIL_event 都与一个fd对应,因此pipe在lect到准备好的fd时,意味这该RIL_event可以进行处理了):
(1) s_commands_event: (与s_fdCommand对应)
该RIL_event在RILJ和RILD之间的socket建立连接后,将初始化并放入RIL 消息队列,同时绑定回调接口processCommandsCallback(),该接口是一个死循环操作,不断的从socket读取来自RILJ的request请求,并依次调用processCommandBuffer()--->dispatchFunction()将request分发到vendor RIL,交由onRequest()来统一处理。正常情况下,processCommandsCallback()的死循环是不会退出的,一旦退出,则预示着socket连接出现问题了,RILJ与RILD之间将无法继续通讯了。
s_commands_event的初始化和回调接口的绑定是在s_listen_event的回调函数中进行的,当s_listen_event监听到来自RILJ的socket连接请求后,
s_commands_event将会被立即加入RIL消息队列;当socket连接出现异常后,ril_event_del(&s_commands_event)将被调用,从而将s_commands_event清除除RIL消息队列,此时,RILD也就不再接收来自RILJ的request请求了。
dispatchFunction()是控制流程由RILD转入Vendor RIL的转折点,从该接口调
用开始,request流程将交由Vendor RIL来处理,并在处理完毕,modem返回结果后,Vendor RIL将调用RIL_onRequestComplete(),流程又由Vendor RIL回到libril,将结果通过socket回传给RILJ,以依次上报给Android Framework及UI。
polysaccharides(2) s_wakeupfd_event: (与s_fdWakeupRead对应)
RILD启动后,最先加入RIL消息队列的一个消息。其初始化流程为:
bellyRIL_register()--> RIL_startEventLoop()--> pthread_create(&s_tid_dispatch, &attr, eventLoop, NULL) --> eventLoop() --> ril_event_loop()--> for(;;){n = lect(nfds, &rfds, NULL, NULL, ptv); firePending()}
中译英在线翻译
RIL消息的循环处理就是在ril_event_loop()中实现的。它所对应的回调函数是processWakeupCallback()。但processWakeupCallback()内部并没有太多的处理,目的仅仅是让pipe的lect()能够得到一次返回,这样lect()就能够跟踪新的消息队列了。
从上面流程可知,s_wakeupfd_event实际上是处理整个RIL消息的核心部分,单独启动了一个thread,并在for循环中循环处理各个消息,当遇到有消息到达后,将通过firePending()接口中的语句ev->func(ev->fd, 0, ev->param),回调
ril_event_t()中该event所绑定的回调函数来处理相应的消息。(ril_event_t()将各个消息与相应的回调函数做了绑定,保证ev->func(ev->fd, 0, ev->param)能够准确的调用event所对应的回调函数以处理各个消息)
从libril代码看,RIL消息一共定义了5个,那么它们又是如何保证互不干扰并及时得到处理的呢?
这是由于在eventLoop()中实现了一个pipe,(它实现了I/O多路复用,以避免如果只有一个I/O时,不管其它I/O是否有数据,都会被阻塞,即使采用I/O 轮询的方式,也会浪费很多的cpu时间;该I/O多路复用机制带来的好处是:它会先构造一张有关I/O描述符的列表,然后调用lect函数,当IO描述符列表中的一个描述符准备好进行I/O时,该函数返回,并告知可以读或写哪个描述符,而具体的处理来自各I/O描述符的数据,则交由各自的回调函数),各消息通过它来统一调度维护,它包含一个s_fdWak
eupRead和一个s_fdWakeupWrite,分别对应pipe的读操作和写操作,并在ril_event_loop()中通过lect()来调度到来的各个event,得到调度的event都交由firePending()及时处理。
在各个event加入pipe统一管理时,google的牛人也做了一个很巧妙的设计,即他们并不是直接通过调用ril_event_add()将event加入RIL消息队列,而是调用了rilEventAddWakeup()来将event加入RIL消息队列,rilEventAddWakeup()不仅仅执行了ril_event_add()的动作,而且调用了triggerEvLoop()接口。我们看接口triggerEvLoop()的实现,该接口代码很简单,就一个核心语句ret = write
(s_fdWakeupWrite, " ", 1),其作用是向pipe写一个空格字符,当向pipe写入内容后,ril_event_loop()中的lect()操作将得到执行,从而将新添加的event加入了RIL消息队列并得以跟踪,否则如果只是简单的调用ril_event_add(),将只能添加事件到队列中,但达不到及时跟踪该event的目的,这就是向RIL消息队列添加新的event时,为何先调用rilEventAddWakeup(),而不是直接调用ril_event_add()。
添加一个新RIL_event的操作是通过ril_event_t()来完成的。在调用接口
ril_event_add()将这个新的event加入到消息队列的过程中,add会把队列里所有ril_event的fd,放入一个fd集合readFds中。这样ril_event_loop能通过一个多

本文发布于:2023-08-12 02:50:45,感谢您对本站的认可!

本文链接:https://www.wtabcd.cn/fanwen/fan/90/194237.html

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

上一篇:CCP代码
标签:处理   消息   队列   函数   客户端   进行   回调   流程
相关文章
留言与评论(共有 0 条评论)
   
验证码:
Copyright ©2019-2022 Comsenz Inc.Powered by © 专利检索| 网站地图