Android 4.0 Alarm机制浅析

Android 4.0 Alarm机制浅析
Author: VIC.LUO@CELLON.COM

最近在做关于Alarm的一些东西，所以就把Android平台上的alarm的源代码给稍微看了看。我个人其实基本不写文档的，而且即使写，也不过区区数字，这个应该是我工作4年来的第二篇文档（第一篇是写的和我一直以来工作相关的Messaging）所以内容上和排版上大家就不要见怪。
Android系统中alarm机制最大的体现着就是闹钟这个app了。通过这个应用我们可以设置自己的各种定时闹钟，当然系统中的各种定时相关功能的实现也基本全部依赖Alarm机制。
闹钟的代码在packages\apps\DeskClock\src\com\android\deskclock目录下，可以自行查看，这里主要说的是Alarm机制。

Alarm机制实现的代码主要在
./frameworks/base/core/java/android/app/AlarmManager.java

./frameworks/base/services/java/com/android/server/AlarmManagerService.java

./frameworks/base/services/jni/com_android_server_AlarmManagerService.cpp

再往下就是驱动和kernel的代码，个人对驱动和kernel的代码不了解，就不说了。

AlarmManager是framework中提供给用户来使用的API，其实现在AlarmManagerService，为一个server，通过binder机制来提供服务，开机便注册到system_server进程中（所有server实现基本都如此）代码如下（systemserver.java）
alarm = new AlarmManagerService(context);
ServiceManager.addService(Context.ALARM_SERVICE, alarm);

下面就来介绍一下AlarmManagerService，本来想用ams代替，不过一般情况下ams指的是ActivityManagerService，所以也就罢了。

AlarmManagerService的初始化：

1. mDescriptor = init();
打开设备驱动，其jni实现为（com_android_server_AlarmManagerService.cpp）
static jint android_server_AlarmManagerService_init(JNIEnv* env, jobject obj)
{
return open("/dev/alarm", O_RDWR);
}

2. 设置时区
String tz = SystemProperties.get(TIMEZONE_PROPERTY);
if (tz != null) {
setTimeZone(tz);
}

3. mTimeTickSender 这个pendingintent的作用应该是系统中经常用到的，它是用来给发送一个时间改变的broadcast，Intent.ACTION_TIME_TICK，每整数分钟的开始发送一次，就是每分钟的开始就发送，应用可以注册对应的receiver来干各种事，譬如更新时间显示等等，具体怎么触发的稍后再说。

mDateChangeSender 这个pendingintent的作用是啥？代码中时这样写的Intent.ACTION_DATE_CHANGED，其实和mTimeTickSender 差不多，只是它是每天的开始发送一次，应该就是00:00:00发送吧

这2个pendingintent 和ClockReceiver有莫大的关系，ClockReceiver的构造函数如下
public ClockReceiver() {
IntentFilter filter = new IntentFilter();
filter.addAction(Intent.ACTION_TIME_TICK);
filter.addAction(Intent.ACTION_DATE_CHANGED);
mContext.registerReceiver(this, filter);
}
同时alarmmanagerservice中还有如下代码
mClockReceiver.scheduleTimeTickEvent();

mClockReceiver.scheduleDateChangedEvent();
深入scheduleTimeTickEvent 和scheduleDateChangedEvent你就可以知道上面2个pendingintent的作用了



同时ClockReceiver也能收到这2个intent，说明时间变了，立刻set下一次alarm，以便系统不停的发送该消息。



4. mUninstallReceiver 这个还真暂时太不清楚它的作用。貌似和应用的安装和卸载有比较大的关系。

5. registerReceiver（我就不说这个receiver名字起得太2了），看他的intent filter
mIntentFilter.addAction(UNREGISTER_POWEROFF_CLOCK);
mIntentFilter.addAction(REGISTER_POWEROFF_CLOCK);
我们可以得知，这个是给应用来注册POWEROFF_CLOCK的，也就是关机闹钟啦，这个貌似是4.0新加的功能，不知道是qualcomm实现的还是google新添加的代码。
它允许用户注册关机闹钟的权限，在关机情况下，当时间到了以后（可能会提前2分钟 什么的），系统会先开机，然后执行你注册的pendingintent。貌似你需要在 Intent 中设置extra，extra（POWEROFF_CLOCK_INTENT_EXTRA）内容为package的名字。
如果你的应用没有通过REGISTER_POWEROFF_CLOCK去注册这个权限的话，那么应用是不会在关机时候去开机执行的。这里的注册只是类似于权限的注册，闹钟设置还是需要调用set去实现。
问题：如果关机后开机，那先前设置的闹钟或者先前设置的alarm（不是指闹钟这个应用，是指定时任务）你认为还有效么？why？

