android通话模块详解

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

Andriod Phone模块相关（一）
2010-01-30 14:52
第一部分：从java端发送at命令的处理流程。
拨出电话流程：
1、Contacts的AndroidManifest.xml 中android:process="android.process.acore"说明此应用程序运行在acore进程中。
DialtactsActivity的intent-filter的action属性设置为main，catelog属性设置为launcher，所以此activity能出现在主菜单中，并且是点击此应用程序的第一个界面。dialtactsactivity包含四个tab，分别由TwelveKeyDialer、RecentCallsListActivity，两个activity-alias DialtactsContactsEntryActivity和DialtactsFavoritesEntryActivity分别表示联系人和收藏tab，但是正真的联系人列表和收藏是由ContactsListActivity负责。
2、进入TwelveKeyDialer 中OnClick方法，按住的按钮id为：R.id.dialButton，执行placecall()方法：
Intent intent = new Intent(Intent.ACTION_CALL_PRIVILEGED,Uri.fromParts("tel", number, null));
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
3、intert.ACTION_CALL_PRIVILEGED实际字符串为android.intent.action.CALL_PRIVILEGED，通过查找知道了packegs/phone下面的AndroidManifest.xml中PrivilegedOutgoingCallBroadcaster activity-alias设置了intent-filter，所以需要找到其targetactivity为OutgoingCallBroadcaster。所以进入OutgoingCallBroadcaster的onCreate（）中：
String action = intent.getAction();
String number = PhoneNumberUtils.getNumberFromIntent(intent, this);
if (number != null) {
number = PhoneNumberUtils.convertKeypadLettersToDigits(number);
number = PhoneNumberUtils.stripSeparators(number);
}
final boolean emergencyNumber =
(number != null) && PhoneNumberUtils.isEmergencyNumber(number);
获取过来的Action以及Number，并对Action以及Number类型进行判断。
//如果为callNow = true；则启动InCall界面：
intent.setClass(this, InCallScreen.class);
startActivity(intent);
并发送广播给OutgoingCallReceiver：
Intent broadcastIntent = new Intent(Intent.ACTION_NEW_OUTGOING_CALL);
if (number != null) broadcastIntent.putExtra(Intent.EXTRA_PHONE_NUMBER, number);
broadcastIntent.putExtra(EXTRA_ALREADY_CALLED, callNow);
broadcastIntent.putExtra(EXTRA_ORIGINAL_URI, intent.getData().toString());
sendOrderedBroadcast(broadcastIntent, PERMISSION,
new OutgoingCallReceiver(), null, Activity.RESULT_OK, number, null);
4、Intent.ACTION_NEW_OUTGOING_CALL实际字符串android.intent.action.NEW_OUTGOING_CALL，通过查找知道了packegs/phone下面的androidmanifest.xml中OutgoingCallReceiver Receiver接收此intent消息。找到OutgoingCallBroadcaster类中的内部类OutgoingCallReceiver，执行onReceive()函数：
执行doReceive(context, intent);方法：
获取传给来的号码，根据PhoneApp的实例获取PhoneType等。最后启动InCall界面：
Intent newIntent = new Intent(Intent.ACTION_CALL, uri);
newIntent.putExtra(Intent.EXTRA_PHONE_NUMBER, number);
newIntent.setClass(context, InCallScreen.class);
newIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
5、请求拨号的java部分流程

6、请求拨号的c/c++部分流程
6.1、初始化事件循环，启动串口监听，注册socket监听。
rild.c->main()
(1)、RIL_startEventLoop
//建立事件循环线程
ret = pthread_create(&s_tid_dispatch, &attr, eventLoop, NULL);
//注册进程唤醒事件回调
ril_event_set (&s_wakeupfd_event, s_fdWakeupRead, true,
processWakeupCallback, NULL);
rilEventAddWakeup (&s_wakeupfd_event);
//建立事件循环
ril_event_loop
for (;;) {
...
n = select(nfds, &rfds, NULL, NULL, ptv);
// Check for timeouts
processTimeouts();
// Check for read-ready
processReadReadies(&rfds, n);
// Fire away
firePending();
}
(2)、funcs = rilInit(&s_rilEnv, argc, rilArgv);//实际是通过动态加载动态库的方式执行reference-ril.c中的RIL_Init
//单独启动一个线程读取串口数据
ret = pthread_create(&s_tid_mainloop, &attr, mainLoop, NULL);
fd = open (s_device_path, O_RDWR);
ret = at_open(fd, onUnsolicited);
ret = pthread_create(&s_tid_reader, &attr, readerLoop, &attr);
RIL_requestTimedCallback(initializeCallback, NULL, &TIMEVAL_0);

在initializeCallback中执行的程序：
setRadioState (RADIO_STATE_OFF);
at_handshake();
/* note: we don't check errors here. Everything important will
be handled in onATTimeout and onATReaderClosed */
/* atchannel is tolerant of echo but it must */
/* have verbose result codes */
at_send_command("ATE0Q0V1", NULL);
/* No auto-answer */
at_send_command("ATS0=0", NULL);
...
//注册rild socket端口事件监听到事件循环中
(3)、RIL_register(funcs);
s_fdListen = android_get_control_socket(SOCKET_NAME_RIL);
ret = listen(s_fdListen, 4);
ril_event_set (&s_listen_event, s_fdListen, false,
listenCallback, NULL);//将此端口加入事件select队列
rilEventAddWakeup (&s_listen_event);

如果rild socket端口有数据来了将执行listencallback函数
listencallback
//为此客户端连接创建新的监听句柄，s_fdListen继续监听其他客户端的连接。
s_fdCommand = accept(s_fdListen, (sockaddr *) &peeraddr, &socklen);
ril_event_set (&s_commands_event, s_fdCommand, 1,
processCommandsCallback, p_rs);//将此端口加入事件select队列
rilEventAddWakeup (&s_commands_event);
6.2、socket监听，收到dial的socket请求
processCommandsCallback
//读数据到p_record中
ret = record_stream_get_next(p_rs, &p_record, &recordlen);
processCommandBuffer(p_record, recordlen);
p.setData((uint8_t *) buffer, buflen);
// status checked at end
status = p.readInt32(&request);
status = p.readInt32 (&token);//请求队列中的序号
pRI = (RequestInfo *)calloc(1, sizeof(RequestInfo));
pRI->token = token;

/*
包含#include "ril_commands.h"语句，结构体如下：
typedef struct {
int requestNumber;
void (*dispatchFunction) (Parcel &p, struct RequestInfo *pRI);
int(*responseFunction) (Parcel &p, void *response, size_t responselen);
} CommandInfo;
*/
pRI->pCI = &(s_commands[request]);
pRI->p_next = s_pendingRequests;
s_pendingRequests = pRI;
pRI->pCI->dispatchFunction(p, pRI);

