本文采用情景分析的方法来分析应用程序如何使用通知灯,所谓情景分析,就是抓住一条主线,只关心与我们相关的代码,忽略不相关的代码.这个方法是我从LINUX内核源代码情景分析中学到的,在此向两位前辈毛德操,胡希明致敬.

应用程序中如何使用通知灯

NotificationManager manager = (NotificationManager)getSystemService(NOTIFICATION_SERVICE);

Notification notification = new NotificationCompat.Builder(this)

notification.ledARGB = Color.GREEN;// 控制 LED 灯的颜色，一般有红绿蓝三种颜色可选

notification.ledOnMS = 1000;// 指定 LED 灯亮起的时长，以毫秒为单位

notification.ledOffMS = 1000;// 指定 LED 灯暗去的时长，也是以毫秒为单位

notification.flags = Notification.FLAG_SHOW_LIGHTS;// 指定通知的一些行为，其//中就包括显示LED 灯这一选项

manager.notify(1, notification)

首先可以看到应用程序中首先获得一个系统服务NOTIFICATION_SERVICE,然后构造一个notification,其中就包括了对led闪烁条件的初始化,最后调用manager.notifi将通知发出去.

Framework中如何调用

那就先看看NOTIFICATION_SERVICE服务是在哪里注册的,搜索它.可以看到在ContextImpl.java中注册了NOTIFICATION_SERVICE.我查看的代码是Android L,Android M有些许不同,但大同小异.

registerService(NOTIFICATION_SERVICE, new ServiceFetcher() {

public Object createService(ContextImpl ctx) {

final Context outerContext = ctx.getOuterContext();

return new NotificationManager(

new ContextThemeWrapper(outerContext,

Resources.selectSystemTheme(0,

outerContext.getApplicationInfo().targetSdkVersion,

com.android.internal.R.style.Theme_Dialog,

com.android.internal.R.style.Theme_Holo_Dialog,

com.android.internal.R.style.Theme_DeviceDefault_Dialog,

com.android.internal.R.style.Theme_DeviceDefault_Light_Dialog)),

ctx.mMainThread.getHandler());

}});

这段代码是在ContextImpl.java中的静态代码块中,也就是说它会是这个文件中最先执行的部分.再来看看registerService具体是如何实现的.

private static void registerService(String serviceName, ServiceFetcher fetcher) {

if (!(fetcher instanceof StaticServiceFetcher)) {

fetcher.mContextCacheIndex = sNextPerContextServiceCacheIndex++;

}

SYSTEM_SERVICE_MAP.put(serviceName, fetcher);

}

可以看到这个函数会把我们上面传进去的匿名类ServiceFetcher放入一个Hash Map.放入哈希表后,下次就可以根据serviceName来取fetcher.也就是应用程序中getSystemService来获取服务的过程

public Object getSystemService(String name) {

ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name);

return fetcher == null ? null : fetcher.getService(this);

}

这里获得了一个fetcher并调用它的getService函数.这里的fetcher就是我们前面注册时传入的匿名类.看看fetcher实现.

static class ServiceFetcher {

public Object getService(ContextImpl ctx) {

...

//这里只保存了关键代码

service = createService(ctx);

cache.set(mContextCacheIndex, service);

return service;

}

}

这里会调用service的createService函数,而上面定义的createService会返回一个NotificationManager实例.

所以getSystemService会返回NotificationManager实例.

接先来再看看应用程序中的manager.notify是如何实现的.

//NotificationManager.java

public void notify(String tag, int id, Notification notification)

{

INotificationManager service = getService();

...

try {

service.enqueueNotificationWithTag(pkg, mContext.getOpPackageName(), tag, id,stripped, idOut, UserHandle.myUserId());//这里涉及到Binder远程调用

}

} catch (RemoteException e) {

}

}

看下getService函数实现

static public INotificationManager getService()

{

if (sService != null) {

return sService;

}

IBinder b = ServiceManager.getService("notification");

sService = INotificationManager.Stub.asInterface(b);

return sService;

}