6. mWaitThread.start() （AlarmThread）
这个应该是AlarmManagerService中最重要的部分了，整个server的执行线程，跑在一个while死循环里面。具体实现了哪些功能以及怎么实现的，后面具体讲到

至此，初始化完毕了。下次就看看AlarmThread 这个用来支撑Alarm机制实现的线程，来看看它是怎么运作的。

AlarmThread的具体流程：

1. 首先，int result = waitForAlarm(mDescriptor); 这个我个人理解其作用就是等待一个底层RTC闹钟的触发，这个过程应该是同步阻塞的。
如果result & TIME_CHANGED_MASK，那么首先remove(mTimeTickSender);然后重新设置mClockReceiver.scheduleTimeTickEvent();就是重新设置scheduleTimeTickEvent这个pendingintent了；然后给系统发送一个ACTION_TIME_CHANGED的broadcast，当然接受者是有Intent.FLAG_RECEIVER_REPLACE_PENDING 和Intent.FLAG_RECEIVER_REGISTERED_ONLY_BEFORE_BOOT的限制。

2. 针对各种情况的MASK RTC_WAKEUP_MASK| RTC_MASK| ELAPSED_REALTIME_WAKEUP_MASK| ELAPSED_REALTIME_MASK，对此进行
triggerAlarmsLocked(ArrayList<Alarm> alarmList, ArrayList<Alarm> triggerList,
long now)

3. 我们就来分析下triggerAlarmsLocked 这个函数的作用。
AlarmManager中定义了4种类型的alarm ：RTC_WAKEUP |RTC ELAPSED_REALTIME_WAKEUP
| ELAPSED_REALTIME，所以在service中定义了4个ArrayList<Alarm> 来对应4中类型的alarmmRtcWakeupAlarms|mRtcAlarms；mElapsedRealtimeWakeupAlarms|mElapsedRealtimeAlarms；当应用调用AlarmManager.set接口去设置alarm，随后就会调用到service中的addAlarmLocked，其根据alarm类型将其add到对应的ArrayList中去。

首先来判断alarm是否到期了，如果还没有到期，直接跳出整个while循环（大家注意这里alarmList是个arraylist，同时其在add的时候对其进行了按照alarm.when从小到大来排序，所以如果alarm.whe>now,那么后面的alarm.when必定> now）；

if (alarm.when > now) {
// don't fire alarms in the future
break;
}
在while里面，我们逐一的找出alarm.when <=now的alarm，将其add到triggerList（triggerList.add(alarm);）中传出去，以便后用；同时将其从alarmList中remove掉。这里面还有一个alarm.count，看说明大家就知道其中的意思了： （this adjustment will be zero if we're late by，less than one full repeat interval），就是说闹钟过期了多少个间隔时间段，计算方法：时间差/间隔 + 1

alarm.count += (now - alarm.when) / alarm.repeatInterval 如果是重复的alarm，那么将其保存在repeats这个arraylist中。

// if it repeats queue it up to be read-added to the list