//假设是接收了dial指令,pRI->PCI->dispatchFunction(p,pRI)，调用dispatchDial (p,pRI)
dispatchDial (p,pRI)
s_callbacks.onRequest(pRI->pCI->requestNumber, &dial, sizeof(dial), pRI);
in reference-ril.c onRequest()
...
switch (request) {
case RIL_REQUEST_DIAL:
requestDial(data, datalen, t);
asprintf(&cmd, "ATD%s%s;", p_dial->address, clir);
ret = at_send_command(cmd, NULL);
err = at_send_command_full (command, NO_RESULT, NULL, NULL, 0, pp_outResponse);
err = at_send_command_full_nolock(command, type, responsePrefix, smspdu,timeoutMsec, sponse);
err = writeline (command);
//此处等待，直到收到成功应答或失败的应答,如：ok,connect,error cme等
err = pthread_cond_wait(&s_commandcond, &s_commandmutex);
waiting....
waiting....

/* success or failure is ignored by the upper layer here.
it will call GET_CURRENT_CALLS and determine success that way */
RIL_onRequestComplete(t, RIL_E_SUCCESS, NULL, 0);
p.writeInt32 (RESPONSE_SOLICITED);
p.writeInt32 (pRI->token);
errorOffset = p.dataPosition();
p.writeInt32 (e);
if (e == RIL_E_SUCCESS) {
/* process response on success */
ret = pRI->pCI->responseFunction(p, response, responselen);
if (ret != 0) {
p.setDataPosition(errorOffset);
p.writeInt32 (ret);
}
}
sendResponse(p);
sendResponseRaw(p.data(), p.dataSize());
blockingWrite(fd, (void *)&header, sizeof(header));
blockingWrite(fd, data, dataSize);
6.4、串口监听收到atd命令的应答"OK"或"no carrier"等
readerLoop()
line = readline();
processLine(line);
handleFinalResponse(line);
pthread_cond_signal(&s_commandcond);//至此，前面的等待结束，接着执行RIL_onRequestComplete函数
6.5、java层收到应答后的处理,以dial为例子.
ril.java->RILReceiver.run()
for(;;)
{
...
length = readRilMessage(is, buffer);
p = Parcel.obtain();
p.unmarshall(buffer, 0, length);
p.setDataPosition(0);
processResponse(p);
type = p.readInt();
if (type == RESPONSE_SOLICITED) {
processSolicited (p);
serial = p.readInt();
rr = findAndRemoveRequestFromList(serial);
rr.mResult.sendToTarget();
......
}
CallTracker.java->handleMessage (Message msg)
switch (msg.what) {
case EVENT_OPERATION_COMPLETE:
ar = (AsyncResult)msg.obj;
operationComplete();
cm.getCurrentCalls(lastRelevantPoll);

Andriod Phone模块相关（二）
2010-01-30 15:09
第二部分：unsolicited 消息从modem上报到java的流程。
C++部分：
readerLoop()
line = readline();
processLine(line);
handleUnsolicited(line);
if (s_unsolHandler != NULL) {
s_unsolHandler (line1, line2);//实际执行的是void onUnsolicited (const char *s, const char *sms_pdu)
if (strStartsWith(s,"+CRING:")|| strStartsWith(s,"RING")
|| strStartsWith(s,"NO CARRIER") || strStartsWith(s,"+CCWA") )
RIL_onUnsolicitedResponse (RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED, NULL, 0);
p.writeInt32 (RESPONSE_UNSOLICITED);
p.writeInt32 (unsolResponse);
ret = s_unsolResponses[unsolResponseIndex].responseFunction(p, data, datalen);
ret = sendResponse(p);
sendResponseRaw(p.data(), p.dataSize());
ret = blockingWrite(fd, (void *)&header, sizeof(header));
blockingWrite(fd, data, dataSize);
Java部分：
ril.java->RILReceiver.run()
for(;;)
{
...
length = readRilMessage(is, buffer);
p = Parcel.obtain();
p.unmarshall(buffer, 0, length);
p.setDataPosition(0);
processResponse(p);
processUnsolicited (p);
response = p.readInt();
switch(response) {
...
case RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED: ret = responseVoid(p); break;
...
}
switch(response) {
case RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED:
if (RILJ_LOGD) unsljLog(response)；
mCallStateRegistrants
.notifyRegistrants(new AsyncResult(null, null, null))；
...
}

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

B.事件通知部分

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

手机SIM卡功能解析
2010-02-01 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卡。如果擦拭后仍无法正常使用，则应将手机连卡送到专业维修点，让维修人员检查。

 

Android Phone分析（一）
2010-01-27 17:45
Android的Radio Interface Layer (RIL)提供了电话服务和的radio硬件之间的抽象层。
Radio Interface Layer RIL(Radio Interface Layer)负责数据的可靠传输、AT命令的发送以及response的解析。应用处理器通过AT命令集与带GPRS功能的无线通讯模块通信。
AT command由Hayes公司发明，是一个调制解调器制造商采用的一个调制解调器命令语言，每条命令以字母"AT"开头。

JAVA Framework
代码的路径为：
frameworks/base/telephony/java/android/telephony
android.telephony以及android.telephony.gsm

Core native:
在hardware/ril目录中，提供了对RIL支持的本地代码，包括4个文件夹：
hardware/ril/include
hardware/ril/libril
hardware/ril/reference-ril
hardware/ril/rild

kernel Driver
在Linux内核的驱动中，提供了相关的驱动程序的支持，可以建立在UART或者SDIO，USB等高速的串行总线上。
hardware/ril/include/telephony/目录中的ril.h文件是ril部分的基础头文件。
其中定义的结构体RIL_RadioFunctions如下所示：
typedef struct {
int version;
RIL_RequestFunc onRequest;
RIL_RadioStateRequest onStateRequest;
RIL_Supports supports;
RIL_Cancel onCancel;
RIL_GetVersion getVersion;
} RIL_RadioFunctions;
RIL_RadioFunctions中包含了几个函数指针的结构体，这实际上是一个移植层的接口，下层的库实现后，由rild守护进程得到这些函数指针，执行对应的函数。
几个函数指针的原型为：
typedef void (*RIL_RequestFunc) (int request, void *data,
size_t datalen, RIL_Token t);
typedef RIL_RadioState (*RIL_RadioStateRequest)();
typedef int (*RIL_Supports)(int requestCode);
typedef void (*RIL_Cancel)(RIL_Token t);
typedef const char * (*RIL_GetVersion) (void);
其中最为重要的函数是onRequest()，它是一个请求执行的函数。

Android Phone分析（二）
2010-01-27 17:47
Android的RIL驱动模块， 在hardware/ril目录下，一共分rild，libril.so以及librefrence_ril.so三个部分，另有一 radiooptions可供自动或手动调试使用。都依赖于include目录中ril.h头文件。目前cupcake分支上带的是gsm的支持，另有一 cdma分支，这里分析的是gsm驱动。
GSM模块，由于Modem的历史原因，AP一直是通过基于串口的AT命令与BB交互。包括到了目前的一些edge或3g模块，或像omap这类ap,bp集成的芯片， 已经使用了USB或其他等高速总线通信，但大多仍然使用模拟串口机制来使用AT命令。这里的RIL(Radio Interface Layer)层，主要也就是基于AT命令的操作，如发命令，response解析等。（gprs等传输会用到的MUX协议等在这里并没有包含，也暂不作介 绍。）
　　以下是详细分析，本文主要涉及基本架构和初始化的内容：
　　首先介绍一下rild与libril.so以及librefrence_ril.so的关系：
　　1. rild：
　　仅实现一main函数作为整个ril层的入口点，负责完成初始化。
　　2. libril.so：
　 　与rild结合相当紧密，是其共享库，编译时就已经建立了这一关系。组成部分为ril.cpp，ril_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参数。

Android Phone分析（三）
2010-01-27 17:51
分析初始化流程，主入口是rild.c中的main函数，主要完成三个任务：
　　1. 开启libril.so中的event机制， 在RIL_startEventLoop中，是最核心的由多路I/O驱动的消息循环。
　　2. 初始化librefrence_ril.so，也就是跟硬件或模拟硬件modem通信的部分（后面统一称硬件）， 通过RIL_Init函数完成。
　　3. 通过RIL_Init获取一组函数指针RIL_RadioFunctions， 并通过RIL_register完成注册，并打开接受上层命令的socket通道。
　 　首先看第一个任务，也就是RIL_startEventLoop函数。RIL_startEventLoop在ril.cpp中实现， 它的主要目的是通过pthread_create(&s_tid_dispatch, &attr, eventLoop, NULL)建立一个dispatch线程，入口点在eventLoop. 而eventLoop中，会调ril_event.cpp中的ril_event_loop（）函数，建立起消息(event)队列机制。
　　我们来仔细看看这一消息队列的机制，这些代码都在ril_event.cpp中。
void ril_event_init();
void ril_event_set(struct ril_event * ev, int fd, bool persist, ril_event_cb func, void * param);
void ril_event_add(struct ril_event * ev);
void ril_timer_add(struct ril_event * ev, struct timeval * tv);
void ril_event_del(struct ril_event * ev);
void ril_event_loop();
struct ril_event {
struct ril_event *next;
struct ril_event *prev;
int fd;
int index;
bool persist;
struct timeval timeout;
ril_event_cb func;
void *param;
};
　　每个ril_event结构，与一个fd句柄绑定（可以是文件，socket，管道等），并且带一个func指针去执行指定的操作。
　 　具体流程是： ril_event_init完成后，通过ril_event_set来配置一新ril_event，并通过ril_event_add加入队列之中（实 际通常用rilEventAddWakeup来添加），add会把队列里所有ril_event的fd，放入一个fd集合readFds中。这样 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的连载文章里。这里可以看到，主要是一些参数配置，以及网络状态的检查等。至此第二个任务分析完毕，硬件已经可以访 问了。
　　最后是第三个任务。第三个任务是由RIL_Init的返回值开始的，这是一个RIL_RadioFunctions结构的指针。
typedef struct {
int version;　　　　　　　　/* set to RIL_VERSION */
RIL_RequestFunc onRequest;
RIL_RadioStateRequest onStateRequest;
RIL_Supports supports;
RIL_Cancel onCancel;
RIL_GetVersion getVersion;
} RIL_RadioFunctions;
　　其中最重要的是onRequest域，上层来的请求都由这个函数进行映射后转换成对应的AT命令发给硬件。
　　rild通过RIL_register注册这一指针。
　　RIL_register中要完成的另外一个任务，就是打开前面提到的跟上层通信的socket接口（s_fdListen是主接口，s_fdDebug供调试时使用）。
　　然后将这两个socket接口使用任务一中实现的机制进行注册（仅列出s_fdListen）
ril_event_set (&s_listen_event, s_fdListen, false,
listenCallback, NULL);
rilEventAddWakeup (&s_listen_event);
　　这样将两个socket加到任务一中建立起来多路复用I/O的检查句柄集合中，一旦有上层来的（调试）请求，event机制便能响应处理了。到这里启动流程已经分析完毕。
Android Phone分析（四）
2010-01-27 17:52
request流程
1. 多路复用I/O机制的运转
上文说到request是接收,是通过ril_event_loop中的多路复用I/O,也对初始化做了分析.现在我们来仔细看看这个机制如何运转.
ril_event_set负责配置一个event,主要有两种event：
ril_event_add添加使用多路I/O的event,它负责将其挂到队列,同时将event的通道句柄fd加入到watch_table,然后通过select等待.
ril_timer_add添加timer event,它将其挂在队列,同时重新计算最短超时时间.
无论哪种add,最后都会调用triggerEvLoop来刷新队列,更新超时值或等待对象.

刷新之后, ril_event_loop从阻塞的位置,select返回,只有两种可能,一是超时,二是等待到了某I/O操作.
超时的处理在processTimeouts中,摘下超时的event,加入pending_list.
检查有I/O操作的通道的处理在processReadReadies中,将超时的event加入pending_list.
最后在firePending中,检索pending_list的event并依次执行event->func.
这些操作完之后,计算新超时时间,并重新select阻塞于多路I/O.

前面的初始化流程已分析得知,初始化完成以后,队列上挂了3个event对象,分别是：
s_listen_event: 名为rild的socket,主要requeset & response通道
s_debug_event: 名为rild-debug的socket,调试用requeset & response通道（流程与s_listen_event基本相同,后面仅分析s_listen_event）
s_wakeupfd_event: 无名管道,用于队列主动唤醒（前面提到的队列刷新,就用它来实现,请参考使用它的相关地方）

2. request的传入和dispatch
明白了event队列的基本运行流程,我们可以来看看request是怎么传入和dispatch的了.
上 层的部分,核心代码在frameworks/base/telephony/java/com/android/internal/telephony /gsm/RIL.java,这是android java框架处理radio(gsm)的核心组件.本文因为主要关注rild,也就是驱动部分,所以这里只作简单介绍.
我们看一个具体的例子,RIL.java中的dial函数：
public void
dial (String address, int clirMode, Message result)
{
RILRequest rr = RILRequest.obtain(RIL_REQUEST_DIAL, result);

rr.mp.writeString(address);
rr.mp.writeInt(clirMode);

if (RILJ_LOGD) riljLog(rr.serialString() + "> " + requestToString(rr.mRequest));

send(rr);
}
rr是以RIL_REQUEST_DIAL为request号而申请的一个RILRequest对象.这个request号在java框架和rild库中共享（参考RILConstants.java中这些值的由来:)）
RILRequest初始化的时候,会连接名为rild的socket（也就是rild中s_listen_event绑定的socket）,初始化数据传输的通道.
rr.mp 是Parcel对象,Parcel是一套简单的序列化协议,用于将对象（或对象的成员）序列化成字节流,以供传递参数之用.这里可以看到String address和int clirMode都是将依次序列化的成员.在这之前,rr初始化的时候,request号跟request的序列号（自动生成的递增数）,已经成为头两个 将被序列化的成员.这为后面的request解析打下了基础.
接下来是send到handleMessage的流程,send将rr直接传递给另 一个线程的handleMessage,handleMessage执行data = rr.mp.marshall()执行序列化操作, 并将data字节流写入到rild socket.

接下来回到我们的rild,select发现rild socket有了请求链接的信号,导致s_listen_event被挂入pending_list,执行event->func,即
static void listenCallback (int fd, short flags, void *param);
接下来,s_fdCommand = accept(s_fdListen, (sockaddr *) &peeraddr, &socklen),获取传入的socket描述符,也就是上层的java RIL传入的连接.
然 后,通过record_stream_new建立起一个record_stream, 将其与s_fdCommand绑定, 这里我们不关注record_stream 的具体流程, 我们来关注command event的回调, processCommandsCallback函数, 从前面的event机制分析, 一旦s_fdCommand上有数据, 此回调函数就会被调用. （略过onNewCommandConnect的分析）
processCommandsCallback通过 record_stream_get_next阻塞读取s_fdCommand上发来的 数据, 直到收到一完整的request(request包的完整性由record_stream的机制保证), 然后将其送达processCommandBuffer.
进入processCommandBuffer以后,我们就正式进入了命令的解析部分. 每个命令将以RequestInfo的形式存在.
typedef struct RequestInfo {
int32_t token; //this is not RIL_Token
CommandInfo *pCI;
struct RequestInfo *p_next;
char cancelled;
char local; // responses to local commands do not go back to command process
} RequestInfo;
这 里的pRI就是一个RequestInfo结构指针, 从socket过来的数据流, 前面提到是Parcel处理过的序列化字节流, 这里会通过反序列化的方法提取出来. 最前面的是request号, 以及token域(request的递增序列号). 我们更关注这个request号, 前面提到, 上层和rild之间, 这个号是统一的. 它的定义是一个包含ril_commands.h的枚举, 在ril.cpp中
static CommandInfo s_commands[] = {
#include "ril_commands.h"
};
pRI直接访问这个数组, 来获取自己的pCI.
这是一个CommandInfo结构:
typedef struct {
int requestNumber;
void (*dispatchFunction) (Parcel &p, struct RequestInfo *pRI);
int(*responseFunction) (Parcel &p, void *response, size_t responselen);
} CommandInfo;
基本解析到这里就完成了, 接下来, pRI被挂入pending的request队列, 执行具体的pCI->dispatchFunction, 进行详细解析.

3. request的详细解析
对dial而言, CommandInfo结构是这样初始化的:
{RIL_REQUEST_DIAL, dispatchDial, responseVoid},
这 里执行dispatchFunction, 也就是dispatchDial这一函数.我们可以看到其实有很多种类的dispatch function, 比如dispatchVoid, dispatchStrings, dispatchSIM_IO等等, 这些函数的区别, 在于Parcel传入的参数形式,Void就是不带参数的,Strings是以string[]做参数,又如Dial等,有自己的参数解析方式,以此类 推.
request号和参数现在都有了,那么可以进行具体的request函数调用了.
s_callbacks.onRequest(pRI->pCI->requestNumber, xxx, len, pRI)完成这一操作.
s_callbacks 是上篇文章中提到的获取自libreference-ril的RIL_RadioFunctions结构指针,request请求在这里转入底层的 libreference-ril处理,handler是reference-ril.c中的onRequest.
onRequest进行一个简单的switch分发,我们依然来看RIL_REQUEST_DIAL
流程是 onRequest-->requestDial-->at_send_command-->at_send_command_full-->at_send_command_full_nolock-->writeline
requestDial中将命令和参数转换成对应的AT命令,调用公共send command接口at_send_command.
除 了这个接口之外,还有 at_send_command_singleline,at_send_command_sms,at_send_command_multiline 等,这是根据at返回值,以及发命令流程的类型来区别的.比如at+csq这类,需要at_send_command_singleline,而发送短 信,因为有prompt提示符">",传裸数据,结束符等一系列操作,需要专门用at_send_command_sms来实现.
然后执行at_send_command_full,前面几个接口都会最终到这里,再通过一个互斥的at_send_command_full_nolock调用,然后完成最终的写出操作,在writeline中,写出到初始化时打开的设备中.
writeline返回之后,还有一些操作,如保存type等信息,供response回来时候使用,以及一些超时处理. 不再详述.

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

Android Phone分析（五）
2010-01-27 17:53
response流程
前文对request的分析， 终止在了at_send_command_full_nolock里的writeline操作，因为这里完成命令写出到硬件设备的操作，接下来就是等待硬件响应，也就是response的过程了。我们的分析也是从这里开始。
response信息的获取，是在第一篇初始化分析中，提到的readerLoop中。由readline函数以‘行'为单位接收上来。
AT的response有两种，一是主动上报的，比如网络状态，短信，来电等都不需要经过请求，有一unsolicited词语专门描述。另一种才是真正意义上的response，也就是命令的响应。
这 里我们可以看到，所有的行，首先经过sms的自动上报筛选，因为短信的AT处理通常比较麻烦，无论收发都单独列出。这里是因为要即时处理这条短信消息（两 行，标志＋pdu），而不能拆开处理。处理函数为onUnsolicited（由s_unsolHandler指向），我们等下介绍。
除开sms的特例，所有的line都要经过processLine，我们来看看这个流程：
processLine
|----no cmd--->handleUnsolicited //主动上报
|----isFinalResponseSuccess--->handleFinalResponse //成功,标准响应
|----isFinalResponseError--->handleFinalResponse //失败，标准响应
|----get '>'--->send sms pdu //收到>符号，发送sms数据再继续等待响应
|----switch s_type--->具体响应 //命令有具体的响应信息需要对应分析

我 们这里主要关注handleUnsolicited自动上报（会调用到前面smsUnsolicite也调用的onUnsolicite），以及 switch s_type具体响应信息，另外具体响应需要handleFinalResponse这样的标准响应来最终完成。
1. onUnsolicite（主动上报响应）
static void onUnsolicited (const char *s, const char *sms_pdu)；
短信的AT设计真是麻烦的主，以致这个函数的第二个参数完全就是为它准备的。
response 的主要的解析过程，由at_tok.c中的函数完成，其实就是字符串按块解析，具体的解析方式由每条命令或上报信息自行决定。这里不再详 述，onUnsolicited只解析出头部(一般是+XXXX的形式)，然后按类型决定下一步操作，操作为 RIL_onUnsolicitedResponse和RIL_requestTimedCallback两种。
a)RIL_onUnsolicitedResponse：
将 unsolicited的信息直接返回给上层。通过Parcel传递，将 RESPONSE_UNSOLICITED，unsolResponse（request号）写入Parcel先，然后通过 s_unsolResponses数组，查找到对应的responseFunction完成进一步的的解析，存入Parcel中。最终通过 sendResponse将其传递回原进程。流程：
sendResponse-->sendResponseRaw-->blockingWrite-->write to s_fdCommand(前面建立起来的和上层框架的socket连接)
这些步骤之后有一些唤醒系统等其他操作。不再详述。
b)RIL_requestTimedCallback：
通 过event机制（参考文章二）实现的timer机制，回调对应的内部处理函数。通过internalRequestTimedCallback将回调添 加到event循环，最终完成callback上挂的函数的回调。比如pollSIMState，onPDPContextListChanged等回 调， 不用返回上层， 内部处理就可以。

2. switch s_type（命令的具体响应）及handleFinalResponse（标准响应）
命 令的类型（s_type）在send command的时候设置（参考文章二），有NO_RESULT，NUMERIC，SINGLELINE，MULTILINE几种，供不同的AT使用。比 如AT+CSQ是singleline, 返回at+csq=xx,xx，再加一行OK，比如一些设置命令，就是no_result, 只有一行OK或ERROR。
这几个类型的解析都很相仿，通过一定的判断（比较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部分，也就告一段落了。

Android Parcel理解
2010-01-30 12:44
android 中Parcel 的使用，他是一个存储基本数据类型和引用数据类型的容器，在andorid 中通过IBinder来绑定数据在进程间传递数据。
Parcel parcel = Parcel.obtain();// 获取一个Parcel 对象
下面就可以对其进行方法进行操作了，createXXX(),wirteXXX(),readXXX(),
其中dataPosition(),返回当前Parcel 当前对象存储数据的偏移量，而setDataPosition(),设置当前Parcel 对象的偏移量，方便读取parcel 中的数据，可问题就出在我读取出来的数据要么是空（null）,要么永远是第一个偏移量处的值，存储和读取数据的。Parcel采用什么机制实现的，是以什么形式的存储的，然后我才能任意对其操作，读取目标数据。
基本数据类型的取值范围，
boolean 1bit
short 16bit
int 32bit
long 64bit
float 32bit
double 64bit
char 16bit
byte 8bit
由此我可以猜想，Parcel 32bit 作为基本单位存储写入的变量,4byte*8=32bit,在内存中的引用地址变量是采用16进制进行编码，且作为偏移量，即偏移量是4的倍数，0,4,8,12,16,20,24,28,32,36,40,44,48......4*N,
f(x) = 4*y｛y>=0&y是自然数｝
我想绝对不会出现向偏移量是3，6，9这样的数据。。。
由此我们可以推断出，无论他存储的是基本数据类型或引用数据类型的变量，都是以32bit基本单位作为偏移量，
parcel.writeInt(1);
parcel.writeInt(2);
parcel.writeInt(3);
parcel.writeInt(4);
parcel.writeInt(5);
parcel.writeInt(6);
parcel.writeInt(7);
parcel.writeInt(81011111);
parcel.writeFloat(1f);
parcel.writeFloat(1000000000000000000000000000000000000f);

parcel.writeXXX(),每写一次数据，在32bit的空间里能够存储要放入的变量，怎只占一个偏移量，也就之一动4个位置，而当存储的数据如 parcel.writeFloat(1000000000000000000000000000000000000f);他就自动往后移动，
parcel.writeString("a");
parcel.writeString("b");
parcel.writeString("d");
parcel.writeString("c");
和
parcel.writeString("abcd"); 的区别。有此可见，他的内存的分配原来是这样的。
那我怎样才能把我存进去的书据依次的去出来呢？setDataPosition(),设置parcel 的偏移量，在readXXX(),读取数据
int size = parcel.dataSize();
int i = 0;
while (i <= size ) {
parcel.setDataPosition(i);
int curr_int = parcel.readInt();
i+=4;
int j = 0;
j++;
}
由此可见parcel 写入数据是按照32bit 为基本的容器，依次存储写入的数据，基本和引用（其实引用的也是有多个基本数据类型组合而成OBJECTS－属性｜方法），读取的时候我们就可以按照这种规律根据目标数据的偏移量的位置（curr_position），以及偏移量的大小(size)，,取出已经存进去的数据了
int i ＝ curr_position；
while (i <= size ) {
parcel.setDataPosition(i);
int curr_int = parcel.readXXXt();
i+=4;
int j = 0;
j++;
}
这样就ok 了
他的createXXX（）方法现在没用，用了在说吧！
总结一句话，java 中 基本数据类型的取值范围，引用类型的数据，相当于c中的指针，以及各进制之间的相互转换和灵活的引用，以及定制自己想要的任意进制数据类型。

Android中Message机制的灵活应用（一）
2010-02-02 11:10
转载请注明来自easyandroid论坛
活用Android线程间通信的Message机制
1.1.Message
代码在frameworks/base/core/java/android/Os/Message.java中。
Message.obtain函数：有多个obtain函数，主要功能一样，只是参数不一样。作用是从Message Pool中取出一个Message，如果Message Pool中已经没有Message可取则新建一个Message返回，同时用对应的参数给得到的Message对象赋值。
Message Pool：大小为10个；通过Message.mPool->（Message并且Message.next）-> （Message并且Message.next）-> （Message并且Message.next）...构造一个Message Pool。Message Pool的第一个元素直接new出来，然后把Message.mPool（static类的static变量）指向它。其他的元素都是使用完的Message通过Message的recycle函数清理后放到Message Pool（通过Message Pool最后一个Message的next指向需要回收的Message的方式实现）。下图为Message Pool的结构：

1.2.MessageQueue
MessageQueue里面有一个收到的Message的对列：
MessageQueue.mMessages(static变量)->( Message并且Message.next)-> ( Message并且Message.next)->...，下图为接收消息的消息队列：

上层代码通过Handler的sendMessage等函数放入一个message到MessageQueue里面时最终会调用MessageQueue的enqueueMessage函数。enqueueMessage根据上面的接收的Message的队列的构造把接收到的Message放入队列中。
MessageQueue的removeMessages函数根据上面的接收的Message的队列的构造把接收到的Message从队列中删除，并且调用对应Message对象的recycle函数把不用的Message放入Message Pool中。
1.3.Looper
Looper对象的创建是通过prepare函数，而且每一个Looper对象会和一个线程关联
public static final void prepare() {

if (sThreadLocal.get() != null) {

throw new RuntimeException("Only one Looper may be created per thread");

}

sThreadLocal.set(new Looper());
}
Looper对象创建时会创建一个MessageQueue，主线程默认会创建一个Looper从而有MessageQueue，其他线程默认是没有MessageQueue的不能接收Message，如果需要接收Message则需要通过prepare函数创建一个MessageQueue。具体操作请见示例代码。
private Looper() {

mQueue = new MessageQueue();

mRun = true;

mThread = Thread.currentThread();
}
prepareMainLooper函数只给主线程调用（系统处理，程序员不用处理），它会调用prepare建立Looper对象和MessageQueue。
public static final void prepareMainLooper() {
prepare();
setMainLooper(myLooper());
if (Process.supportsProcesses()) {

myLooper().mQueue.mQuitAllowed = false;
}
}
Loop函数从MessageQueue中从前往后取出Message，然后通过Handler的dispatchMessage函数进行消息的处理（可见消息的处理是Handler负责的），消息处理完了以后通过Message对象的recycle函数放到Message Pool中，以便下次使用，通过Pool的处理提供了一定的内存管理从而加速消息对象的获取。至于需要定时处理的消息如何做到定时处理，请见MessageQueue的next函数，它在取Message来进行处理时通过判断MessageQueue里面的Message是否符合时间要求来决定是否需要把Message取出来做处理，通过这种方式做到消息的定时处理。
public static final void loop() {
Looper me = myLooper();
MessageQueue queue = me.mQueue;
while (true) {
Message msg = queue.next(); // might block
//if (!me.mRun) {
//
break;
//}
if (msg != null) {
if (msg.target == null) {
// No target is a magic identifier for the quit message.
return;
}
if (me.mLogging!= null) me.mLogging.println(
">>>>> Dispatching to " + msg.target + " "
+ msg.callback + ": " + msg.what

);
msg.target.dispatchMessage(msg);
if (me.mLogging!= null) me.mLogging.println(
"<<<<< Finished to
" + msg.target + " "
+ msg.callback);
msg.recycle();
}
}
}
1.4.Handler
Handler的构造函数表示Handler会有成员变量指向Looper和MessageQueue，后面我们会看到没什么需要这些引用；至于callback是实现了Callback接口的对象，后面会看到这个对象的作用。
public Handler(Looper looper, Callback callback) {
mLooper = looper;
mQueue = looper.mQueue;
mCallback = callback;
}
public interface Callback {

public boolean handleMessage(Message msg);
}
获取消息：直接通过Message的obtain方法获取一个Message对象。
public final Message obtainMessage(int what, int arg1, int arg2, Object obj)
{
return Message.obtain(this, what, arg1, arg2, obj);
}
发送消息：通过MessageQueue的enqueueMessage把Message对象放到MessageQueue的接收消息队列中
public boolean sendMessageAtTime(Message msg, long uptimeMillis)
{
boolean sent = false;
MessageQueue queue = mQueue;
if (queue != null) {
msg.target = this;
sent = queue.enqueueMessage(msg, uptimeMillis);
}
else {
RuntimeException e = new RuntimeException(
this + " sendMessageAtTime() called with no mQueue");
Log.w("Looper", e.getMessage(), e);
}
return sent;
}
线程如何处理MessageQueue中接收的消息：在Looper的loop函数中循环取出MessageQueue的接收消息队列中的消息，然后调用Hander的dispatchMessage函数对消息进行处理，至于如何处理（相应消息）则由用户指定（三个方法，优先级从高到低：Message里面的Callback，一个实现了Runnable接口的对象，其中run函数做处理工作；Handler里面的mCallback指向的一个实现了Callback接口的对象，里面的handleMessage进行处理；处理消息Handler对象对应的类继承并实现了其中handleMessage函数，通过这个实现的handleMessage函数处理消息）。
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
Runnable说明：Runnable只是一个接口，实现了这个接口的类对应的对象也只是个普通的对象，并不是一个Java中的Thread。Thread类经常使用Runnable，很多人有误解，所以这里澄清一下。
从上可知以下关系图：

其中清理Message是Looper里面的loop函数指把处理过的Message放到Message的Pool里面去，如果里面已经超过最大值10个，则丢弃这个Message对象。
调用Handler是指Looper里面的loop函数从MessageQueue的接收消息队列里面取出消息，然后根据消息指向的Handler对象调用其对应的处理方法。

Android中Message机制的灵活应用（二）
2010-02-02 11:44
1.5.代码示例
下面我们会以android实例来展示对应的功能，程序界面于下：

程序代码如下，后面部分有代码说明：

说明（代码详细解释请见后文）：
1.
2. package com.android.messageexample;
3. import android.app.Activity;
4. import android.content.Context;
5. import android.graphics.Color;
6. import android.os.Bundle;
7. import android.os.Handler;
8. import android.os.Looper;
9. import android.os.Message;
10. import android.util.Log;
11. import android.view.View;
12. import android.view.View.OnClickListener;
13. import android.widget.Button;
14. import android.widget.LinearLayout;
15. import android.widget.TextView;
16. public class MessageExample extends Activity implements OnClickListener {
17. private final int WC = LinearLayout.LayoutParams.WRAP_CONTENT;
18. private final int FP = LinearLayout.LayoutParams.FILL_PARENT;
19. public TextView tv;
20. private EventHandler mHandler;
21. private Handler mOtherThreadHandler=null;
22. private Button btn, btn2, btn3, btn4, btn5, btn6;
23. private NoLooperThread noLooerThread = null;
24. private OwnLooperThread ownLooperThread = null;
25. private ReceiveMessageThread receiveMessageThread =null;
26. private Context context = null;
27. private final String sTag = "MessageExample";
28. private boolean postRunnable = false;
29.
30. /** Called when the activity is first created. */
31. @Override
32. public void onCreate(Bundle savedInstanceState) {
33. super.onCreate(savedInstanceState);
34. context = this.getApplicationContext();
35. LinearLayout layout = new LinearLayout(this);
36. layout.setOrientation(LinearLayout.VERTICAL);
37. btn = new Button(this);
38. btn.setId(101);
39. btn.setText("message from main thread self");
40. btn.setOnClickListener(this);
41. LinearLayout.LayoutParams param =
42. new LinearLayout.LayoutParams(250,50);
43. param.topMargin = 10;
44. layout.addView(btn, param);
45. btn2 = new Button(this);
46. btn2.setId(102);
47. btn2.setText("message from other thread to main thread");
48. btn2.setOnClickListener(this);
49. layout.addView(btn2, param);
50. btn3 = new Button(this);
51. btn3.setId(103);
52. btn3.setText("message to other thread from itself");
53. btn3.setOnClickListener(this);
54. layout.addView(btn3, param);
55. btn4 = new Button(this);
56. btn4.setId(104);
57. btn4.setText("message with Runnable as callback from other thread to main thread");
58. btn4.setOnClickListener(this);
59. layout.addView(btn4, param);
60. btn5 = new Button(this);
61. btn5.setId(105);
62. btn5.setText("main thread's message to other thread");
63. btn5.setOnClickListener(this);
64. layout.addView(btn5, param);
65. btn6 = new Button(this);
66. btn6.setId(106);
67. btn6.setText("exit");
68. btn6.setOnClickListener(this);
69. layout.addView(btn6, param);
70. tv = new TextView(this);
71. tv.setTextColor(Color.WHITE);
72. tv.setText("");
73. LinearLayout.LayoutParams param2 =
74. new LinearLayout.LayoutParams(FP, WC);
75. param2.topMargin = 10;
76. layout.addView(tv, param2);
77. setContentView(layout);
78.
79. //主线程要发送消息给other thread， 这里创建那个other thread
80. receiveMessageThread = new ReceiveMessageThread();
81. receiveMessageThread.start();
82. }
83.
84. //implement the OnClickListener interface
85. @Override
86. public void onClick(View v) {
87. switch(v.getId()){
88. case 101:
89. //主线程发送消息给自己
90. Looper looper;
91. looper = Looper.myLooper(); //get the Main looper related with the main thread
92. //如果不给任何参数的话会用当前线程对应的Looper(这里就是Main Looper)为Handler里面的成员mLooper赋值
93. mHandler = new EventHandler(looper);
94. //mHandler = new EventHandler();
95. // 清除整个MessageQueue里的消息
96. mHandler.removeMessages(0);
97. String obj = "This main thread's message and received by itself!";
98. //得到Message对象
99. Message m = mHandler.obtainMessage(1, 1, 1, obj);
100. // 将Message对象送入到main thread的MessageQueue里面
101. mHandler.sendMessage(m);
102. break;
103. case 102:
104. //other线程发送消息给主线程
105. postRunnable = false;
106. noLooerThread = new NoLooperThread();
107. noLooerThread.start();
108. break;
109. case 103:
110. //other thread获取它自己发送的消息
111. tv.setText("please look at the error level log for other thread received message");
112. ownLooperThread = new OwnLooperThread();
113. ownLooperThread.start();
114. break;
115. case 104:
116. //other thread通过Post Runnable方式发送消息给主线程
117. postRunnable = true;
118. noLooerThread = new NoLooperThread();
119. noLooerThread.start();
120. break;
121. case 105:
122. //主线程发送消息给other thread
123. if(null!=mOtherThreadHandler){
124. tv.setText("please look at the error level log for other thread received message from main thread");
125. String msgObj = "message from mainThread";
126. Message mainThreadMsg = mOtherThreadHandler.obtainMessage(1, 1, 1, msgObj);
127. mOtherThreadHandler.sendMessage(mainThreadMsg);
128. }
129. break;
130. case 106:
131. finish();
132. break;
133. }
134. }
135. class EventHandler extends Handler
136. {
137. public EventHandler(Looper looper) {
138. super(looper);
139. }
140. public EventHandler() {
141. super();
142. }
143. public void handleMessage(Message msg) {
144. //可以根据msg.what执行不同的处理，这里没有这么做
145. switch(msg.what){
146. case 1:
147. tv.setText((String)msg.obj);
148. break;
149. case 2:
150. tv.setText((String)msg.obj);
151. noLooerThread.stop();
152. break;
153. case 3:
154. //不能在非主线程的线程里面更新UI，所以这里通过Log打印收到的消息
155. Log.e(sTag, (String)msg.obj);
156. ownLooperThread.stop();
157. break;
158. default:
159. //不能在非主线程的线程里面更新UI，所以这里通过Log打印收到的消息
160. Log.e(sTag, (String)msg.obj);
161. break;
162. }
163. }
164. }
165. //NoLooperThread
166. class NoLooperThread extends Thread{
167. private EventHandler mNoLooperThreadHandler;
168. public void run() {
169. Looper myLooper, mainLooper;
170. myLooper = Looper.myLooper();
171. mainLooper = Looper.getMainLooper(); //这是一个static函数
172. String obj;
173. if(myLooper == null){
174. mNoLooperThreadHandler = new EventHandler(mainLooper);
175. obj = "NoLooperThread has no looper and handleMessage function executed in main thread!";
176. }
177. else {
178. mNoLooperThreadHandler = new EventHandler(myLooper);
179. obj = "This is from NoLooperThread self and handleMessage function executed in NoLooperThread!";
180. }
181. mNoLooperThreadHandler.removeMessages(0);
182. if(false == postRunnable){
183. //send message to main thread
184. Message m = mNoLooperThreadHandler.obtainMessage(2, 1, 1, obj);
185. mNoLooperThreadHandler.sendMessage(m);
186. Log.e(sTag, "NoLooperThread id:" + this.getId());
187. }else{
188. //下面new出来的实现了Runnable接口的对象中run函数是在Main Thread中执行，不是在NoLooperThread中执行
189. //注意Runnable是一个接口，它里面的run函数被执行时不会再新建一个线程
190. //您可以在run上加断点然后在eclipse调试中看它在哪个线程中执行
191. mNoLooperThreadHandler.post(new Runnable(){
192. @Override
193. public void run() {
194. tv.setText("update UI through handler post runnalbe mechanism!");
195. noLooerThread.stop();
196. }
197. });
198. }
199. }
200. }
201.
202. //OwnLooperThread has his own message queue by execute Looper.prepare();
203. class OwnLooperThread extends Thread{
204. private EventHandler mOwnLooperThreadHandler;
205. public void run() {
206. Looper.prepare();
207. Looper myLooper, mainLooper;
208. myLooper = Looper.myLooper();
209. mainLooper = Looper.getMainLooper(); //这是一个static函数
210. String obj;
211. if(myLooper == null){
212. mOwnLooperThreadHandler = new EventHandler(mainLooper);
213. obj = "OwnLooperThread has no looper and handleMessage function executed in main thread!";
214. }
215. else {
216. mOwnLooperThreadHandler = new EventHandler(myLooper);
217. obj = "This is from OwnLooperThread self and handleMessage function executed in NoLooperThread!";
218. }
219. mOwnLooperThreadHandler.removeMessages(0);
220. //给自己发送消息
221. Message m = mOwnLooperThreadHandler.obtainMessage(3, 1, 1, obj);
222. mOwnLooperThreadHandler.sendMessage(m);
223. Looper.loop();
224. }
225. }
226.
227. //ReceiveMessageThread has his own message queue by execute Looper.prepare();
228. class ReceiveMessageThread extends Thread{
229. public void run() {
230. Looper.prepare();
231. mOtherThreadHandler = new Handler(){
232. public void handleMessage(Message msg) {
233. Log.e(sTag, (String)msg.obj);
234. }
235. };
236. Looper.loop();
237. }
238. }
239.
240. }

使用Looper.myLooper静态方法可以取得当前线程的Looper对象。
使用mHandler = new EevntHandler(Looper.myLooper()); 可建立用来处理当前线程的Handler对象；其中，EevntHandler是Handler的子类。
使用mHandler = new EevntHandler(Looper.getMainLooper()); 可建立用来处理main线程的Handler对象；其中，EevntHandler是Handler的子类。
1.5.1.主线程给自己发送消息示例
主线程发送消息：
在onClick的case 101中创建一个继承自Handler的EventHandler对象，然后获取一个消息，然后通过EventHandler对象调用sendMessage把消息发送到主线程的MessageQueue中。主线程由系统创建，系统会给它建立一个Looper对象和MessageQueue，所以可以接收消息。这里只要根据主线程的Looper对象初始化EventHandler对象，就可以通过EventHandler对象发送消息到主线程的消息队列中。
主线程处理消息：
这里是通过EventHandler的handleMessage函数处理的，其中收到的Message对象中what值为一的消息就是发送给它的，然后把消息里面附带的字符串在TextView上显示出来。
1.5.2.其他线程给主线程发送消息示例
其他线程发送消息（这里是说不使用Runnable作为callback的消息）：
首先postRunnable设为false，表示不通过Runnable方式进行消息相关的操作。然后启动线程noLooerThread， 然后以主线程的Looper对象为参数建立EventHandler的对象mNoLooperThreadHandler，然后获取一个Message并把一个字符串赋值给它的一个成员obj，然后通过mNoLooperThreadHandler把消息发送到主线程的MessageQueue中。
主线程处理消息：
这里是通过EventHandler的handleMessage函数处理的，其中收到的Message对象中what值为二的消息就是上面发送给它的，然后把消息里面附带的字符串在TextView上显示出来。
1.5.3.其他线程给自己发送消息示例
其他线程发送消息：
其他非主线程建立后没有自己的Looper对象，所以也没有MessageQueue，需要给非主线程发送消息时需要建立MessageQueue以便接收消息。下面说明如何给自己建立MessageQueue和Looper对象。从OwnLooperThread的run函数中可以看见有一个Looper.prepare()调用，这个就是用来建立非主线程的MessageQueue和Looper对象的。
所以这里的发送消息过程是建立线程mOwnLooperThread，然后线程建立自己的Looper和MessageQueue对象，然后根据上面建立的Looper对象建立对应的EventHandler对象mOwnLooperThreadHandler，然后由mOwnLooperThreadHandler建立消息并且发送到自己的MessageQueue里面。
其他线程处理接收的消息：
线程要接收消息需要在run函数中调用Looper.loop()，然后loop函数会从MessageQueue中取出消息交给对应的Handler对象mOwnLooperThreadHandler处理，在mOwnLooperThreadHandler的handleMessage函数中会把Message对象中what值为三的消息（上面发送的消息）在Log中打印出来，可以通过Logcat工具查看log。
1.5.4.其他线程以Runnable为消息参数给主线程发送消息示例
其他线程发送消息（这里是说使用Runnable作为callback的消息）：
首先postRunnable设为true，表示通过Runnable方式进行消息相关的操作。然后启动线程noLooerThread， 然后以主线程的Looper对象为参数建立EventHandler的对象mNoLooperThreadHandler，然后获取一个Message并把一个字符串赋值给它的一个成员obj，然后通过mNoLooperThreadHandler把消息发送到主线程的MessageQueue中。
主线程处理消息：
主线程收到上面发送的Message后直接运行上面Runnable对象中的run函数进行相应的操作。run函数通过Log打印一个字符串，可以通过Logcat工具查看log。
1.5.5.主线程给其他线程发送消息示例
主线程发送消息：
这里首先要求线程receiveMessageThread运行（在onCreate函数中完成），并且准备好自己的Looper和MessageQueue（这个通过ReceiveMessageThread中的run函数中的Looper.prepare()调用完成），然后根据建立的Looper对象初始化Handler对象mOtherThreadHandler。然后在onClick的case 105中由mOtherThreadHandler建立一个消息（消息中有一个字符串对象）并且发送到线程receiveMessageThread中的MessageQueue中。
其他线程处理接收的消息：
线程要接收消息需要在run函数中调用Looper.loop()，然后loop函数会从MessageQueue中取出消息交给对应的Handler对象mOtherThreadHandler处理，在mOtherThreadHandler的handleMessage函数中会把Message对象中的字符串对象在Log中打印出来，可以通过Logcat工具查看log。

详解 Android 的 Activity 组件(转)
2010-02-03 11:34
本文详细介绍了 Android 应用编程中 Activity 的生命周期、通信方式和 Intent Filter 等内容，并提供了一些日常开发中经常用到的关于 Activity 的技巧和方法。通过本文，你可以进一步了接 Android 中 Activity 的运作方式。
详解 Android 的 Activity 组件
Activity 的生命周期
和 J2ME 的 MIDlet 一样，在 android 中，Activity 的生命周期交给系统统一管理。与 MIDlet 不同的是安装在 android 中的所有的 Activity 都是平等的。
Activity 的状态及状态间的转换
在 android 中，Activity 拥有四种基本状态：
1. Active/Runing一个新 Activity 启动入栈后，它在屏幕最前端，处于栈的最顶端，此时它处于可见并可和用户交互的激活状态。
2. Paused 当 Activity 被另一个透明或者 Dialog 样式的 Activity 覆盖时的状态。此时它依然与窗口管理器保持连接，系统继续维护其内部状态，所以它仍然可见，但它已经失去了焦点故不可与用户交互。
3. Stoped 当 Activity 被另外一个 Activity 覆盖、失去焦点并不可见时处于 Stoped状态。
4. Killed Activity 被系统杀死回收或者没有被启动时处于 Killed状态。
当一个 Activity 实例被创建、销毁或者启动另外一个 Activity 时，它在这四种状态之间进行转换，这种转换的发生依赖于用户程序的动作。下图说明了 Activity 在不同状态间转换的时机和条件：

图 1. Activity 的状态转换

如上所示，Android 程序员可以决定一个 Activity 的"生"，但不能决定它的"死"，也就时说程序员可以启动一个 Activity，但是却不能手动的"结束"一个 Activity。当你调用 Activity.finish()方法时，结果和用户按下 BACK 键一样：告诉 Activity Manager 该 Activity 实例完成了相应的工作，可以被"回收"。随后 Activity Manager 激活处于栈第二层的 Activity 并重新入栈，同时原 Activity 被压入到栈的第二层，从 Active 状态转到 Paused 状态。例如：从 Activity1 中启动了 Activity2，则当前处于栈顶端的是 Activity2，第二层是 Activity1，当我们调用 Activity2.finish()方法时，Activity Manager 重新激活 Activity1 并入栈，Activity2 从 Active 状态转换 Stoped 状态，Activity1. onActivityResult(int requestCode, int resultCode, Intent data)方法被执行，Activity2 返回的数据通过 data参数返回给 Activity1。
Activity 栈
Android 是通过一种 Activity 栈的方式来管理 Activity 的，一个 Activity 的实例的状态决定它在栈中的位置。处于前台的 Activity 总是在栈的顶端，当前台的 Activity 因为异常或其它原因被销毁时，处于栈第二层的 Activity 将被激活，上浮到栈顶。当新的 Activity 启动入栈时，原 Activity 会被压入到栈的第二层。一个 Activity 在栈中的位置变化反映了它在不同状态间的转换。Activity 的状态与它在栈中的位置关系如下图所示：

图 2. Activity 的状态与它在栈中的位置关系

如上所示，除了最顶层即处在 Active 状态的 Activity 外，其它的 Activity 都有可能在系统内存不足时被回收，一个 Activity 的实例越是处在栈的底层，它被系统回收的可能性越大。系统负责管理栈中 Activity 的实例，它根据 Activity 所处的状态来改变其在栈中的位置。
Activity 生命周期
在 android.app.Activity类中，Android 定义了一系列与生命周期相关的方法，在我们自己的 Activity 中，只是根据需要复写需要的方法，Java 的多态性会保证我们自己的方法被虚拟机调用，这一点与 J2ME 中的 MIDlet 类似。
public class OurActivity extends Activity {
protected void onCreate(Bundle savedInstanceState);
protected void onStart();
protected void onResume();
protected void onPause();
protected void onStop();
protected void onDestroy();
}

这些方法的说明如下：
i. protected void onCreate(Bundle savedInstanceState)一个 Activity 的实例被启动时调用的第一个方法。一般情况下，我们都覆盖该方法作为应用程序的一个入口点，在这里做一些初始化数据、设置用户界面等工作。大多数情况下，我们都要在这里从 xml 中加载设计好的用户界面。例如：
setContentView(R.layout.main);

当然，也可从 savedInstanceState中读我们保存到存储设备中的数据，但是需要判断 savedInstanceState是否为 null，因为 Activity 第一次启动时并没有数据被存贮在设备中：
if(savedInstanceState!=null){
savedInstanceState.get("Key");
}

i. protected void onStart()该方法在 onCreate() 方法之后被调用，或者在 Activity 从 Stop 状态转换为 Active 状态时被调用。
ii. protected void onResume()在 Activity 从 Pause 状态转换到 Active 状态时被调用。
iii. protected void onResume()在 Activity 从 Active 状态转换到 Pause 状态时被调用。
iv. protected void onStop()在 Activity 从 Active 状态转换到 Stop 状态时被调用。一般我们在这里保存 Activity 的状态信息。
v. protected void onDestroy()在 Active 被结束时调用，它是被结束时调用的最后一个方法，在这里一般做些释放资源，清理内存等工作。

图 3. 这些方法的调用时机

此外，Android 还定义了一些不常用的与生命周期相关的方法可用：
protected void onPostCreate(Bundle savedInstanceState);
protected void onRestart();
protected void onPostResume();

Android 提供的文档详细的说明了它们的调用规则。
创建一个 Activity
在 android 中创建一个 Activity 是很简单的事情，编写一个继承自 android.app.Activity的 Java 类并在 AndroidManifest.xml声明即可。下面是一个为了研究 Activity 生命周期的一个 Activity 实例（工程源码见下载）：
Activity 文件：
public class EX01 extends Activity {
private static final String LOG_TAG = EX01.class.getSimpleName();
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
Log.e(LOG_TAG, "onCreate");
}
@Override
protected void onStart() {
Log.e(LOG_TAG, "onStart");
super.onStart();
}
@Override
protected void onResume() {
Log.e(LOG_TAG, "onResume");
super.onResume();
}
@Override
protected void onPause() {
Log.e(LOG_TAG, "onPause");
super.onPause();
}
@Override
protected void onStop() {
Log.e(LOG_TAG, "onStop");
super.onStop();
}
@Override
protected void onDestroy() {
Log.e(LOG_TAG, "onDestroy ");
super.onDestroy();
}
}

AndroidManifest.xml 中通过 <activity> 节点说明 Activity，将 apk 文件安装后，系统根据这里的说明来查找读取 Activity，本例中的说明如下：
<activity android:name=".EX01" android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

启动另外一个 Activity
Activity.startActivity()方法可以根据传入的参数启动另外一个 Activity：
Intent intent =new Intent(CurrentActivity.this,OtherActivity.class);
startActivity(intent);

当然，OtherActivity同样需要在 AndroidManifest.xml 中定义。
Activity 之间通信
使用 Intent 通信
在 Android 中，不同的 Activity 实例可能运行在一个进程中，也可能运行在不同的进程中。因此我们需要一种特别的机制帮助我们在 Activity 之间传递消息。Android 中通过 Intent 对象来表示一条消息，一个 Intent 对象不仅包含有这个消息的目的地，还可以包含消息的内容，这好比一封 Email，其中不仅应该包含收件地址，还可以包含具体的内容。对于一个 Intent 对象，消息"目的地"是必须的，而内容则是可选项。
在上面的实例中通过 Activity. startActivity(intent)启动另外一个 Activity 的时候，我们在 Intent 类的构造器中指定了"收件人地址"。
如果我们想要给"收件人"Activity 说点什么的话，那么可以通过下面这封"e-mail"来将我们消息传递出去：
Intent intent =new Intent(CurrentActivity.this,OtherActivity.class);
// 创建一个带"收件人地址"的 email
Bundle bundle =new Bundle();// 创建 email 内容
bundle.putBoolean("boolean_key", true);// 编写内容
bundle.putString("string_key", "string_value");
intent.putExtra("key", bundle);// 封装 email
startActivity(intent);// 启动新的 Activity

那么"收件人"该如何收信呢？在 OtherActivity类的 onCreate()或者其它任何地方使用下面的代码就可以打开这封"e-mail"阅读其中的信息：
Intent intent =getIntent();// 收取 email
Bundle bundle =intent.getBundleExtra("key");// 打开 email
bundle.getBoolean("boolean_key");// 读取内容
bundle.getString("string_key");

上面我们通过 bundle对象来传递信息，bundle维护了一个 HashMap<String, Object>对象，将我们的数据存贮在这个 HashMap 中来进行传递。但是像上面这样的代码稍显复杂，因为 Intent 内部为我们准备好了一个 bundle，所以我们也可以使用这种更为简便的方法：
Intent intent =new Intent(EX06.this,OtherActivity.class);
intent.putExtra("boolean_key", true);
intent.putExtra("string_key", "string_value");
startActivity(intent);

接收：
Intent intent=getIntent();
intent.getBooleanExtra("boolean_key",false);
intent.getStringExtra("string_key");

使用 SharedPreferences
SharedPreferences 使用 xml 格式为 Android 应用提供一种永久的数据存贮方式。对于一个 Android 应用，它存贮在文件系统的 /data/ data/your_app_package_name/shared_prefs/目录下，可以被处在同一个应用中的所有 Activity 访问。Android 提供了相关的 API 来处理这些数据而不需要程序员直接操作这些文件或者考虑数据同步问题。
// 写入 SharedPreferences
SharedPreferences preferences = getSharedPreferences("name", MODE_PRIVATE);
Editor editor = preferences.edit();
editor.putBoolean("boolean_key", true);
editor.putString("string_key", "string_value");
editor.commit();

// 读取 SharedPreferences
SharedPreferences preferences = getSharedPreferences("name", MODE_PRIVATE);
preferences.getBoolean("boolean_key", false);
preferences.getString("string_key", "default_value");

其它方式
Android 提供了包括 SharedPreferences 在内的很多种数据存贮方式，比如 SQLite，文件等，程序员可以通过这些 API 实现 Activity 之间的数据交换。如果必要，我们还可以使用 IPC 方式。

Activity 的 Intent Filter
Intent Filter 描述了一个组件愿意接收什么样的 Intent 对象，Android 将其抽象为 android.content.IntentFilter 类。在 Android 的 AndroidManifest.xml 配置文件中可以通过 <intent-filter >节点为一个 Activity 指定其 Intent Filter，以便告诉系统该 Activity 可以响应什么类型的 Intent。
当程序员使用 startActivity(intent) 来启动另外一个 Activity 时，如果直接指定 intent 了对象的 Component 属性，那么 Activity Manager 将试图启动其 Component 属性指定的 Activity。否则 Android 将通过 Intent 的其它属性从安装在系统中的所有 Activity 中查找与之最匹配的一个启动，如果没有找到合适的 Activity，应用程序会得到一个系统抛出的异常。这个匹配的过程如下：

图 4. Activity 种 Intent Filter 的匹配过程

Action 匹配
Action 是一个用户定义的字符串，用于描述一个 Android 应用程序组件，一个 Intent Filter 可以包含多个 Action。在 AndroidManifest.xml 的 Activity 定义时可以在其 <intent-filter >节点指定一个 Action 列表用于标示 Activity 所能接受的"动作"，例如：
<intent-filter >
<action android:name="android.intent.action.MAIN" />
<action android:name="com.zy.myaction" />
......
</intent-filter>

如果我们在启动一个 Activity 时使用这样的 Intent 对象：
Intent intent =new Intent();
intent.setAction("com.zy.myaction");

那么所有的 Action 列表中包含了"com.zy.myaction"的 Activity 都将会匹配成功。
Android 预定义了一系列的 Action 分别表示特定的系统动作。这些 Action 通过常量的方式定义在 android.content. Intent中，以"ACTION_"开头。我们可以在 Android 提供的文档中找到它们的详细说明。
URI 数据匹配
一个 Intent 可以通过 URI 携带外部数据给目标组件。在 <intent-filter >节点中，通过 <data/>节点匹配外部数据。
mimeType 属性指定携带外部数据的数据类型，scheme 指定协议，host、port、path 指定数据的位置、端口、和路径。如下：
<data android:mimeType="mimeType" android:scheme="scheme"
android:host="host" android:port="port" android:path="path"/>

如果在 Intent Filter 中指定了这些属性，那么只有所有的属性都匹配成功时 URI 数据匹配才会成功。
Category 类别匹配
<intent-filter >节点中可以为组件定义一个 Category 类别列表，当 Intent 中包含这个列表的所有项目时 Category 类别匹配才会成功。

一些关于 Activity 的技巧
锁定 Activity 运行时的屏幕方向
Android 内置了方向感应器的支持。在 G1 中，Android 会根据 G1 所处的方向自动在竖屏和横屏间切换。但是有时我们的应用程序仅能在横屏 / 竖屏时运行，比如某些游戏，此时我们需要锁定该 Activity 运行时的屏幕方向，<activity >节点的 android:screenOrientation属性可以完成该项任务，示例代码如下：
<activity android:name=".EX01"
android:label="@string/app_name"
android:screenOrientation="portrait">// 竖屏 , 值为 landscape 时为横屏
............
</activity>

全屏的 Activity
要使一个 Activity 全屏运行，可以在其 onCreate()方法中添加如下代码实现：
// 设置全屏模式
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
WindowManager.LayoutParams.FLAG_FULLSCREEN);
// 去除标题栏
requestWindowFeature(Window.FEATURE_NO_TITLE);

