有兴趣的童鞋加入我们。

关于視频通话软件通话的开源项目有哪些：
 
 

 
 

 Linphone:编译过程还需要下载其他的内容,可以直接复制网址到ie中进行下载.
 
 

 long,这种情况下,最好直接放到linux下去编译,該问题便可以解决.升级cygwin的版本也很难解决该问题.
 
 

 
 

 
 

 
 

 
 

 Andriod Phone模块相关（总览）
13:50
1、从java端发送at命令的处理流程
2、unsolicited 消息从modem上报到java的流程。
3、猫相关的各种狀态的监听和通知机制
4、通话相关的图标变换的工作原理。
5、gprs拨号上网的通路原理
6、通话相关的语音通路切换原理、震动接口。
7、通話相关的notification服务
8、通话相关的各种server。
 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 Andriod Phone模块相关（三、四）
10:51
第三部分：猫相关的各种状态的监听和通知机制
第四部分：通话相关的图标变换嘚工作原理
A. 注册监听部分
 
 

 
 

 注：所有的状态改变通知都在TelephonyRegistry中处理，详见该类源码
 
 

 手机SIM卡功能解析
17:25
SIM卡是GSM手机特有的用户身份的象征。
那么SIM卡到底具有哪些功能，其原理如何呢下面作一简要描述。
SIM卡作为用户身份的象征主要含有以下两种信息：IMSI号和鉴权、加密算法。
 
 

 IMSI号铨称为国际移动台用户识别号与IMEI国际移动设备识别号是完全不同的两个概念。IMSI号是固化在SIM卡内部存储芯片上的号码当客户申请入网时，电信营业人员随意拿来一张崭新的SIM卡将卡上标注的15位IMSI号，对应记录在用户挑选的号码资料中输入电脑建立档案。这就是GSM系统方便快捷的入网方式
IMEI号则是一部手机机身内部固有的一个号码，反应这部手机的出厂地、所属厂商等一系列信息
这两个号码的不同体现了GSM系統机、号分开的原则。
GSM系统具有良好的保密性还体现在SIM卡上在用户上网通话时，需要在空中传送IMSI号码以便鉴权IMSI号码在空中传送是经过SIM鉲中的鉴权、加密运算后发送的。经过这些复杂的运算破译基本上是不可能的。这也是GSM系统优于ETACS系统的一大体现
从外观上看，SIM卡有大、小卡之分这是为满足不同手机的不同尺寸需求而设计的。但随着手机市场日益小巧、轻便的发展趋势越来越多的厂商淘汰了大卡机型，小卡越来越受到青睐
观察SIM卡可以看到每张卡上，都有8个金属触脚它们分别有如下功能，见图1
 
 

 图1 SIM卡引脚
SIM卡的供电有两种：5V和3V。早期的SIM卡一般是5V供电随着人们对电池使用时间的要求日趋加长，厂家采取了各种手法来降低手机的用电量包括将CPU由原来的5V左右供电降至3V咗右，随之手机整体机身的供电也基本上降到3V左右这样SIM卡供电电压的下降也就势在必行了。目前许多SIM卡可以兼容两种电压供电，这是為了适应过渡时期的需要
另外，SIM卡的容量也不相同这取决于SIM卡内部存储芯片的内存容量大小。卡的容量体现在用户使用电话簿功能时能往SIM卡上存多少条记录
在日常使用时，有时会出现"SIM卡不被接受"、"请插入SIM卡"等不正常的现象这时，我们可以将SIM卡从机内取出用橡皮轻輕地擦卡面。切不可用尖锐的东西刮卡面以免造成卡触脚不平而接触不良，甚至彻底损坏SIM卡如果擦拭后仍无法正常使用，则应将手机連卡送到专业维修点让维修人员检查。
 
 

 
 

 
 

 
 

 
 

 Layer)层主要也就是基于AT命令的操作，如发命令response解析等。（gprs等传输会用到的MUX协议等在这里并没有包含也暂不作介 绍。）
　　以下是详细分析本文主要涉及基本架构和初始化的内容：
　　首先介绍一下rild与libril.so以及librefrence_ril.so的关系：
　　1. rild：
　　仅实現一main函数作为整个ril层的入口点，负责完成初始化
　　2. libril.so：
　 　与rild结合相当紧密，是其共享库编译时就已经建立了这一关系。组成部分为ril.cppril_event.cpp。libril.so驻留在 rild这一守护进程中主要完成同上层通信的工作，接受ril请求并传递给librefrence_ril.so 同时把来自librefrence_ril.so的反馈回传给调用进程。
　　3. librefrence_ril.so：
　 　rild通过手动嘚dlopen方式加载结合稍微松散，这也是因为librefrence.so主要负责跟Modem硬件通信的缘故这样做更方便替 换或修改以适配更多的Modem种类。它转换来自libril.so的请求为AT命令同时监控Modem的反馈信息，并传递回libril.so在初 始化时， rild通过符号RIL_Init获取一组函数指针并以此与之建立联系
4. radiooptions：
　　radiooptiongs通过获取启动参数， 利用socket與rild通信可供调试时配置Modem参数。
 
 

 ril_event_loop能通过一个多路复用I/O的机制（select）来等待这些fd 如果任何一个fd有数据写入，则进入分析流程processTimeouts()processReadReadies(&rfds, n)，firePending() 后文会详細分析这些流程。
　　另外我们可以看到 在进入ril_event_loop之前， 已经挂入了一s_wakeupfd_event 通过pipe的机制实现的， 这个event的目的是可以在一些情况下能内部唤醒ril_event_loop的多路复用阻塞，比如一些带timeout的命令timeout到期的 时候
　　至此第一个任务分析完毕，这样便建立起了基于event队列的消息循环稍后便可以接受上层发来的的请求了（上层请求的event对象建立，在第三个任务中）
　　接下来看第二个任务，这个任务的入口是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命令都是以rn或nr的换行符来作为分隔符的所以readerLoop是line驱动的，除非出错超时等，否则会讀到一行完整的响应或主动上 报才会返回。这个循环跑起来以后我们基本的AT响应机制已经建立了起来。它的具体分析包括at_open中挂接的ATUnsolHandler, 峩们都放到后面分析response的连载文章里去。
　　有了响应的机制（当然能与硬件通信也已经可以发请求了），通过 RIL_requestTimedCallback(initializeCallback, NULL, &TIMEVAL_0)跑到initializeCallback中，执行一些Modem的初始化命令主要都是AT命令的方式。发AT命令的
 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 
 

 到这里,request的详细流程,就分析完毕了.
 
 

 
 

 
 

 
 

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