彭丑丑

V1

2022/07/21阅读:25主题:山吹

Android 面试题:说一下 PendingIntent 和 Intent 的区别

请点赞,你的点赞对我意义重大,满足下我的虚荣心。

🔥 Hi,我是小彭。本文已收录到 GitHub · Android-NoteBook 中。这里有 Android 进阶成长知识体系,有志同道合的朋友,关注公众号 [彭旭锐] 跟我一起成长。

前言

  • 从字面意思上理解,PendingIntent 是一种延迟的 Intent,表示一种延迟执行的意图操作。对,但又不完全对。 一句话概括,PendingIntent 一种是支持授权其他应用以当前应用的身份执行包装的 Intent 操作的系统特性。
  • 在这篇文章里,我将带你理解 PendingIntent 的使用方法、设计理念以及核心源码分析,相信阅读完这篇文章后你对 PendingIntent 的理解将超过绝大部分同学。如果能把帮上忙,请务必点赞加关注,你的支持对我非常重要。

1. 认识 PendingIntent

1.1 为什么要使用 PendingIntent?

PendingIntent 的应用场景关键在于间接的 Intent 跳转需求, 即先通过一级 Intent 跳转到某个组件,在该组件完成任务后再间接地跳转到二级的 Intent。PendingIntent 中的单词 “pending” 指延迟或挂起,就是指它是延迟的或挂起的。例如,你在以下场景中就可以使用 PendingIntent:

  • 场景 1 - 系统通知消息的点击操作
  • 场景 2 - 桌面微件的点击操作
  • 场景 3 - 系统闹钟操作
  • 场景 4 - 第三方应用回调操作

可以看到,在这些场景中,我们真正感兴趣的操作是挂起的,并且该操作并不是由当前应用执行,而是由某个外部应用来 “间接” 执行的。例如,我们在发送系统通知消息时,会通过 PendingIntent 构造一个系统通知 Notification ,并调用 NotificationManagerCompat.notify(…) 发送通知,此时并不会直接执行 PendingIntent。而是当系统显示通知,并且用户点击通知时,才会由系统通知这个系统应用间接执行 PendingIntent#send() ,而不是通过当前应用执行。