在 Activity 的 Title 中加入进度条
为了更友好的用户体验，在处理一些需要花费较长时间的任务时可以使用一个进度条来提示用户"不要着急，我们正在努力的完成你交给的任务"。如下图：
在 Activity 的标题栏中显示进度条不失为一个好办法，下面是实现代码：
// 不明确进度条
requestWindowFeature(Window.FEATURE_INDETERMINATE_PROGRESS);
setContentView(R.layout.main);
setProgressBarIndeterminateVisibility(true);

// 明确进度条
requestWindowFeature(Window.FEATURE_PROGRESS);
setContentView(R.layout.main);
setProgress(5000);

[转]关于Activity和Task的设计思路和方法
2010-02-03 11:51
Activity和Task是Android Application Framework架构中最基础的应用，开发者必须清楚它们的用法和一些开发技巧。本文用大量的篇幅并通过引用实例的方式一步步深入全面讲解它们的基础原理(underlying principles)和架构(mechanisms)，例如：Navigation、Multitasking、activity re-use、intents和activity stack等...大部分与其相关的应用模块。重点讲解开发过程中如何更准确的体现用户交互性的便捷和高效，同时也帮助分析Designers和Developers在开发期间所要面对的问题。
文中涉及到的实例有一部分是属于平台自带的application（例如：拨号程序等），另外也有Google产品线中的一些有代表性的应用（例如：Google Map等）。建议大家亲自利用Emulator或者Android-powered device测试实例中的效果，这样可以帮助更加清晰的理解一些模块的含义。（注意：可能会因为硬件对于某些功能无法提供支持，所以有一些实例可能无法在你的测试机中正常浏览）
首先需要清楚一些基础模块:
• Applications
• Acitivities
• Activity Stack
• Tasks
以上这四个模块对于理解这篇文章非常重要，下边就来逐一的简单介绍其具体的含义和用法（也可以通过其链接直接查看官方文档）。
Applications
任何一个Android Application基本上是由一些Activities组成，当用户与应用程序交互时其所包含的部分Activities具有紧密的逻辑关系，或者各自独立处理不同的响应。这些Activities捆绑在一起成为了一个处理特定需求的Application, 并且以".apk"作为后缀名存在于文件系统中。Android平台默认下的应用程序 例如：Email、Calendar、Browser、Maps、Text Message、Contacts、Camera和Dialer等都是一个个独立的Apps。
Activities
上边已经提到Activities是构成Applications的主要组成部分，其实可以更为具体的理解为Application仅仅是一个抽象的标签，它将系统内一部分Activities关联在一起，协同完成用户的特定需求。安装Application的过程也可以简单理解为将其所包裹的Activities导入到当前的系统中，如果系统中已经存在了相同的Activities，那么将会自动将其关联，而不会重复安装相同的Activities，避免资源的浪费。Application卸载的过程也会检查当前所关联的Activities是否有被其它Application标签所关联，如果仅仅是提供当前的Application使用，那么将会彻底被移除，相反则不做任何操作。
用户与Application的交互行为大部分都是通过GUI来完成，在Android平台可以有两种方式定义GUI，其中可以利用XML来预置静态的GUI元素，或者在Activity类的内部动态定义GUI元素。这两种不同的方法都是由Activity作为驱动和响应用户交互事件的主体。当启动Application之后，至少需要一个包含有GUI信息的Activity实例被创建。
Activity的主体包括两个主要部分，其中一个是Content(data)，另外一个是响应用户交互事件的行为。列举一个Dialer例子的截图，其中包括四个部分：Dialer主界面、通讯录、查看联系人信息和添加新联系人。