if (alarm.repeatInterval > 0) {

repeats.add(alarm);
遍历完了alarmList之后，做2件事：
①：把repeats 这个arraylist中的重复响的闹钟计算出新的alarm，将其add到alarm对应的arraylist中去。
②：setLocked，将alarmList中最近的一个闹钟（其按照从小到大排列，故第一个就是最小的）set到系统中去。
好了，这个函数的作用分析完了。简而言之，这个函数作用就是找出对应alarmlist中到期的alarm，将其取出来；同时将重复的alarm计算出新的alarm添加到对应的list中，然后set最近时间的alarm。

4. 执行完triggerAlarmsLocked后，我们得到了需要进行操作的triggerList，逐一取出，随后就开始了最为重要的一部分
alarm.operation.send(mContext, 0,
mBackgroundIntent.putExtra(
Intent.EXTRA_ALARM_COUNT, alarm.count),
mResultReceiver, mHandler);
将pendingintent发送出去，这样，先前注册alarm到期时所期望做的的操作这个时候就开始执行了。

AlarmThread的执行流程就是这样，它一直重复的等待着底层alarm到期，然后从列表中取出到期的alarm，逐一对pendingintent进行send操作，直到系统挂了为止。

AlarmManagerService中重要的操作：

1. set/setRepeating：设置（重复的）alarm
外部如果需要设置一个alarm来进行某些操作，一般流程都是
manager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
manager.set(AlarmManager.RTC_WAKEUP, time, pi);
一般都会用AlarmManager这个代理类来进行对应的操作，其实质会调用到AlarmManagerService中的set/setRepeating函数，当然set其实也是调用setRepeating，所以我们就来看看setRepeating这个函数

setRepeating(int type, long triggerAtTime, long interval, PendingIntent operation)，这个函数有4个参数，其中大家要注意的是triggerAtTime和type要对应起来，我们用RTC_WAKEUP和RTC的时候，就要对应系统的绝对时间（System.currentTimeMillis()得到）；而用ELAPSED_REALTIME_WAKEUP和ELAPSED_REALTIME的时候，就要对应系统的相对时间（相对开机流逝了多少时间通过SystemClock.elapsedRealtime()得到），interval来表示间隔interval时间间隔重复该alarm，operation就是alarm到期后你要进行的操作。

①：创建一个Alarm来组织传进来的数据，随后进行的这一步大家要稍微注意：
// Remove this alarm if already scheduled.
removeLocked(operation);
该函数会从type对应的alarm arraylist中remove掉此operation（pendingintent）对应的alarm，其中匹配规则为alarm.operation.equals(operation)，也就是pendingintent的equal函数。所以这个大家可能要注意，因为如果你在一个app中不同的地方new pendingintent的时候的参数都一样的话，那么new出来的pendingintent通过pendingintent.equal来比较的话是相等的，也就是说你这个时候不能通过一般途径来设置2个alarm，因为这个时候会把前一个alarm移除掉，具体可以参见pendingintent.equal()以及pendingintent.mTarget怎么创建的，其实就是比较mTarget是否相等，如果你要设置2个alarm的话，就要用不同的requestcode或者intent。

②：执行完remove后，开始执行
index = addAlarmLocked(alarm);
此函数的作用首先通过Collections.binarySearch(alarmList, alarm, mIncreasingTimeOrder)将此alarm定位出其在alarmlist（此arraylist为按照alarm.when从小到大排列）的位置index，然后将该alarm添加到对应的alarm arraylist中去 ：alarmList.add(index, alarm)；同时返回该index（后面还要用）。

③：接下来，会去判断调用set的app是否为系统自带的闹钟或者是在系统中注册了power_off_clock权限的app（alarmmanagerservice初始化中讲到过），如果是，并且alarm.type == AlarmManager.RTC_WAKEUP，那么newType = RTC_DEVICEUP。
接着看：if (index == 0 || newType == RTC_DEVICEUP) { setLocked(alarm); }
也就是说如果该alarm是最进将要触发的alarm（index =0）或者有power_off_clock权限的alarm，那么将立刻执行setLocked操作，也就是设置到系统底层RTC时钟中去。

setLocked函数中同样也有关于power_off_clock权限的检测，代码如下
String callingPackage = mContext.getPackageManager().getNameForUid(Binder.getCallingUid());
if (SELF_CLOCK.equals(callingPackage) && alarm.type == AlarmManager.RTC_WAKEUP) {
type = RTC_DEVICEUP;
}
SharedPreferences mSharedPref = mContext.getSharedPreferences("power_off_clock", 0);
if (mSharedPref.contains(callingPackage) && alarm.type == AlarmManager.RTC_WAKEUP) {
type = RTC_DEVICEUP;
}

随后就会通过jni调用底层的set函数，这里不多说。

2. remove：取消alarm
取消一个alarm的流程那就太simple了，直接removeLocked(operation)，这个过程在和set中remove相同。通过pendingintent.equal来确定2个alarm是否相等。

3. setTime：设置系统时间
该功能需要android.permission.SET_TIME，需要注意。

4. setTimeZone：设置系统时区
该功能需要android.permission. SET_TIME_ZONE，需要注意。

疑问：
1.关机alarm问题
在初始化分析中，提出了这样一个问题：如果关机后开机，那先前设置的闹钟或者先前设置的alarm（不是指闹钟这个应用，是指定时任务）你认为还有效么？why？
有人觉得有效，因为闹钟不就是个很好的例子么？也有人说无效，因为自己set一个alarm，重启到时间后对应的pendingintent并没有执行。那么到底是有效还是无效呢？在这里，我很负责任（个人责任）的告诉大家，是无效的。
Why？
其实我们set alarm最终调用的是jni层的set函数，看看这个函数的参数 set(int fd, int type, long seconds, long nanoseconds)；我们很容易发现并没有将pendingintent保存起来，pendingintent只是保存在arraylist中Alarm结构体中，同时重启后，先前arraylist的数据并没有保存到固化空间上，全部都丢失掉了，所以重启后刚开始的arraylist是空的。那么你以前设置的alarm显然就无效啦。
那为什么系统的闹钟有效呢？带着这个问题我问了一些同事，但是没有什么发现。最后我在闹钟的app中发现了这个Receiver：AlarmInitReceiver，



看到这里，你明白了吧？闹钟这个app接收了开机完成事件，然后将其保存在数据库中的alarm数据重新set到AlarmManagerService（具体看AlarmInitReceiver.java），所以闹钟关机重启还有效。

如果你的程序需要设置定时任务，并且不管系统是否关机重启等，那么你就可以仿照闹钟注册开机完成（BOOT_CVOMPLETED）事件，重新set alarm（其实我是偶然看到SMP同事写的定时信息feature想到的这个问题，鉴定重启后果然不能定时发送）。

2.pendingintent 比较问题
由于在set和remove alarm的时候都会执行removeLocked(operation)的操作，其中涉及到pendingintent的比较问题，pendingintent.equal函数比较2个pendingintent其实只是比较2个pendingintent的mTarget，所以即使2个pendingintent不相等，但是pendingintent .equal确实相等。
PendingIntent p1 = PendingIntent.getBroadcast(this, 0, new Intent("test1"), 1);
PendingIntent p2 = PendingIntent.getBroadcast(this, 0, new Intent("test1"), 1);
此时　p1 != p2,但是p1.equals(p2) == true。
所以大家需要设置不同的alarm的时候，new PendingIntent时候需要注意用不同的参数，requestCode，intent，flags 有一个不同即可。
注意 :如果Flag是FLAG_CANCEL_CURRENT的话，那么不管怎么样，p1.equals(p2) == false。
注意影响PendingIntent相等的参数就是这个key：





（这里的意思是这3个Flag在key中不起作用）
如果Flag中有FLAG_CANCEL_CURRENT的话，那么将会执行：


以及



所以就会造成不相等的情况。
这里就有一个很严重的问题了啊，既然用了FLAG_CANCEL_CURRENT，那么为什么我先前设置了一个10点钟的闹钟，再去取消的时候，为什么能够取消？不是上面刚说了2个pendingintent不相等吗？这个问题我断断续续看了很长时间，今天给别人讲闹钟的设置取消和AlarmManagerService的时候才总算是弄明白了。
让我们来看一下取消闹钟的代码



先去得到一个pendingintent，大家可要注意啊，这个sender和我们设置闹钟时候得到的sender不相等啊，并且其中的mTarget对象也不相等啊，真是急死人。都不相等了，你还去am.set,am.cancel有什么作用？我可以负责任的告诉大家，这2个函数在这里完全是打酱油的作用，完全可以去掉。为什么android的源代码这样设计，估计也是为了我们自己看着这样可以cancel掉吧。
Set我就不讲了，我们来看看cancel，最终调用的是AlarmManagerService的remove函数



OMG，就是想从4个列表中remove掉和传进去的sender相等的pendingintent对应的alarm，关键是这个sender不和其中任何一个相等啊，因为你用了这个该死的FLAG啊亲FLAG_CANCEL_CURRENT，所以我说这2行代码完全可以去掉。这2行代码本意是好的，想去remove掉对应的alarm，可以效果你懂的，哎，大家不信可以去跟跟断点，打打log，或者dumpsys alarm看看alarm的信息即可。
既然这2行代码没有去remove掉这个alarm，那为什么我咱闹钟中取消某个闹钟后，起作用了呢。这个得从pendingintent的创建说起了。当我们设置了FLAG_CANCEL_CURRENT之后，然后想去get到一个pendingintent，具体的实现代码在AMS中的getIntentSenderLocked这个函数，上面已经讲了一部分，当我们设置了该FLAG后，将会执行
：



请着重注意

这行代码，因为这个值在pendingintent触发的时候起到至关重要的作用，我们看看在AlarmManagerService中的当一个alarm时间到了，便会触发下面的操作：



也就是pendingintent的send操作，最终会调用到PendingIntentRecord的send操作(具体是sendInner，不要问我为什么，不懂的可以去看下binder机制），请大家睁大眼睛啊：



各种操作



看清楚没有啊亲，也就是说你先前设置的pendingintent虽然在AlarmManagerService中，但是走到send的时候其实是什么操作都没做啊，所以这个就是为什么闹钟不响了啊。
OK，AlarmManagerService浅析就差不多这些了。

OVER了，如果你对此有什么疑问或者见解，那么可以和我一起讨论。此文纯个人理解，有错误在所难免，所以请大家切勿轻信，欢迎指正（VIC.LUO@CELLON.COM）。