看到这里就需要对Android的Binder机制比较了解才行了,后面我会陆续推出讲解Binder机制的文章,也不知道有没有人看哈,没人看也没关系,反正就当给自己工作学习过程留个记录,(^__^) 嘻嘻……

回归正题,我们来看看”notification”是在哪里注册的.

//SystemServer.java

mSystemServiceManager.startService(NotificationManagerService.class);

//startService会调用NotificationManagerService的onStart函数

publishBinderService(Context.NOTIFICATION_SERVICE, mService);//这里就把'notification'服务注册进去了.

来看看mService里面有什么.

private final IBinder mService = new INotificationManager.Stub(){

...

public void enqueueNotificationWithTag(String pkg, String opPkg, String tag, int id,

Notification notification, int[] idOut, int userId) throws RemoteException {

enqueueNotificationInternal(pkg, opPkg, Binder.getCallingUid(),

Binder.getCallingPid(), tag, id, notification, idOut, userId);

}

...

}

再来看看enqueueNotificationInternal函数

/*和Led操作相关的*/

buzzBeepBlinkLocked(r);

/*然后会调用到*/

updateLightsLocked();

/*进而调用到*/

mNotificationLight.setFlashing(ledARGB, Light.LIGHT_FLASH_TIMED,ledOnMS, ledOffMS);

那mNotificationLight是谁,以及setFlashing是如何实现的呢?

final LightsManager lights = getLocalService(LightsManager.class);

mNotificationLight = lights.getLight(LightsManager.LIGHT_ID_NOTIFICATIONS);

lights是从一个ArrayMap里面get到的,那在哪里put的呢,可以搜索’LightsManager.class’发现

//LightsService.java

public void onStart() {

publishBinderService("hardware", mLegacyFlashlightHack);

publishLocalService(LightsManager.class, mService);

}

在LightsService.java里面会注册本地服务.LightsService就实现了上面的setFlashing函数

@Override

public void setFlashing(int color, int mode, int onMS, int offMS) {

synchronized (this) {

setLightLocked(color, mode, onMS, offMS, BRIGHTNESS_MODE_USER);

}

}

private void setLightLocked(int color, int mode, int onMS, int offMS, int brightnessMode) {

if (color != mColor || mode != mMode || onMS != mOnMS || offMS != mOffMS) {

if (DEBUG) Slog.v(TAG, "setLight #" + mId + ": color=#"

+ Integer.toHexString(color));

mColor = color;

mMode = mode;

mOnMS = onMS;

mOffMS = offMS;

Trace.traceBegin(Trace.TRACE_TAG_POWER, "setLight(" + mId + ", " + color + ")");

try {

setLight_native(mNativePointer, mId, color, mode, onMS, offMS, brightnessMode);

} finally {

Trace.traceEnd(Trace.TRACE_TAG_POWER);

}

}

终于看到setLight_native函数了,它在JNI层.

JNI层中操作LED

JNI层其实也只是一层过渡,它向上为JAVA层提供操作硬件的接口,向下调用HAL层,然后在HAL层中具体操作硬件.

static void setLight_native(JNIEnv *env, jobject clazz, jlong ptr,

jint light, jint colorARGB, jint flashMode, jint onMS, jint offMS, jint brightnessMode)

{

Devices* devices = (Devices*)ptr;

light_state_t state;

if (light < 0 || light >= LIGHT_COUNT || devices->lights[light] == NULL) {

return ;

}

memset(&state, 0, sizeof(light_state_t));

state.color = colorARGB;

state.flashMode = flashMode;

state.flashOnMS = onMS;

state.flashOffMS = offMS;

state.brightnessMode = brightnessMode;

{

ALOGD_IF_SLOW(50, "Excessive delay setting light");

devices->lights[light]->set_light(devices->lights[light], &state);

}

其实JNI层,没什么好说的,主要是通过硬件访问服务来操作硬件,关于硬件访问服务,可以看我以前写的博文.