下面列举了更多比较有代表性的Applications和其所包含的Activities：
• Email - activities to view folders, view list of messages, view a message, compose a message, and set up an account
• Calendar - activities to view day, view week, view month, view agenda, edit an event, edit preferences, and view an alert
• Camera - activities for running the camera, viewing the list of pictures, viewing a picture, cropping a picture, running the camcorder, viewing the list of movies, and viewing a movie
• Game - one activity to play the game, typically another for setup
• Maps - one activity to view a location on a map, a second for lists (such as turn list or friend list), and a third for details (friend location, status, photo)
Application基本上是由四个模块组成：Activity、Service、Content Provider 和 Broadcast Receiver，其中Activity是实现应用的主体。
Activity Stack
操作应用程序时，有时需要调用多个Activities来完成需求，例如：发送邮件程序，首先是进入邮件主界面，然后启动一个新的Activity用于填写新邮件内容，同时可以调出联系人列表用于插入收件人信息等等。在这个操作过程中Android平台有一个专门用于管理Activities堆栈的机制，其可以方便的线性记录Activities实例，当完成某个操作时，可以通过这个导航功能返回之前的Activity（通过按操作台的"Back"）。
每次启动新的Activity都将被添加到Activity Stack。用户可以方便的返回上一个Activity直到Home Screen，到达Home Screen后，将无法再继续查看堆栈记录（俗话说：到头了- Androidres.com）。如果当前Task被中止(Interrupting the task)，返回到系统主界面后启动了其它操作，当希望返回到前一个Task继续执行时，只需要再次通过主界面的Application launcher或者快捷方式启动这个Task的Root Activity便可返回其中止时的状态继续执行。
相对于Views、Windows、Menus和Dialogs而言，Activity是唯一可被记录在History stack中的数据，所以当你所设计的应用程序需要用户由A界面进入到次一级界面B，当完成操作后需要再次返回A,那么必须考虑将A看作为Activity，否则将无法从历史堆栈中返回。
Tasks
在Android平台上可以将Task简单的理解为由多个Activities共同协作完成某一项应用，而不管Activities具体属于哪个Application。通过下边的图示可以更清晰的理解Applications、Tasks、Activities三者之间的关系 （Androidres.com提供）:

