背景

今天在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