背景
今天在NotificationManagerService中去调用PendingIntent.getIntent()时发现了下面这个报错,其中pid=4901, uid=10097分别是来push平台的进程id和应用id,而PendingIntent.getIntent()这个API是@hide的,所以普通应用是无法调用的,反射也调用不到,所以后面给出的解法是针对具有系统权限的开发者的。
W System.err: java.lang.SecurityException: Permission Denial: getIntentForIntentSender() from pid=4901, uid=10097 requires android.permission.GET_INTENT_SENDER_INTENT
W System.err: at com.android.server.am.ActivityManagerService.enforceCallingPermission(ActivityManagerService.java:6291)
W System.err: at com.android.server.am.ActivityManagerService.getIntentForIntentSender(ActivityManagerService.java:5855)
W System.err: at android.app.PendingIntent.getIntent(PendingIntent.java:1135)
W System.err: at com.android.server.notification.xxx.callReplyIntent(xxx.java:64)
W System.err: at com.android.server.notification.NotificationManagerService.checkDisqualifyingFeatures(NotificationManagerService.java:5569)
W System.err: at com.android.server.notification.NotificationManagerService.enqueueNotificationInternal(NotificationManagerService.java:5193)
W System.err: at com.android.server.notification.NotificationManagerService$10.enqueueNotificationWithTag(NotificationManagerService.java:2609)
W System.err: at android.app.INotificationManager$Stub.onTransact(INotificationManager.java:1149)
W System.err: at android.os.Binder.execTransactInternal(Binder.java:1027)
W System.err: at android.os.Binder.execTransact(Binder.java:1000)
复制代码
分析
看报错的调用栈能发现是在AMS中做权限检查(ActivityManagerService.enforceCallingPermission())的时候抛的异常:
// 抛异常的代码
void enforceCallingPermission(String permission, String func) {
if (checkCallingPermission(permission)
== PackageManager.PERMISSION_GRANTED) {
return;
}
String msg = "Permission Denial: " + func + " from pid="
+ Binder.getCallingPid()
+ ", uid=" + Binder.getCallingUid()
+ " requires " + permission;
Slog.w(TAG, msg);
throw new SecurityException(msg);
}
// checkCallingPermission(),往下走就是去检查该用户是否具有android.permission.GET_INTENT_SENDER_INTENT 这个权限了
int checkCallingPermission(String permission) {
return checkPermission(permission,
Binder.getCallingPid(),
Binder.getCallingUid());
}
复制代码
可以看到抛异常是因为checkCallingPermission函数返回false了,也就是调用方push平台没有权限去调这个接口,那为什么我们明明是在NotificationManagerService(这是一个系统服务,管理通知的发送和删除等事务)中去调用这个接口的,这里却判断出来是来自push平台的呢,这里我们需要了解两个Binder相关的概念。
Binder.getCallingPid() 与 Binder.getCallingUid()
每个线程都有一个唯一的IPCThreadState对象记录着当前线程的pid和uid,而这两个id的获取就是通过Binder.getCallingPid() 与 Binder.getCallingUid()这两个方法来获取的。
当线程A通过Binder调用线程B的接口时,B线程的IPCThreadState中保存的uid和pid是线程A的uid和pid,一般我们调用这两个接口来获取线程A的id值来做权限对比。
而此时在线程B中,B是当前进程中的调用方了,若此时线程B通过Binder去调用其他方法,而其他方法又通过这两个方法去获取对应的uid和pid去做权限对比时,获取到的值就还是线程A的,所以我们需要在B通过Binder去调用其他方法前,将线程B中保存的uid和pid做一遍刷新,对于这个Binder提供了另外两个接口:
Binder.clearCallingIdentity() 与 Binder.restoreCallingIdentity(id)
long id = Binder.clearCallingIdentity()
Binder.restoreCallingIdentity(id)
其中Binder.clearCallingIdentity()会帮我们去清除当前线程中的id状态,并将结果返回给我们;而当我们执行完Binder操作后,我们需要恢复线程B中的id值,此时就需要调用Binder.restoreCallingIdentity(id)去执行这个操作。
了解完这两个概念,我们再来看看原来的问题,前面我们说过,这个接口是@hide的,只有具有系统权限的应用才能调用,那么问题就转化为,我们在这里怎么以系统的身份去调这个接口呢?这里就需要用到我们上面说的几个接口了,直接看代码吧:
final long token = Binder.clearCallingIdentity();
Intent intent;
try {
intent = pendingIntent.getIntent();
} finally {
Binder.restoreCallingIdentity(token);
}
复制代码
代码很简单,也就是在调用前利用Binder.clearCallingIdentity()将线程状态清除掉,在调用结束时利用Binder.restoreCallingIdentity(token)将线程状态恢复,这样就实现了将原来来自push平台的调用转化为NotificationManagerService的调用,而NotificationManagerService是系统服务,就可以顺利调用到了。
总结
其实这个问题是Android在7.0以上的系统中新增了相关的权限判断后才出现的(感兴趣的可以看下这笔提交),在这之后普通应用就无法调用该接口了,想要调用PendingIntent.getIntent()就必须拥有系统签名,或者像上面这个例子一样,通过Binder提供的接口,巧妙的将原来权限不足的应用的权限升级为系统权限。
本文主要想分享下上文出现的几个Binder相关函数的意义和使用场景,That'all