Activities可以被看作为是独立存在于系统资源中，而且是作为实现具体应用的主体，Task将一些Activity关联起来实现一个更复杂的应用,单独或者多个Tasks可以被定义为一个Application。
通常实现一个Task都会存在一个Root Activity，但并不是所有情况都如此，通过Application launcher、Home screen 的快捷方式或者 由 "Recent Tasks"（长时间按住Home键） 最近使用过的Task记录中启动。当从一个Activity中启动另外一个Activity时，Back键将作用于返回前一个Activity,与此同时新开启的Activity将被添加到Activity Stack中。
这里有两个被表示为Task的例子：
• 发送带有附件的邮件
• 查看YouTube视频，并且通过Email的方式共享给其他联系人。
- Interrupting the Task
这是Task一个非常重要的特性，用户可以实时中止当前为完成的Task，新开启一个不同的Task，当新Task完成操作后，依然可以返回当上一次中止的Task继续完成余下操作。这个特性大大方便了同时运行多个Tasks，并且可以方便的在他们之间切换。这里有两种方式可以从当前Task跳转为其它Task（应用这两种方式切换Task，都允许返回到Task最初中止前的状态）。
• 系统抛出一个Notification，当前Task会被终止，跳转为Notification的Task。
• 用户强制中止
当然，除了这两种方式以外，还有另外一个特殊情况，算作为第三种方式来启动一个新的Task：Activity本身被定义为一个Task。例如： Maps和Browser就是属于第三种情况的Application，通过邮件中的一个地址来启动Maps Activity作为一个新的Task，或者通过邮件中的链接启动Browser来启动一个新的Task。当处在这种情况下，Back按键被触发后，将返回到上一个Task(邮件），因为这些新的Tasks并不是通过Home Screen中的Application launcher或者快捷方式来启动。

了解Activities和Tasks的基本原理
请大家一定首先理解之前所提及的内容，如果对某些概念依然含混不清，请及时查阅更多资料（官方文档是最好的学习资料），否则无法快速理解接下来将要讲述的例子，甚至丧失阅读兴趣。
接下来，将通过一些有代表性的实例了解关于Applications、Activities、Activities stack、Tasks和Intent等一些模块的最基本原理。从各个角度分析系统对于用户在不同模式下操作的反应原理。
从Home启动一个Activity
绝大部分的Application都由此启动（也有一些Application是通过其它Application启动）。具体的方式有两种，其一是从系统的Application Launcher启动，另一种是直接由Home Screen的快捷方式。启动Application后，Root Activity会显示在当前窗口，并可直接供用户操作界面元素。官方给出了一个有关这个过程的图示，其实我感觉这个描述的还不够直观，凑合着用吧。大体的过程是由Home下启动Email Application，在这个应用程序中可以直接提供给用户操作的是List Messages Activity，Home Activity切换为后台运行。

应用Back或Home键离开当前Activity的区别
应用Back或者Home都可以离开当前Activity（基于Application的Root Activity），Home activity重新切换到foreground，然而二者最根本的区别在于用户是否还需要保留当前Activity的state。
- Back:
将会终止（Destroy）当前正在运行的Activity，返回到之前的Activity（如果是 Root Activity，那么将会直接返回到Home Activity）。官方给出了一个相关过程的图示，当用户正在操作List Messages Activity时，下拉邮件列表（改变了Scrolling状态），通过Back键返回到Home Activity之后，当再次通过Email Icon启动 List Messages Activity时，将会看到列表处在初始位置。通过这个演示可以了解到通过Back键离开当前Activity时，无法暂时保留住其State数据，当再次启动时相当于重新创建了一个实例。

-Home:
利用Home取代Back返回的方式，当前Activity将被切换到Background，而不是被Destroied。这样的好处是可以暂时保留这个Activity的State信息，当再次通过Application launcher或者快捷方式启动时，可以返回到最后离开的状态。对比在Back中引用的例子，当再次由Home返回到Activity时，将会看到最后一次操作所记录的Scroll状态，而不是默认的初始位置。

Exception(例外情况）
前边列举了两种典型的情况，同时还存在一些例外的情况，某些Activity从Background被"召唤"到foreground之后依然是相当于重新创建了新实例，其有区别于前边所论述的结果。即便是暂时保存在Background模式下（没有被Destroied），其State数据也将丢失。例如：Contacts 和 Gallery 等。当用户启动了Contact应用程序，并点选某个条目查看详细信息，如果通过Home键返回后，再次重复启动Contact应用程序时，看到的并不是之前所打开的特定条目的详细信息，而是初始的默认界面。这个例子说明不是所有情况下通过Home键返回后都可以保存当前Activity的State信息。
另外一种是与Back键有关的特殊情况。前边提及到大部分的Activity通过Back键返回到Home Activity时，其自身将被彻底销毁，默认情况下Activity响应Back按键的方法被定义了Destroy行为。但对于某些特别情况，开发者可以根据需求将相应Back按键事件的行为重新"override"，撤消默认的Destroy行为。音乐播放器是与其相关的一个典型应用，当用户在播放器的Root Activity中触发Back按键后，转为Background模式下继续播放当前的音乐，同时Home Activity转为Foreground。
Activity的复用
在多个不同的Applications中，当遇到有相同目的应用时，会涉及到Activity的复用性问题，这在开发过程中是一个非常普遍的情况。复用性一直被众多开发机构强调为节约成本，优化资源的最有效的机制。对于移动应用平台更加看重资源的最优化利用，复用性的应用在Android平台上无处不在，通过两个比较基础的例子来具体的说明。
- Contacts利用Gallery获得图像资源
众所周知Contacts是手机中最常用的应用程序，主要用于存储当前用户的联系人信息，其中需要包含联系人的头像信息。在Android平台中的图像信息是由Gallery管理，所以Contacts必然需要复用Gallery Activity来获取相应的图像信息。
针对于Android或者其它平台开发应用程序都需要有良好的复用性意识，这个需要贯穿于项目的整个开发过程。包括如何利用当前系统的现有资源，或者考虑到将来可能会被其它应用程序用于完成特定的需求。当用户正在调用的Intent filter不唯一时，系统将弹出一个供用户选择的对话框，这的确是一个完美的解决方法。

- 利用Messaging扩展Gallery共享功能
用户通过Gallery查看当前系统中的图像资源，每次单独打开一幅图像资源都可以通过Menu -> Share将当前的资源以附件形式插入新创建的Messaging中，并且以正常发送信息的方式将其共享给收件人。如果取消当前的共享行为，只需要通过Back按键返回到Gallery Activity。相比较前一个例子的区别在于，Message Activity完成发送或者被取消操作，其不会返回任何信息。

以上两个例子分别讲解了利用一系列的Activities来完成某一项需求，并且它们都调用了外部的Application资源。
Replacing an Activity
目前要介绍的内容是关于在不同的Applications中，有相同Intent filter属性的Activities可相互间替换，这对于习惯Windows等操作系统的用户比较不容易理解。其实如果您足够细心，就可以发现之前的例子中有关于这里所提及情况。
通常遇到这种情况发生时，一般都是因为外部具有相同功能的Activity A 在处理问题的能力方面要优于当前Application中默认的操作行为Activity B，系统会抛出一个可供选择的对话框，用户根据主观判断来选择最优的方式处理当前任务。通过一个比较容易理解的实例来说明整个过程，建议"动手能力强"的同学可以通过模拟器亲自尝试。
例如：用户在当前系统下加载了最新的Phone Ringtone Activity，取名为Rings Extended。如果用户通过Setting -> Sounds&Display -> Phone Ringtone 来设置当前的铃音属性时，将会弹出一个包含有系统默认的Phone Ringtone Activity 和最新加载的Rings Extended两种可供选择的操作应用，同时在对话框中还提供了一种可以直接启动系统默认的操作方式选项。如果用户选择了Rings Extended，那么其将会被载入当前的线程中替代原有的默认操作行为，可以根据下面的图示来增强理解。

多任务同时运行（Multitasking）
在之前的版块有专门提到关于Home和Back两种切换到Home Screen的方法和它们之间的差异性，这个章节将会重点涉及到系统可以同时处理多个实时运行的任务。如果用户正处于某个Application A开启状态时，通过Home按键切换回Home Activity的同时保留了此前Application A运行的状态信息，可以开启新程序的同时，也可以再次将Application A切换回Foreground。
接下来通过一个有关Map应用的实例更加具体的了解其所涵盖的过程。
首先的起始阶段分为三个步骤，
第一步，由Application Launcher启动Map应用程序，并且搜索一个具体的地理位置。假设当前的网络环境非常不理想，需要花费一定的时间Download地图数据。
第二步，当系统需要花费较长时间加载当前地图信息数据时，保持当前Activity的状态，返回Home Activity启动其它的Applicaton，地图Activity切换到Background，而并不会中断加载进度（依然保持网络连接）。
注意：以上是Activity在默认条件下的反应行为，其切换为Background状态后直接触发onStop()事件，开发者可以重新定义其方法。例如：强制Activity在转为Background状态下，终止网络连接。
第三步，当前Map activity已经切换到Background状态下运行，Home Activity切换到Foreground。这时用户启动Calender activity，其将自动转为Foreground状态，同时获得操作焦点。
将以上三个步骤用图示的方式表述：

最后，退出当前Calender activity返回到Home，再次通过Maps图标将其处在Background状态的实例切换到Foreground。

通过上边的例子看出用户通过Application Launcher同时运行多个Tasks，代表系统具备多任务处理机制 - Running multiple tasks。
启动Application的两种不同方式
每个App都需要提供至少一个Entry point（翻译成"入口点"有点别扭，干脆保留原样）供用户或者系统调用其所关联的Activities，Application launcher中的小图标就是每个单独App的Entry Point。另外App也可以相互间通过Activity作为Entry Point来启动，可以将App所包含的每个Activity看作为潜在的Entry point。
系统中的Phone Application同样具有两个Entry Points：Contacts和Dialer。下边的图示中可以了解到用户通过Application launcher启动Contacts Activity，选择其中某一个联系人之后，调用Dialer Activity拨打其所提供的电话号码。

Intents
在现实世界中大家每时每刻都会与周围的环境发生互动，这个互动的过程首先要确定一种意识，例如：感觉到口渴，需要水分补充。这种意识会引导自己以习惯的方式解决口渴问题，采用的方式可以多种多样，吃冰淇淋、喝水、嚼树叶等。类似于口渴的意识形态被抽象为Intent，并将其看作是一种对象，这就是Android响应"意识"的方式。
在Android平台上，用户的操作行为是由各种不同的事件组成，系统会将每个事件都抽象为Intent对象，寻找解决这项需求的具体方法。抽象的Intent对象有两种形式，第一种是"明确"的Intent（Explicit Intent），在初始化的时候已经为这个Intent关联了特定的Activity。第二种是"不明确"的Intent（Implicit Intent），代表这个Intent没有明确关联Activity，当它被抛出后，系统在众多Activities中根据Intent filter来寻找与其匹配的处理方法。如果存在多个结果，用户可以根据需要选择合适的处理方法。
引用一个具体的例子，单击一个mailto:info@androidres.com链接后，这个被抛出的Intent属于 Implicit Intent ，系统抓取了解决这个Intent的结果，将所有的结果供用户选择（Gmail或者Email）：

下边给出更多系统默认的Intent关联列表：
• View the list of contacts - resolves to a contact list viewer activity
• View a particular contact - resolves to a contact viewer activity
• Edit a particular contact - resolves to a contact editor activity
• Send to a particular email - resolves to an email activity
• Dial a phone number - resolves to a phone dialer activity
• View the list of images - resolves to an image list viewer activity
• View a particular image - resolves to an image viewer activity
• Crop a particular image - resolves to an image cropper activity
Intent对象包含两个元素：
1）Action ：例如 查看、编辑、拨打电话、查看图像资源等等。
2）Data：提供给某种行为的具体数据。加工果汁饮料，需要提供水果（黑心店除外）。
参照官网的解释：Intent Class 和 Intent Filters。
Tasks相互间切换
依然是应用实例来说明这个切换的过程。在这个例子中，用户编辑一个短消息，并且插入图像附件，但是在发送之前启动Calendar，随后切换回短消息编辑界面，最后发送信息。
1）启动第一个Task：Messaging App，Home > Messaging > New Message > Menu > Attach > Picture。插入图片的步骤需要调用Gallery Activity，它是一个独立的外部程序。

 

接下来启动另外一个Task，由于没有直接从当前的Activity运行Calendar，所以需要切换到Home。
2）启动另外一个Application（Calendar）：Home > Calendar

3）查看Calendar完成后，将Messaging由Background切换到Foreground模式，其中还包括了添加附件，并最终发送消息。

至此，对于Android平台中两个比较核心元素： Activities和Tasks 的介绍基本告一段落，以后也许会有更多关于这方面的讨论，希望得到您的关注。另外，有些朋友或许已经看过官方的原文，而本站也再次有幸得到了您的通读，如果在某些概念或者论述内容上存在遗漏或者误解，那么真诚的希望能够获得指正和帮助。

查看文章
Android Wifi模块分析(总览)
2010-02-04 10:37
这两天通过对Android源码中Wifi模块相关代码的理解，对Wifi模块有了一个全新的认识。简单记录在这里，就算是为以后的学习留个记录。
总览：
1，Wifi介绍（百度百科）
2，Android中Wifi模块的初始化
3，Wifi模块的启动（使能）
4，Wifi扫描流程
5，Wifi配置AP参数流程
6，Wifi启动连接流程
7，Wifi配置IP地址

Android Wifi模块分析（一）
2010-02-04 10:44
一：Wifi介绍
概述
WIFI就是一种无线联网的技术，以前通过网线连接电脑，而现在则是通过无线电波来连网；常见的就是一个无线路由器，那么在这个无线路由器的电波覆盖的有效范围都可以采用WIFI连接方式进行联网，如果无线路由器连接了一条ADSL线路或者别的上网线路，则又被称为"热点"。
运作原理
Wi-Fi 的设置至少需要一个Access Point（ap）和一个或一个以上的client（hi）。AP每100ms将SSID（Service Set Identifier）经由beacons（信号台）封包广播一次，beacons封包的传输速率是1 Mbit/s，并且长度相当的短，所以这个广播动作对网络效能的影响不大。因为Wi-Fi规定的最低传输速率是1 Mbit/s ，所以确保所有的Wi-Fi client端都能收到这个SSID广播封包，client 可以借此决定是否要和这一个SSID的AP连线。使用者可以设定要连线到哪一个SSID。Wi-Fi系统总是对用户端开放其连接标准，并支援漫游，这就是Wi-Fi的好处。但亦意味着，一个无线适配器有可能在性能上优于其他的适配器。由于Wi-Fi通过空气传送信号，所以和非交换以太网有相同的特点。 近两年，出现一种WIFI over cable的新方案。此方案属于EOC（ethernet over cable）中的一种技术。通过将2.4G wifi射频降频后在cable中传输。此种方案已经在中国大陆小范围内试商用。

Android Wifi模块分析（二）
2010-02-04 10:51
二：Wifi模块的初始化:：
在 SystemServer 启动的时候，会生成一个ConnectivityService 的实例，

try {
Log.i(TAG, "Starting Connectivity Service.");
ServiceManager.addService(Context.CONNECTIVITY_SERVICE, new
ConnectivityService(context));
} catch (Throwable e) {
Log.e(TAG, "Failure starting Connectivity Service", e);
}

ConnectivityService 的构造函数会创建WifiService，
if (DBG) Log.v(TAG, "Starting Wifi Service.");
mWifiStateTracker = new WifiStateTracker(context, handler);
WifiService wifiService = new WifiService(context, mWifiStateTracker);
ServiceManager.addService(Context.WIFI_SERVICE, wifiService);

WifiStateTracker 会创建WifiMonitor 接收来自底层的事件，WifiService 和WifiMonitor 是整
个模块的核心。WifiService 负责启动关闭wpa_supplicant、启动关闭WifiMonitor 监视线程
和把命令下发给wpa_supplicant，而WifiMonitor 则负责从wpa_supplicant 接收事件通知。
具体流程图如下：

DBUS简介（转）
2010-02-05 10:18
DBus 介绍
dbus 是freedesktop下开源的Linux IPC通信机制，本身Linux 的IPC通信机制包括，管道（fifo），共享内存，信号量，消息队列，Socket等。 像现在流行的moblin平台就使用了DBUS通信，还有我最近看的bluez 4 也是通过DBUS来交互的。

它是个3层架构的进程间通信系统，包括：
1. 函数库libdbus，用于两个应用程序呼叫联系和交互消息。
2. Message bus daemon，总线守护进程可同时与多个应用程序相连，并能把来自一个应用程序的消息路由到0或者多个其他程序。
3. 一系列基于特定应用程序框架的Wrapper库。 比如libdbus-glib, libdbus-python.
参看图1-1, Bus Daemon Process就是运行在linux的daemon(dbus-daemon, 用户可以在/etc/init.d/dbus 操作，stop, start等等), dbus-daemon运行时会调用libdus的库。 在Application Process1里面就是应用层的东西了，应用程序调用特定的应用程序框架的Wrapper库与dbus-daemon进行通信。

我前段时间就是用Python写程序与dbus-daemon通信，所以就需要libdbus-python，后来又用c写程序，又装了libdus-glib。实质上在dbus主页上(http://www.freedesktop.org/wiki/Software/dbus) 提供了很多Wrapper库, for QT4, JAVA, Perl, C++, Pascal, QT3, .NET, Ruby等等。这个Wrapper库呢其实就是对dbus下层调用做了封装，给上层暴露一个友好的接口。dbus的底层其实也是通过socket通信的

图 1－1
我再给一张bluez的例子让大家更理解dbus; 有四个应用想与bluz的damon通信，bluez注册到dbus中，其它的应用只需要向dbus要bluez的数据，
dbus负责再和bluez沟通了，但是bluez一定要把接口告诉其它应用。

Android Wifi模块分析（三）
2010-02-05 17:13
第三部分：Wifi模块的启动（使能）

WirelessSettings 在初始化的时候配置了由WifiEnabler 来处理Wifi 按钮，

private void initToggles() {
mWifiEnabler = new WifiEnabler(this,
(WifiManager) getSystemService(WIFI_SERVICE),
(CheckBoxPreference) findPreference(KEY_TOGGLE_WIFI));

当用户按下Wifi 按钮后，Android 会调用WifiEnabler 的onPreferenceChange，再由WifiEnabler
调用WifiManager 的setWifiEnabled 接口函数，通过AIDL，实际调用的是WifiService 的
setWifiEnabled 函数，WifiService 接着向自身发送一条MESSAGE_ENABLE_WIFI 消息，在
处理该消息的代码中做真正的使能工作：首先装载WIFI 内核模块（该模块的位置硬编码为
"/system/lib/modules/wlan.ko" ）， 然后启动wpa_supplicant （ 配置文件硬编码为
"/data/misc/wifi/wpa_supplicant.conf"），再通过WifiStateTracker 来启动WifiMonitor 中的监视
线程。

private boolean setWifiEnabledBlocking(boolean enable) {
final int eventualWifiState = enable ? WIFI_STATE_ENABLED :WIFI_STATE_DISABLED;
updateWifiState(enable ? WIFI_STATE_ENABLING : WIFI_STATE_DISABLING);
if (enable) {
if (!WifiNative.loadDriver()) {
Log.e(TAG, "Failed to load Wi-Fi driver.");
updateWifiState(WIFI_STATE_UNKNOWN);
return false;
}
if (!WifiNative.startSupplicant()) {
WifiNative.unloadDriver();
Log.e(TAG, "Failed to start supplicant daemon.");
updateWifiState(WIFI_STATE_UNKNOWN);
return false;
}
mWifiStateTracker.startEventLoop();
}
// Success!
persistWifiEnabled(enable);
updateWifiState(eventualWifiState);
return true;
}

当使能成功后，会广播发送WIFI_STATE_CHANGED_ACTION 这个Intent 通知外界WIFI
已经成功使能了。WifiEnabler 创建的时候就会向Android 注册接收
WIFI_STATE_CHANGED_ACTION，因此它会收到该Intent，从而开始扫描。

private void handleWifiStateChanged(int wifiState) {
if (wifiState == WIFI_STATE_ENABLED) {
loadConfiguredAccessPoints();
attemptScan();
}

具体流程如下流程图所示：

Android Wifi模块分析（四）
2010-02-08 16:29
第四部分：查找热点（AP）

上一节（第三部分：Wifi开启）中讲到Wifi模块开启后会对外发送WIFI_STATE_CHANGED_ACTION。WifiLayer中注册了Action的Receiver。
当WifiLayer收到此Action后开始scan的流程，具体如下：

当wpa_supplicant 处理完SCAN 命令后，它会向控制通道发送事件通知扫描完成，从wifi_wait_for_event 函数会接收到该事件，由此WifiMonitor 中的MonitorThread 会被执行来出来这个事件：

Android Wifi模块分析（五）
2010-02-08 16:32
第五部分：配置 AP 参数

当用户在 WifiSettings 界面上选择了一个AP 后，会显示配置AP 参数的一个对话框：

Android Wifi模块分析（六）
2010-02-08 16:34
第六部分：Wifi连接

具体流程参见以下流程图：

Android Wifi模块分析（七）
2010-02-08 16:35
第七部分：IP地址的配置

流程如图：

Linux进程知识
2010-02-22 14:56
1、进程可以看做程序的一次执行过程。在linux下，每个进程有唯一的PID标识进程。PID是一个从1到32768的正整数，其中1一般是特殊进程 init，其它进程从2开始依次编号。当用完32768后，从2重新开始。

2、linux中有一个叫进程表的结构用来存储当前正在运行的进程。可以使用"ps aux"命令查看所有正在运行的进程。

3、进程在linux中呈树状结构，init为根节点，其它进程均有父进程，某进程的父进程就是启动这个进程的进程，这个进程叫做父进程的子进程。

4、fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作 为原进程的子进程。

Andriod通话处理流程

一、总览
1、从java端发送at命令的处理流程。

2、unsolicited 消息从modem上报到java的流程。

3、猫相关的各种状态的监听和通知机制。

4、通话相关的图标变换的工作原理。

5、gprs拨号上网的通路原理。

6、通话相关的语音通路切换原理、震动接口。

7、通话相关的notification服务。

8、通话相关的各种server。

第一部分：从java端发送at命令的处理流程。
拨出电话流程：

 

1、contacts的androidmanifest.xml android:process="android.process.acore"说明此应用程序运行在acore进程中。

DialtactsActivity的intent-filter的action属性设置为main，catelog属性设置为launcher，所以此activity能出现

在主菜单中，并且是点击此应用程序的第一个界面。dialtactsactivity包含四个tab，分别由TwelveKeyDialer、

RecentCallsListActivity，两个activity-alias DialtactsContactsEntryActivity和DialtactsFavoritesEntryActivity分别

表示联系人和收藏tab，但是正真的联系人列表和收藏是由ContactsListActivity负责。

 

2、进入TwelveKeyDialer OnClick方法，按住的按钮id为： R.id.digits，执行

placecall()

Intent intent = new Intent(Intent.ACTION_CALL_PRIVILEGED,

Uri.fromParts("tel", number, null));

intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

startActivity(intent);

3、intert.ACTION_CALL_PRIVILEGED实际字符串为android.intent.action.CALL_PRIVILEGED，通过查找知道了packegs/phone

下面的androidmanifest.xml中PrivilegedOutgoingCallBroadcaster activity-alias设置了intent-filter，所以需要找到其

targetactivity为OutgoingCallBroadcaster。所以进入OutgoingCallBroadcaster的

onCreate（）

//如果为紧急号码马上启动intent.setClass(this, InCallScreen.class); startActivity(intent);

Intent broadcastIntent = new Intent(Intent.ACTION_NEW_OUTGOING_CALL);

if (number != null) broadcastIntent.putExtra(Intent.EXTRA_PHONE_NUMBER, number);

broadcastIntent.putExtra(EXTRA_ALREADY_CALLED, callNow);

broadcastIntent.putExtra(EXTRA_ORIGINAL_URI, intent.getData().toString());

if (LOGV) Log.v(TAG, "Broadcasting intent " + broadcastIntent + ".");

sendOrderedBroadcast(broadcastIntent, PERMISSION, null, null,

Activity.RESULT_OK, number, null);

 

4、Intent.ACTION_NEW_OUTGOING_CALL实际字符串为android.intent.action.NEW_OUTGOING_CALL，通过查找知道了packegs/phone

下面的androidmanifest.xml中OutgoingCallReceiver Receiver接收此intent消息。找到OutgoingCallReceiver，执行

onReceive()函数

Intent newIntent = new Intent(Intent.ACTION_CALL, uri);

newIntent.putExtra(Intent.EXTRA_PHONE_NUMBER, number);

newIntent.setClass(context, InCallScreen.class);

newIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

 

5、请求拨号的java部分流程

onCreate(第一次)/onNewIntent(非第一次)

internalResolveIntent

placeCall(intent);

PhoneUtils.placeCall(mPhone, number, intent.getData());

phone.dial(number);

mCT.dial(newDialString);

dial(dialString, CommandsInterface.CLIR_DEFAULT);

cm.dial(pendingMO.address, clirMode, obtainCompleteMessage());//obtainCompleteMessage(EVENT_OPERATION_COMPLETE);

send(rr);

msg = mSender.obtainMessage(EVENT_SEND, rr);

acquireWakeLock();

msg.sendToTarget();

RILSender.handleMessage()

case EVENT_SEND:

...

s.getOutputStream().write(dataLength);

s.getOutputStream().write(data);//从这里流程跑到下面ril.cpp中监听部份

 

 

6、请求拨号的c/c++部分流程

6.1、初始化事件循环，启动串口监听，注册socket监听。

rild.c->main()

(1)、RIL_startEventLoop

//建立事件循环线程

ret = pthread_create(&s_tid_dispatch, &attr, eventLoop, NULL);

//注册进程唤醒事件回调

ril_event_set (&s_wakeupfd_event, s_fdWakeupRead, true,

processWakeupCallback, NULL);

rilEventAddWakeup (&s_wakeupfd_event);

//建立事件循环

ril_event_loop

for (;;) {

...

n = select(nfds, &rfds, NULL, NULL, ptv);

// Check for timeouts

processTimeouts();

// Check for read-ready

processReadReadies(&rfds, n);

// Fire away

firePending();

}

(2)、funcs = rilInit(&s_rilEnv, argc, rilArgv);//实际是通过动态加载动态库的方式执行reference-ril.c中的RIL_Init

//单独启动一个线程读取串口数据

ret = pthread_create(&s_tid_mainloop, &attr, mainLoop, NULL);

fd = open (s_device_path, O_RDWR);

ret = at_open(fd, onUnsolicited);

ret = pthread_create(&s_tid_reader, &attr, readerLoop, &attr);

RIL_requestTimedCallback(initializeCallback, NULL, &TIMEVAL_0);

 

在initializeCallback中执行的程序：

setRadioState (RADIO_STATE_OFF);

at_handshake();

/* note: we don't check errors here. Everything important will

be handled in onATTimeout and onATReaderClosed */

/* atchannel is tolerant of echo but it must */

/* have verbose result codes */

at_send_command("ATE0Q0V1", NULL);

/* No auto-answer */

at_send_command("ATS0=0", NULL);

...

 

 

//注册rild socket端口事件监听到事件循环中

(3)、RIL_register(funcs);

s_fdListen = android_get_control_socket(SOCKET_NAME_RIL);

ret = listen(s_fdListen, 4);

ril_event_set (&s_listen_event, s_fdListen, false,

listenCallback, NULL);//将此端口加入事件select队列

rilEventAddWakeup (&s_listen_event);

 

如果rild socket端口有数据来了将执行listencallback函数

listencallback

//为此客户端连接创建新的监听句柄，s_fdListen继续监听其他客户端的连接。

s_fdCommand = accept(s_fdListen, (sockaddr *) &peeraddr, &socklen);

ril_event_set (&s_commands_event, s_fdCommand, 1,

processCommandsCallback, p_rs);//将此端口加入事件select队列

rilEventAddWakeup (&s_commands_event);

 

6.2、socket监听，收到dial的socket请求

processCommandsCallback

//读数据到p_record中

ret = record_stream_get_next(p_rs, &p_record, &recordlen);

processCommandBuffer(p_record, recordlen);

p.setData((uint8_t *) buffer, buflen);

// status checked at end

status = p.readInt32(&request);

status = p.readInt32 (&token);//请求队列中的序号

pRI = (RequestInfo *)calloc(1, sizeof(RequestInfo));

pRI->token = token;

 

/*

包含#include "ril_commands.h"语句，结构体如下：

typedef struct {

int requestNumber;

void (*dispatchFunction) (Parcel &p, struct RequestInfo *pRI);

int(*responseFunction) (Parcel &p, void *response, size_t responselen);

} CommandInfo;

*/

pRI->pCI = &(s_commands[request]);

pRI->p_next = s_pendingRequests;

s_pendingRequests = pRI;

pRI->pCI->dispatchFunction(p, pRI);

 

//假设是接收了dial指令,pRI->PCI->dispatchFunction(p,pRI)，调用dispatchDial (p,pRI)

dispatchDial (p,pRI)

s_callbacks.onRequest(pRI->pCI->requestNumber, &dial, sizeof(dial), pRI);

in reference-ril.c onRequest()

...

switch (request) {

case RIL_REQUEST_DIAL:

requestDial(data, datalen, t);

asprintf(&cmd, "ATD%s%s;", p_dial->address, clir);

ret = at_send_command(cmd, NULL);

err = at_send_command_full (command, NO_RESULT, NULL, NULL, 0, pp_outResponse);

err = at_send_command_full_nolock(command, type, responsePrefix, smspdu,timeoutMsec, sponse);

err = writeline (command);

//此处等待，直到收到成功应答或失败的应答,如：ok,connect,error cme等

err = pthread_cond_wait(&s_commandcond, &s_commandmutex);

waiting....

waiting....

 

/* success or failure is ignored by the upper layer here.

it will call GET_CURRENT_CALLS and determine success that way */

RIL_onRequestComplete(t, RIL_E_SUCCESS, NULL, 0);

p.writeInt32 (RESPONSE_SOLICITED);

p.writeInt32 (pRI->token);

errorOffset = p.dataPosition();

p.writeInt32 (e);

if (e == RIL_E_SUCCESS) {

/* process response on success */

ret = pRI->pCI->responseFunction(p, response, responselen);

if (ret != 0) {

p.setDataPosition(errorOffset);

p.writeInt32 (ret);

}

}

sendResponse(p);

sendResponseRaw(p.data(), p.dataSize());

blockingWrite(fd, (void *)&header, sizeof(header));

blockingWrite(fd, data, dataSize);

 

6.4、串口监听收到atd命令的应答"OK"或"no carrier"等

readerLoop()

line = readline();

processLine(line);

handleFinalResponse(line);

pthread_cond_signal(&s_commandcond);//至此，前面的等待结束，接着执行RIL_onRequestComplete函数

 

6.5、java层收到应答后的处理,以dial为例子.

ril.java->RILReceiver.run()

for(;;)

{

...

length = readRilMessage(is, buffer);

p = Parcel.obtain();

p.unmarshall(buffer, 0, length);

p.setDataPosition(0);

processResponse(p);

type = p.readInt();

if (type == RESPONSE_SOLICITED) {

processSolicited (p);

serial = p.readInt();

rr = findAndRemoveRequestFromList(serial);

rr.mResult.sendToTarget();

......

}

 

CallTracker.java->handleMessage (Message msg)

switch (msg.what) {

case EVENT_OPERATION_COMPLETE:

ar = (AsyncResult)msg.obj;

operationComplete();

cm.getCurrentCalls(lastRelevantPoll);

第二部分：unsolicited 消息从modem上报到java的流程。
c++部份

readerLoop()

line = readline();

processLine(line);

handleUnsolicited(line);

if (s_unsolHandler != NULL) {

s_unsolHandler (line1, line2);//实际执行的是void onUnsolicited (const char *s, const char *sms_pdu)

if (strStartsWith(s,"+CRING:")

|| strStartsWith(s,"RING")

|| strStartsWith(s,"NO CARRIER")

|| strStartsWith(s,"+CCWA")

)

RIL_onUnsolicitedResponse (RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED, NULL, 0);

p.writeInt32 (RESPONSE_UNSOLICITED);

p.writeInt32 (unsolResponse);

ret = s_unsolResponses[unsolResponseIndex].responseFunction(p, data, datalen);

ret = sendResponse(p);

sendResponseRaw(p.data(), p.dataSize());

ret = blockingWrite(fd, (void *)&header, sizeof(header));

blockingWrite(fd, data, dataSize);

 

java部份

ril.java->RILReceiver.run()

for(;;)

{

...

length = readRilMessage(is, buffer);

p = Parcel.obtain();

p.unmarshall(buffer, 0, length);

p.setDataPosition(0);

processResponse(p);

processUnsolicited (p);

response = p.readInt();

switch(response) {

...

case RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED: ret = responseVoid(p); break;

...

}

switch(response) {

case RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED:

if (RILJ_LOGD) unsljLog(response);

 

mCallStateRegistrants

.notifyRegistrants(new AsyncResult(null, null, null));

...

}
第三部分、第四部分：猫相关的各种状态的监听和通知机制／通话相关的图标变换的工作原理。
网络状态，edge,gprs图标的处理
a、注册监听部分
==>SystemServer.java
init2()
Thread thr = new ServerThread();
thr.setName("android.server.ServerThread");
thr.start();
ServerThread.run()
com.android.server.status.StatusBarPolicy.installIcons(context, statusBar);
sInstance = new StatusBarPolicy(context, service);
// phone_signal
mPhone = (TelephonyManager)context.getSystemService(Context.TELEPHONY_SERVICE);
mPhoneData = IconData.makeIcon("phone_signal",
null, com.android.internal.R.drawable.stat_sys_signal_null, 0, 0);
mPhoneIcon = service.addIcon(mPhoneData, null);
// register for phone state notifications.
((TelephonyManager)mContext.getSystemService(Context.TELEPHONY_SERVICE))
.listen(mPhoneStateListener,
PhoneStateListener.LISTEN_SERVICE_STATE
| PhoneStateListener.LISTEN_SIGNAL_STRENGTH
| PhoneStateListener.LISTEN_CALL_STATE
| PhoneStateListener.LISTEN_DATA_CONNECTION_STATE
| PhoneStateListener.LISTEN_DATA_ACTIVITY);
//实际是调用的是TelephonyRegistry.listen，此listen函数会将Iphonestatelistener添加到对应的的handler数组中，到时来了事件会轮询回调。

// data_connection
mDataData = IconData.makeIcon("data_connection",
null, com.android.internal.R.drawable.stat_sys_data_connected_g, 0, 0);
mDataIcon = service.addIcon(mDataData, null);
service.setIconVisibility(mDataIcon, false);

b、事件通知部分
==>PhoneFactory.java
makeDefaultPhones()
sPhoneNotifier = new DefaultPhoneNotifier();
useNewRIL(context);
phone = new GSMPhone(context, new RIL(context), sPhoneNotifier);

for example
==>DataConnectionTracker.java
notifyDefaultData(String reason)
phone.notifyDataConnection(reason);
mNotifier.notifyDataConnection(this, reason);
==>DefaultPhoneNotifier.java
mRegistry = ITelephonyRegistry.Stub.asInterface(ServiceManager.getService(
"telephony.registry"));
mRegistry.notifyDataConnection(convertDataState(sender.getDataConnectionState()),
sender.isDataConnectivityPossible(), reason, sender.getActiveApn(),
sender.getInterfaceName(null));

第五部分：gprs拨号上网的通路原理。
上层java程序调用gprs流程：
=>PhoneApp.java
onCreate()
PhoneFactory.makeDefaultPhones(this);
phone = new GSMPhone(context, new SimulatedCommands(), sPhoneNotifier);
mDataConnection = new DataConnectionTracker (this);
createAllPdpList();//建立缺省pdpconnection
pdp = new PdpConnection(phone);
dataLink = new PppLink(phone.mDataConnection);
dataLink.setOnLinkChange(this, EVENT_LINK_STATE_CHANGED, null);

//某个条件触发执行
trySetupData(String reason)
setupData(reason);
pdp = findFreePdp();
Message msg = obtainMessage();
msg.what = EVENT_DATA_SETUP_COMPLETE;
msg.obj = reason;
pdp.connect(apn, msg);
phone.mCM.setupDefaultPDP(apn.apn, apn.user, apn.password,
obtainMessage(EVENT_SETUP_PDP_DONE));

//收到EVENT_SETUP_PDP_DONE消息
=>pdpconnection.java
handleMessage()
case EVENT_SETUP_PDP_DONE:
dataLink.connect();//dataLink是pppLink.java
SystemService.start(SERVICE_PPPD_GPRS);//启动pppd_grps服务
poll.what = EVENT_POLL_DATA_CONNECTION;
sendMessageDelayed(poll, POLL_SYSFS_MILLIS);//启动轮询，看是否成功连接gprs
checkPPP()//每隔5秒轮询，看是否连接成功，或断开
//如果已经连接
mLinkChangeRegistrant.notifyResult(LinkState.LINK_UP);

//执行到pdpconnection.handleMessage()
case EVENT_LINK_STATE_CHANGED
onLinkStateChanged(ls);
case LINK_UP:
notifySuccess(onConnectCompleted);
onCompleted.sendToTarget();

//执行dataConnectionTracker.java的handleMessage()
case EVENT_DATA_SETUP_COMPLETE
notifyDefaultData(reason);
setupDnsProperties();
setState(State.CONNECTED);
phone.notifyDataConnection(reason);
startNetStatPoll();
resetPollStats();
1、读取发送出去的包数和接受到的包数
2、如果发送的数据包且没有收到应答包数n大于等于看门狗追踪的限定包数。
2.1、开始轮询pdp context list，尝试恢复网络连接
2.2、如果轮询24次后还没有联通网络则停止网络状态轮询，进行一次ping实验。
2.2.1、如果ping成功则，重新进行网络状态轮询，否则发送EVENT_START_RECOVERY事件。

// reset reconnect timer
nextReconnectDelay = RECONNECT_DELAY_INITIAL_MILLIS;

着重c++部分代码的角度分析
＝>DataConnectionTracker.java
trySetupData(String reason)
setupData(reason);
＝>PdpConnection.java
pdp.connect(apn, msg);
=>RIL.JAVA
phone.mCM.setupDefaultPDP(apn.apn, apn.user, apn.password,
obtainMessage(EVENT_SETUP_PDP_DONE));
send(rr);
//send socket to RIL

//enter c++ layer
=>ril.cpp
processCommandsCallback (int fd, short flags, void *param)
processCommandBuffer(p_record, recordlen);
status = p.readInt32(&request);
pRI->pCI = &(s_commands[request]);
pRI->pCI->dispatchFunction(p, pRI);
dispatchStrings();
s_callbacks.onRequest(pRI->pCI->requestNumber, pStrings, datalen, pRI);
=>reference-ril.c
onRequest();
requestSetupDefaultPDP(data, datalen, t);
err = write_at_to_data_channel("ATD*99***1#",1);

//after a while.get "connect" from data channel,so need to send socket message to java layer.
p.writeInt32 (RESPONSE_SOLICITED);
p.writeInt32 (pRI->token);//the serial No in the request list.
errorOffset = p.dataPosition();
p.writeInt32 (e);
if (e == RIL_E_SUCCESS) {
/* process response on success */
ret = pRI->pCI->responseFunction(p, response, responselen);

/* if an error occurred, rewind and mark it */
if (ret != 0) {
p.setDataPosition(errorOffset);
p.writeInt32 (ret);
}
}
sendResponse(p);
sendResponseRaw(p.data(), p.dataSize());
ret = blockingWrite(fd, (void *)&header, sizeof(header));
blockingWrite(fd, data, dataSize);

=>RIL.JAVA
RILReceiver.run();
length = readRilMessage(is, buffer);
p = Parcel.obtain();
p.unmarshall(buffer, 0, length);
p.setDataPosition(0);
processResponse(p);
processSolicited (p);
serial = p.readInt();
error = p.readInt();
rr = findAndRemoveRequestFromList(serial);
ret = responseStrings(p);
if (rr.mResult != null) {
AsyncResult.forMessage(rr.mResult, ret, null);
rr.mResult.sendToTarget();
}

=>pdpConnection.java
handleMessage()
case EVENT_SETUP_PDP_DONE:
...
dataLink.connect();
=>pppLink.java
SystemProperties.set(PROPERTY_PPPD_EXIT_CODE, "");
SystemService.start(SERVICE_PPPD_GPRS);//启动pppd_grps服务

poll.what = EVENT_POLL_DATA_CONNECTION;
sendMessageDelayed(poll, POLL_SYSFS_MILLIS);
dataConnection.state = State.CONNECTING;
handleMessage()
case EVENT_POLL_DATA_CONNECTION
checkPPP();
if (ArrayUtils.equals(mCheckPPPBuffer, UP_ASCII_STRING, UP_ASCII_STRING.length)
|| ArrayUtils.equals(mCheckPPPBuffer, UNKNOWN_ASCII_STRING,
UNKNOWN_ASCII_STRING.length)
&& dataConnection.state == State.CONNECTING)
if (mLinkChangeRegistrant != null) {
mLinkChangeRegistrant.notifyResult(LinkState.LINK_UP);
=>pdpConnection.java
handleMessage()
case EVENT_LINK_STATE_CHANGED:
DataLink.LinkState ls = (DataLink.LinkState) ar.result;
onLinkStateChanged(ls);
case LINK_UP:
notifySuccess(onConnectCompleted);
AsyncResult.forMessage(onCompleted);
onCompleted.sendToTarget();

=>DataConnectionTracker.java
handleMessage()
case EVENT_DATA_SETUP_COMPLETE:
...
SystemProperties.set("gsm.defaultpdpcontext.active", "true");
notifyDefaultData(reason);
setupDnsProperties();//设置dns，gw，我们的实现方式是在pppd中设置的，不用pppd拨号的适用。
setState(State.CONNECTED);
phone.notifyDataConnection(reason);
mNotifier.notifyDataConnection(this, reason);
＝>DefaultPhoneNotifier.java
//mRegistry = ITelephonyRegistry.Stub.asInterface(ServiceManager.getService(
"telephony.registry"));构造函数中初始化了mRegistry
mRegistry.notifyDataConnection(convertDataState(sender.getDataConnectionState()),
sender.isDataConnectivityPossible(), reason, sender.getActiveApn(),
sender.getInterfaceName(null));
startNetStatPoll();

}
第六部分：通话相关的语音通路切换原理、震动接口
6、语音通路

6.1、设置语音通路的路由

目前我们有两处处理:

a、CallTracker.java中的

handlePollCalls（）

检测到＋clcc返回的电话列表中有状态为DriverCall.State.ALERTING(表示拨打电话后，对方已经振铃)，此时需要设置语音通路为MODE_IN_CALL

 

b、PhoneUtils.java中setAudioMode（）函数

 

c、调用通路分析

AudioManager audioManager = (AudioManager) context.getSystemService

(Context.AUDIO_SERVICE);

audioManager.setMode(mode);

AudioManager.setMode(mode);

AudioService.setMode(mode);

AudioSystem.setMode(mode);（native function)

android_media_AudioSystem.cpp==>android_media_AudioSystem_setMode()

AudioSystem.cpp==>setMode()

const sp<IAudioFlinger>& af = AudioSystem::get_audio_flinger();

binder = sm->getService(String16("media.audio_flinger"));

...

gAudioFlinger = interface_cast<IAudioFlinger>(binder);

...

return gAudioFlinger;

通过查找"media.audio_flinger"发现AudioFlinger.cpp==>instantiate()//Main_mediaserver.cpp中被实例化。

defaultServiceManager()->addService(String16("media.audio_flinger"), new AudioFlinger());

mAudioHardware = AudioHardwareInterface::create();

LOGV("Creating Vendor Specific AudioHardware");

hw = createAudioHardware();

return new AudioHardwareMarvell();

 

 

return af->setMode(mode);

AudioHardwareLittle.cpp==>setMode(mode)

doRouting();

enable_incall_headphone()//or others...

system("alsactl -f /etc/alsactl/asound.state_none restore");

system("alsactl -f /etc/alsactl/asound.state_headset_r_s restore");

 

6.2、来电播放振铃,挂断或接听停止振铃。

==>Phone.app

onCreate()

ringer = new Ringer(phone);

Vibrator mVibrator = new Vibrator();

mService = IHardwareService.Stub.asInterface(ServiceManager.getService("hardware"));

notifier = new CallNotifier(this, phone, ringer, mBtHandsfree);

mPhone.registerForIncomingRing(this, PHONE_INCOMING_RING, null);

mPhone.registerForPhoneStateChanged(this, PHONE_STATE_CHANGED, null);

mPhone.registerForDisconnect(this, PHONE_DISCONNECT, null);

...

case PHONE_INCOMING_RING:

mRinger.ring();

mHardwareService.setAttentionLight(true);

mVibratorThread.start();

while (mContinueVibrating) {

mVibrator.vibrate(VIBRATE_LENGTH);

SystemClock.sleep(VIBRATE_LENGTH + PAUSE_LENGTH);

}

...

makeLooper();

mRingHandler.sendEmptyMessage(PLAY_RING_ONCE);

...

case PLAY_RING_ONCE:

PhoneUtils.setAudioMode(mContext, AudioManager.MODE_RINGTONE);

r.play();

...

case PHONE_DISCONNECT:

case PHONE_STATE_CHANGED:

...

mRinger.stopRing();

Message msg = mRingHandler.obtainMessage(STOP_RING);

msg.obj = mRingtone;

mRingHandler.sendMessage(msg);

 

case STOP_RING:

r.stop();

getLooper().quit();

...

mVibrator.cancel();
第七部分：通话相关的notification服务
7、通话相关的notification服务。

7.1、NotificationMgr

==>PhoneApp.java

onCreate()

NotificationMgr.init(this)//NotificationMgr.java//此类主要负责电话通知的具体表现（通知和取消通知），未接图标、通话中、蓝牙激活中、保持中，静音、免提等。封装了简单的瞬间显示文本消息的功能。提供漫游数据连接禁止的通知封装和漫游数据连接允许时取消通知

sMe = new NotificationMgr(context);

mNotificationMgr = (NotificationManager)

context.getSystemService(Context.NOTIFICATION_SERVICE);

mStatusBar = (StatusBarManager) context.getSystemService(Context.STATUS_BAR_SERVICE); //主要用于显示静音和speaker状态的图表（在状态条右边显示）

sMe.updateNotifications();//主要功能是：

1、查询是否有未读的未接听电话，并显示到状态栏图标，和通知列表

2、根据是否是电话状态，更新状态栏图表和通知列表（可能是激活，蓝牙，保持等）

7.2、CallNotifier

==>PhoneApp.java

onCreate()

notifier = new CallNotifier(this, phone, ringer, mBtHandsfree);//此类主要是监听通话相关的事件，然后进行例如来电播放铃声，震动。挂断、接听停止振铃等（调用Ringer类实现此功能)，根据不同的状态调用调用NotificationMgr进行具体的通知和取消通知。
第八部分： 通话相关的各种server
电话通信相关的服务：
(1)、从ServiceManager得到的：
a、wifiService
b、PhoneInterfaceManager
c、PhoneSubInfo
d、SimPhoneBookInterfaceManager
e、SimSmsInterfaceManager
f、TelephonyRegistry
g、NetStatService
h、ConnectivityService

(2)、从ApplicationContext得到的：
a、TelephonyManager