当然,在低版本系统中,你还可以使用嵌套 Intent(Intent#extra 中嵌套另一个 Intent)来实现以上需求。但是从 Android 12 开始,嵌套 Intent 将被严格禁止,原因下文会说。

1.2 PendingIntent 和 Intent 有什么区别?

从结构上来说,PendingIntent 是 Intent 的包装类,其内部持有一个代表最终意图操作的 Intent(事实上,内部是通过 IIntentSender 间接持有)。它们的区别我认为可以概括为 3 个维度:

  • 1、执行进程不同 —— PendingIntent 在其他进程执行: Intent 通常会在创建进程中执行,而 PendingIntent 通常不会在创建进程中执行;
  • 2、执行时间不同 —— PendingIntent 会延迟执行: Intent 通常会立即执行,而 PendingIntent 通常会延迟执行,延迟到其他进程完成任务后再执行,甚至延迟到创建进程消亡后。例如,在 场景 1 - 系统通知消息的点击操作 中,即使发送系统通知消息的进程已经消亡了,依然不妨碍二级 Intent 的跳转;
  • 3、执行身份不同 —— PendingIntent 支持授权: PendingIntent 内部持有授权信息,支持其他应用以当前应用的身份执行,这有利于避免嵌套 Intent 存在的安全隐患。而直接使用 Intent 的话,一般只能以当前应用的身份执行(为什么说一般?因为有 Activity#startActivityAsUser() 这个 API,但一般你拿不到所需的参数)。

提示: 当然了,如果你创建 PendingIntent 后又马上同步地在当前进程消费这个 PendingIntent,那么时间维度上就没区别了。但是这样做其实不符合 PendingIntent 的应用场景。

1.3 嵌套 Intent 存在的安全隐患

上文提到,在低版本系统中,你可以使用嵌套 Intent 实现类似于 PendingIntent 的需求。但这一方案从 Android 12 开始被严格禁止,为什么呢 —— 存在安全隐患。

举个例子,我们将启动 ClientCallbackActivity 的 Intent 嵌套到启动 ApiService 的 Intent 里,实现一个 场景 4 - 第三方应用回调操作 的效果:

  • 步骤 1: Client App 请求 Provider App 的一个服务(这通过一级 Intent 实现);
  • 步骤 2: Provider App 在任务结束后回调到 Client App 的 ClientCallbackActivity(这通过嵌套的二级 Intent 实现)。

该过程用示意图表示如下:

乍看起来没有问题,但其实存在 2 个隐蔽的安全隐患:

  • 隐患 1 - Client App: 由于 ClientCallbackActivity 是从另一个应用 Provider App 启动的,因此该 Activity 必须暴露为 exported。这意味着除了 Provider App 可以启动该 Activity 外,同时也给了恶意应用启动该 Activity 的可能性。如果 ClientCallbackActivity 是一个普通的 Activity 还要说,要是 ClientCallbackActivity 是一个敏感或高风险的行为(例如支付回调),那么这就存在很大的安全隐患了;
  • 隐患 2 - Provider App: 由于嵌套的 Intent 是在 Provider App 的上下文中启动的,那么二级 Intent 不仅可以正常启动 Client App 中的 ClientCallbackActivity(打开 exported 时),还可以启动 Provider App 中任意 Activity。这意味着给了恶意应用启动 Provider App 中敏感或高风险的 Activity 的可能性,即使这个敏感的 Activity 事先已经关闭 exported。这说明 exported 机制失效了,也存在很大的安全隐患。

该攻击过程用示意图表示如下:

解决方法是使用 PendingIntent 代替嵌套 Intent,此时这两个风险都不存在。为什么呢?—— 因为 PendingIntent 将以 Client App(PendingIntent 的创建进程)的身份执行,而不是 Provider App (PendingIntent 的消费进程)的身份执行。

现在,我们再回顾下还有没有安全隐患:

  • 隐患 1 - Client App: 由于 PendingIntent 使用 Client App 的身份执行,那么 ClientCallbackActivity 不再需要暴露为 exported。此时,恶意应用不存在常规启动 ClientCallbackActivity 的可能性,风险解除;
  • 隐患 2 - Provider App: 由于 PendingIntent 使用 Client App / Attacker App 的身份执行,而它们是没有权限访问 Provider App 非 exported 的 ApiSensitiveActivity 的。此时,恶意应用不能启动 ApiSensitiveActivity,风险解除。

该过程用示意图表示如下:

提示: 担心有的同学钻牛角这里再补充以下:如果我的二级 Intent 就是想要回调到 Provider App 中的 ApiSensitiveActivity 那怎么办?很简单,说明 Client 并不关心回调,那么就直接使用 Intent 即可,Provider App 内部的回调行为交给其内部处理。


2. PendingIntent 的使用方法

2.1 创建 PendingIntent

PendingIntent 支持在启动 Activity、Service 或 BroadcastReceiver。不同类型的组件必须使用特定的静态方法:

示例程序

// 启动 Activity
PendingIntent.getActivity(Context context, int requestCode, Intent intent, int flags)
// 启动 Service
PendingIntent.Service(Context context, int requestCode, Intent intent, int flags)
// 启动 BroadcastReceiver(发送广播)
PendingIntent.getBroadcast(Context context, int requestCode, Intent intent, int flags)

创建 PendingIntent 后,就可以将 PendingIntent 发送给其他应用,例如发送到系统通知消息:

示例程序

// 通知构造器
NotificationManagerCompat compat = NotificationManagerCompat.from(context);
NotificationCompat.Builder builder = null;
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    builder = new NotificationCompat.Builder(context, CHANNEL_ID);
else {
    builder = new NotificationCompat.Builder(context);
}
...
// 设置 PendingIntent
builder.setContentIntent(pendingIntent);
// 构造通知
Notification notification = builder.build()
// 发送通知
compat.notify(NOTIFICATION_TAG, NOTIFICATION_ID, notification);

简单说明下创建 PendingIntent 的 4 个参数:

  • 1、context: 当前应用的上下文,PendingIntent 将从中抽取授权信息;
  • 2、requestCode: PendingIntent 的请求码,与 Intent 的请求码类似;
  • 3、intent: 最终的意图操作;
  • 4、flag: 控制标记位,我们暂且放到一边。

创建 PendingIntent 时有一个容易犯错的地方需要注意:重复调用 PendingIntent.getActivity() 等创建方法不一定会返回新的对象,系统会基于两个要素判断是否需要返回相同的 PendingIntent:

  • 要素 1 - requestCode: 不同的 requestCode 会被认为不同的 PendingIntent 意图;
  • 要素 2 - Intent: 不同的 Intent 会被认为不同的 PendingIntent 意图,但并不是 Intent 中所有的参数都会参与计算,而是仅包含 Intent.filterEquals() 方法考虑的参数,即:action、data、type、identity、class 和 categories,但不包括 extras。

2.2 消费 PendingIntent

上面提到 PendingIntent 是 Intent 的嵌套类,那么在消费 PendingIntent 时是否可以从中取出嵌套的 Intent 再执行 startActivity 之类的方法呢?NO!消费 PendingIntent 的方法只能使用 PendingIntent#send() 相关重载方法。例如:

PendingIntent.java

public void send() throws CanceledException {
    send(null0nullnullnullnullnull);
}

public void send(Context context, int code, @Nullable Intent intent) throws CanceledException {
    send(context, code, intent, nullnullnullnull);
}

关于 send() 内部的实现原理,我们在下一节原理分析中再说。

2.3 取消 PendingIntent

调用 PendingIntent#cancel() 方法可以取消已经创建的 PendingIntent,该方法将从系统中移除已经注册的 PendingIntent(事实上,是移除 IIntentSender)。如果后续继续消费这个已经被取消的 PendingIntent,将抛出 CanceledException 异常。

PendingIntent.java

private final IIntentSender mTarget;

public void cancel() {
    ActivityManager.getService().cancelIntentSender(mTarget);
}

2.4 可变性与不可变性

PendingIntent 可变性是一种对外部应用消费行为的约束机制,通过标记位 FLAG_MUTABLEFLAG_IMMUTABLE 控制 PendingIntent 可变或不可变。例如:

示例程序

// 创建可变 PendingIntent
val pendingIntent = PendingIntent.getActivity(applicationContext, NOTIFICATION_REQUEST_CODE, intent, PendingIntent.FLAG_MUTABLE)

// 创建不可变 PendingIntent
val pendingIntent = PendingIntent.getActivity(applicationContext, NOTIFICATION_REQUEST_CODE, intent, PendingIntent.FLAG_IMMUTABLE)

那么,可变性意味着什么呢?可变性意味着在消费 PendingIntent 时,可以针对其中包装的 Intent 进行修改,即使用 PendingIntent#send(Context, int, Intent) 进行修改。需要注意的是,这里的 Intent 参数并不会完全替换 PendingIntent 中包装的 Intent,而是将修改的信息填充到原有的 Intent 上。

源码摘要

// send() 内部通过 Intent#fillIn() 修改 Intent,而不是替换 Intent

// PendingIntent#send() 最终执行到:
int changes = finalIntent.fillIn(intent, key.flags);

例如,以下为修改可变 PendingIntent 示例:

示例程序

val intentWithExtrasToFill = Intent().apply {
    putExtra(EXTRA_CUSTOMER_MESSAGE, customerMessage)
}
mutablePendingIntent.send(applicationContext, PENDING_INTENT_CODE, intentWithExtrasToFill)

// 至此,PendingIntent 内部包装的 Intent 将持有 EXTRA_CUSTOMER_MESSAGE 信息

另外,PendingIntent 可变性的注意事项:

  • 注意事项 1 - 修改不可变 PendingIntent: 即使是不可变的 PendingIntent 类型,创建 PendingIntent 的应用总是可以修改,因为可变性只是对外部应用消费行为的约束。例如:

修改示例

// 创建不可变 PendingIntent
val pendingIntent = PendingIntent.getActivity(applicationContext, NOTIFICATION_REQUEST_CODE, intent, PendingIntent.FLAG_IMMUTABLE)

// 在当前应用修改不可变 PendingIntent,需要使用 PendingIntent.FLAG_UPDATE_CURRENT 标记位
val updatedPendingIntent = PendingIntent.getActivity(applicationContext, NOTIFICATION_REQUEST_CODE, anotherIntent, PendingIntent.FLAG_IMMUTABLE or PendingIntent.FLAG_UPDATE_CURRENT)
  • 注意事项 2 - 显式指定可变性: FLAG_MUTABLE 可变标记位是 Android 12 新增的,在 Android 12 之前,未使用 FLAG_IMMUTABLE 不可变标记位的 PendingIntent 都默认是可变的。但是,从 Android 12 开始,为了使 PendingIntent 的处理更加安全,系统要求 PendingIntent 必须显式声明一个可变性标志。这个问题我们在 Android 系统适配手册 里讲到过。
  • 注意事项 3 - 可变 PendingIntent 需要使用显式 Intent: 可变 PendingIntent 应该将其中包装的 Intent 设置为显式 Intent,确保修改后的 PendingIntent 没有安全隐患。

2.5 PendingIntent 标记位

现在,我们回过头再总结一下 PendingIntent 的 flags 标记位:

  • FLAG_IMMUTABLE: 不可变标记位,将约束外部应用消费 PendingIntent 修改其中的 Intent;
  • FLAG_MUTABLE: 可变标记位,不约束外部应用消费 PendingIntent 修改其中的 Intent;
  • FLAG_UPDATE_CURRENT: 更新标记位 1,如果系统中已经存在相同的 PendingIntent,那么将保留原有 PendingIntent 对象,而更新其中的 Intent。即使不可变 PendingIntent,依然可以在当前应用更新;
  • FLAG_CANCEL_CURRENT: 更新标记位 2,如果系统中已经存在相同的 PendingIntent,那么将先取消原有的 PendingIntent,并重新创建新的 PendingIntent。
  • FLAG_NO_CREATE: 更新标记位 3,如果系统中已经存在相同的 PendingIntent,那么不会重新创建,而是直接返回 null;
  • FLAG_ONE_SHOT: 一次有效标记位,PendingIntent 被消费后不支持重复消费,即只能使用一次。

3. PendingIntent 实现原理分析

3.1 创建 PendingIntent 的执行过程

创建 PendingIntent 需要使用特定的静态方法,内部会通过 Binder 通信将 PendingIntent 意图注册到 AMS 系统服务进程中,并获得一个 Binder 对象 IIntentSender。关键源码摘要如下:

PendingIntent.java

private final IIntentSender mTarget;

// 此处运行在应用进程
public static PendingIntent getActivity(Context context, int requestCode, Intent intent, @Flags int flags) {
    return getActivity(context, requestCode, intent, flags, null);
}

public static PendingIntent getActivity(Context context, int requestCode, @NonNull Intent intent, @Flags int flags, @Nullable Bundle options) {
    String packageName = context.getPackageName();
    String resolvedType = intent != null ? intent.resolveTypeIfNeeded(context.getContentResolver()) : null;
    intent.migrateExtraStreamToClipData(context);
    intent.prepareToLeaveProcess(context);
    // 通过 Binder 通信注册 Intent,得到 IIntentSender
    IIntentSender target = ActivityManager.getService().getIntentSenderWithFeature(
        ActivityManager.INTENT_SENDER_ACTIVITY, packageName,
        context.getAttributionTag(), nullnull, requestCode, new Intent[] { intent },
        resolvedType != null ? new String[] { resolvedType } : null,
        // 注意这个参数,使用当前应用的 UserId
        flags, options, context.getUserId());
    return new PendingIntent(target);
}

ActivityManagerService.java

// 此处运行在 AMS 系统服务进程
public IIntentSender getIntentSenderWithFeature(int type, String packageName, String featureId,
    IBinder token, String resultWho, int requestCode, Intent[] intents,
    String[] resolvedTypes, int flags, Bundle bOptions, int userId)
 
{
    ...
    int callingUid = Binder.getCallingUid();
    return mPendingIntentController.getIntentSender(type, packageName, featureId,
        callingUid /*调用应用进程*/, userId /*原始应用进程*/, token, resultWho, requestCode, intents, resolvedTypes,
        flags, bOptions);
}

PendingIntentController.java

// 存储已注册的 pendingIntent 记录
final HashMap<PendingIntentRecord.Key, WeakReference<PendingIntentRecord>> mIntentSenderRecords = new HashMap<>();

// 此处运行在 AMS 系统服务进程
public PendingIntentRecord getIntentSender(int type, String packageName,
    @Nullable String featureId, int callingUid, int userId, IBinder token, String resultWho,
    int requestCode, Intent[] intents, String[] resolvedTypes, int flags, Bundle bOptions)
 
{
  
    // 构建 PendingIntent 的 Key
    PendingIntentRecord.Key key = new PendingIntentRecord.Key(type, packageName, featureId,token, resultWho, requestCode, intents, resolvedTypes, flags, SafeActivityOptions.fromBundle(bOptions), userId);

    WeakReference<PendingIntentRecord> ref = mIntentSenderRecords.get(key);

    // 此处处理以下标记位的逻辑
    // FLAG_NO_CREATE
    // FLAG_CANCEL_CURRENT
    // FLAG_UPDATE_CURRENT

    if(ref != null) {
        return ref;
    }
    rec = new PendingIntentRecord(this, key, callingUid);
    mIntentSenderRecords.put(key, rec.ref);
    return rec;
}

PendingIntentRecord.java

public final class PendingIntentRecord extends IIntentSender.Stub {

    final static class Key {

        // 关键参数:创建进程的 UserId
        final int userId;

        Key(int _t, String _p, ..., int _userId) {
            ...
            userId = _userId;
        }

        public boolean equals(Object otherObj) {
            ...
            // 要素 1 - requestCode 源码体现
            if (requestCode != other.requestCode) {
                return false;
            }
            // 要素 2 - Intent 源码体现
            if (requestIntent != other.requestIntent) {
                if (requestIntent != null) {
                    if (!requestIntent.filterEquals(other.requestIntent)) {
                        return false;
                    }
                } else if (other.requestIntent != null) {
                    return false;
                }
            }
        }
    } 
}

至此,PendingIntent 就在系统进程中以 PendingIntentRecord 记录的形式存在,相当于 PendingIntent 是存在于比当前应用更长生命周期的系统进程中。这就是应用进程退出后,依然不影响消费 PendingIntent 的原因。

3.2 消费 PendingIntent 执行过程

消费 PendingIntent 需要使用 PendingIntent#send() 方法,内部会将创建 PendingIntent 时获得的 Binder 对象 IIntentSender 发送给 AMS 服务,用于执行最终的 Intent 操作。关键源码摘要如下:

PendingIntent.java

private final IIntentSender mTarget;

// 此处运行在应用进程
public void send(Context context, int code, @Nullable Intent intent, ...) throws CanceledException {
    if (sendAndReturnResult(context, code, intent, onFinished, handler, requiredPermission,options) < 0) {
        throw new CanceledException();
    }
}

public int sendAndReturnResult(Context context, int code, @Nullable Intent intent, ...) throws CanceledException {
  // 通过 Binder 通信执行 IIntentSender
  return ActivityManager.getService().sendIntentSender(mTarget, mWhitelistToken, code, intent, resolvedType, ...);
}

ActivityManagerService.java

// 此处运行在 AMS 系统服务进程
@Override
public int sendIntentSender(IIntentSender target, IBinder whitelistToken, int code, Intent intent, String resolvedType, ...) {
    if (target instanceof PendingIntentRecord) {
        return ((PendingIntentRecord)target).sendWithResult(code, intent, resolvedType, ...);
    }else {
        ...
    }
}

PendingIntentRecord.java

// 此处运行在 AMS 系统服务进程
public int sendInner(int code, Intent intent, String resolvedType, ...) {
    // 此处处理以下标记位的逻辑
    // FLAG_ONE_SHOT
    // FLAG_MUTABLE
    // FLAG_IMMUTABLE

    // FLAG_ONE_SHOT 标记会移除 PendingIntentController 存储的记录
    if ((key.flags & PendingIntent.FLAG_ONE_SHOT) != 0) {
        controller.cancelIntentSender(thistrue);
    }

    int res = START_SUCCESS;

    // 关键参数:创建进程的 UserId
    int userId = key.userId;

    switch (key.type) {
        case ActivityManager.INTENT_SENDER_ACTIVITY:
            res = controller.mAtmInternal.startActivitiesInPackage(
                uid /*关键参数*/, callingPid, callingUid, key.packageName, key.featureId,
                allIntents, allResolvedTypes, resultTo, mergedOptions, userId,
                false /* validateIncomingUser */,
                this /* originatingPendingIntent */,
                mAllowBgActivityStartsForActivitySender.contains(whitelistToken));
        break;

        case ActivityManager.INTENT_SENDER_ACTIVITY_RESULT:
        ...
        break;

        case ActivityManager.INTENT_SENDER_BROADCAST:
        ...
        break;

        case ActivityManager.INTENT_SENDER_SERVICE:
        case ActivityManager.INTENT_SENDER_FOREGROUND_SERVICE:
        ...
        break;
    }
    return res;
}

ActivityTaskManagerInternal.java

public abstract class ActivityTaskManagerInternal {
    public abstract int startActivityInPackage(int uid, int realCallingPid, int realCallingUid, ...);
}

ActivityTaskManagerInternal 是一个抽象类,小彭没有找到其最终的实现类,有大佬知道的话请在评论区告诉我。

至此,就完成执行 PendingIntent 中延迟操作的目的。 那么,为什么在当前进程执行,还会以另一个进程(PendingIntent 的创建进程) 的身份执行呢,关键在于使用了保存在 PendingIntentRecord 记录中的 userId,这与我们通过常规的 Activity#startActivityAsUser() 是类似的。

Activity.java

@Override
public void startActivityAsUser(Intent intent, UserHandle user) {
    startActivityAsUser(intent, null, user);
}

4. 总结

到这里,PendingIntent 的内容就讲完了,相信你对 PendingIntent 的理解已经超过绝大部分同学,你认同吗?关注我,带你了解更多,我们下次见。


参考资料

你的点赞对我意义重大!微信搜索公众号 [彭旭锐],希望大家可以一起讨论技术,找到志同道合的朋友,我们下次见!

分类:

移动端开发

标签:

Android

作者介绍

彭丑丑
V1