源码茶舍之FLAG_EXCLUDE_STOPPED_PACKAGES与广播唤醒

发现

我们先随便实现一个BroadcastReceiver，静态注册：

class TestReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context?, intent: Intent?) {
        Log.w("TEST-1", "onReceive ${intent?.action}")
    }
}

<receiver android:name=".TestReceiver">
    <intent-filter>
        <action android:name="com.xxx.yyy.action_test_receiver" />
    </intent-filter>
</receiver>

其他诸如Activity什么的就不写了哈，然后我们启动这个测试App之后，用adb命令发一条广播：

1	adb shell am broadcast -p com.xxx.yyy -a com.xxx.yyy.action_test_receiver

其中参数p表示广播接收所在进程包名，a表示action。命令执行后终端会输出：

1 2	Broadcasting: Intent { act=com.xxx.yyy.action_test_receiver flg=0x400000 pkg=com.xxx.yyy } Broadcast completed: result=0

然后查看logcat，我们可以如愿以偿地看到onReceive中的log。接下来我们杀掉进程，任意方式均可，这里我还是用adb命令，方便：

1	adb shell am force-stop com.xxx.yyy

杀进程后，再重复上面的广播发送命令，就会发现收不到广播了。这是为什么呢？表面看来这个问题很弱智，进程都死了当然不能再搞事。但实际上背后的逻辑还是值得探索的，系统也不是想象中那么简单地直接判断进程死活然后决定广播发送。

探秘

很显然我们要搞明白广播发送的底层逻辑。这里主要分析Framework层面的源码（基于Android 10），涉及到的关键类：

frameworks/base/core/java/android/content/Intent.java
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
frameworks/base/services/core/java/com/android/server/pm/PackageManagerService.java
frameworks/base/services/core/java/com/android/server/pm/ComponentResolver.java
frameworks/base/services/core/java/com/android/server/IntentResolver.java

关于广播发送的细节，可以参考此文：https://www.jianshu.com/p/c5323a22f3f3，虽然源码版本不是最新，但基本逻辑差异不大，时序图也画得非常清晰。下面我们只针对文题简单地分析关键路径即可。

当我们乐呵呵地调用了 sendBroadcast 方法之后，会调用到AMS（ActivityManagerService）的 broadcastIntent 方法，进而调用内部的 broadcastIntentLocked 方法（此处插入一个题外话：很多同学可能经常见到源码里 xxxLocked 这种方法，这个locked是什么意思呢？顾名思义就是加锁咯，即你要调用这些locked后缀的方法时，必须保证是线程安全的，所以一般就会看到synchronize关键字，这也算是AOSP的编码规范吧）。

由于 broadcastIntentLocked 方法非常长，我们只截取关键片段：

  final int broadcastIntentLocked(Intent intent/*省略18个参数*/) {
      intent = new Intent(intent);
// ...
      // By default broadcasts do not go to stopped apps.
      intent.addFlags(Intent.FLAG_EXCLUDE_STOPPED_PACKAGES);
      // ...
      // Figure out who all will receive this broadcast.
      List receivers = null;
      List<BroadcastFilter> registeredReceivers = null;
      // Need to resolve the intent to interested receivers...
      if ((intent.getFlags()&Intent.FLAG_RECEIVER_REGISTERED_ONLY)
               == 0) {
          receivers = collectReceiverComponents(intent, resolvedType, callingUid, users);
      }
      // ...
  }

可以看到，起手就是new Intent(intent)，为什么不直接使用参数中的intent来进行后续操作呢？此处一个小细节可以看出源码逻辑的谨慎，去查Intent的构造方法就知道，这是对入参的拷贝，避免被其他线程修改。
然后最关键的便是下面的 FLAG_EXCLUDE_STOPPED_PACKAGES ，注释也写得很清楚，即广播发送会排除（exclude）已停止运行的进程。

但我初次分析时看了半天没发现是怎么排除的，于是找这个flag引用的地方，在 Intent 源码中发现一个方法，判断该intent是否要排除已停止的进程：

public boolean isExcludingStopped() {
    return (mFlags&(FLAG_EXCLUDE_STOPPED_PACKAGES|FLAG_INCLUDE_STOPPED_PACKAGES))
            == FLAG_EXCLUDE_STOPPED_PACKAGES;
}

非常好，我们直接查 isExcludingStopped 方法的引用，发现在 IntentResolver 中：

  private void buildResolveList(Intent intent, FastImmutableArraySet<String> categories,
          boolean debug, boolean defaultOnly, String resolvedType, String scheme,
          F[] src, List<R> dest, int userId) {
      // ...
      final boolean excludingStopped = intent.isExcludingStopped();
// ...
      for (i=0; i<N && (filter=src[i]) != null; i++) {
          // ...
          if (excludingStopped && isFilterStopped(filter, userId)) {
              if (debug) {
                  Slog.v(TAG, "  Filter's target is stopped; skipping");
              }
              continue;
          }
      }
      // ...
  }

这是通过intent构造resolve列表的一个私有方法，代码也非常清晰，此判断逻辑 excludingStopped && isFilterStopped 过滤了最后要启动的组件。其中 isFilterStopped 是真正判断进程是否已停止的方法，而 excludingStopped 是我们刚才传入的flag对应的控制标识。所以要过滤掉已停止进程有两个必要条件，一是这个进程真的死了，二是开发者要通过flag来声明确实需要过滤（是不是超人性化哈哈哈）。

因此，我们也可以声明不需要过滤，即给intent设置 FLAG_EXCLUDE_STOPPED_PACKAGES 的兄弟flag：FLAG_INCLUDE_STOPPED_PACKAGES （注意是 include），这样在发送广播时，即便是已停止的进程，也能接收到了。这就是上古时期通过广播唤醒死亡进程的方法，现在基本上被各大ROM厂商给优化没了，一般都是三方应用被禁，系统应用依然可以。

分析到此，其实只是有头有尾，但没有中间过程，broadcastIntentLocked 最终怎么就调到了 buildResolveList 呢？
我们回到上面的 broadcastIntentLocked 方法，其中的 receivers 对象存储的是静态广播的集合，registeredReceivers 则是动态广播的集合。我们只看静态广播即可，它来自于 collectReceiverComponents 方法，此方法最后返回的receiver肯定是被过滤后的：

private List<ResolveInfo> collectReceiverComponents(Intent intent, String resolvedType,
        int callingUid, int[] users) {
    // ...
    List<ResolveInfo> receivers = null;
    try {
        // ...
        for (int user : users) {
            // ...
            List<ResolveInfo> newReceivers = AppGlobals.getPackageManager()
                    .queryIntentReceivers(intent, resolvedType, pmFlags, user).getList();
            // ...
            if (newReceivers != null && newReceivers.size() == 0) {
                newReceivers = null;
            }
            if (receivers == null) {
                receivers = newReceivers;
            // ...
        }
    } catch (RemoteException ex) {
        // pm is in same process, this will never happen.
    }
    return receivers;
}

这个方法内部逻辑较为简单，我们可以看到最终receivers的来源便是那个 queryIntentReceivers 方法，此方法实现在PMS（PackageManagerService）里面：

@Override
public @NonNull ParceledListSlice<ResolveInfo> queryIntentReceivers(Intent intent,
        String resolvedType, int flags, int userId) {
    return new ParceledListSlice<>(
            queryIntentReceiversInternal(intent, resolvedType, flags, userId,
                    false /*allowDynamicSplits*/));
}

private @NonNull List<ResolveInfo> queryIntentReceiversInternal(Intent intent,
        String resolvedType, int flags, int userId, boolean allowDynamicSplits) {
    // ...
    synchronized (mPackages) {
        String pkgName = intent.getPackage();
        if (pkgName == null) {
            final List<ResolveInfo> result =
                    mComponentResolver.queryReceivers(intent, resolvedType, flags, userId);
            return applyPostResolutionFilter(
                    result, instantAppPkgName, allowDynamicSplits, callingUid, false, userId,
                    intent);
        }
        final PackageParser.Package pkg = mPackages.get(pkgName);
        if (pkg != null) {
            final List<ResolveInfo> result = mComponentResolver.queryReceivers(
                    intent, resolvedType, flags, pkg.receivers, userId);
            return applyPostResolutionFilter(
                    result, instantAppPkgName, allowDynamicSplits, callingUid, false, userId,
                    intent);
        }
        return Collections.emptyList();
    }
}

最终receiver集合的查询操作在私有方法中，由 mComponentResolver.queryReceivers 得来，似乎越来越接近真相了，马上查看ComponentResolver：

List<ResolveInfo> queryReceivers(Intent intent, String resolvedType, int flags, int userId) {
    synchronized (mLock) {
        return mReceivers.queryIntent(intent, resolvedType, flags, userId);
    }
}

List<ResolveInfo> queryReceivers(Intent intent, String resolvedType, int flags,
        List<PackageParser.Activity> receivers, int userId) {
    synchronized (mLock) {
        return mReceivers.queryIntentForPackage(intent, resolvedType, flags, receivers, userId);
    }
}

这里正好对应上面的两个不同情况下的调用，它们最终都会调用到 queryIntent 方法，此方法在ComponentResolver的一个静态内部类ActivityIntentResolver中实现：

private static final class ActivityIntentResolver
        extends IntentResolver<PackageParser.ActivityIntentInfo, ResolveInfo> {
    @Override
    public List<ResolveInfo> queryIntent(Intent intent, String resolvedType,
            boolean defaultOnly, int userId) {
        // ...
        return super.queryIntent(intent, resolvedType, defaultOnly, userId);
    }

    List<ResolveInfo> queryIntent(Intent intent, String resolvedType, int flags,
            int userId) {
        // ...
        return super.queryIntent(intent, resolvedType,
                (flags & PackageManager.MATCH_DEFAULT_ONLY) != 0,
                userId);
    }
    // ...
}

内部类的中的 queryIntent 方法只是做了一些参数处理，进一步调用的是父类的实现，这个父类也就是起初我们提到的 IntentResolver：

  public List<R> queryIntent(Intent intent, String resolvedType, boolean defaultOnly,
          int userId) {
      // ...
      if (firstTypeCut != null) {
          buildResolveList(intent, categories, debug, defaultOnly, resolvedType,
                  scheme, firstTypeCut, finalList, userId);
      }
      if (secondTypeCut != null) {
          buildResolveList(intent, categories, debug, defaultOnly, resolvedType,
                  scheme, secondTypeCut, finalList, userId);
      }
      if (thirdTypeCut != null) {
          buildResolveList(intent, categories, debug, defaultOnly, resolvedType,
                  scheme, thirdTypeCut, finalList, userId);
      }
      if (schemeCut != null) {
          buildResolveList(intent, categories, debug, defaultOnly, resolvedType,
                  scheme, schemeCut, finalList, userId);
      }
      filterResults(finalList);
      sortResults(finalList);
// ...
      return finalList;
  }

看上面的 buildResolveList 方法，照应了开头分析的结果。最终返回的 finalList 也就是过滤之后的receiver集合。

总结

在广播发送的前序步骤（位于AMS）里，通过 intent.addFlags(Intent.FLAG_EXCLUDE_STOPPED_PACKAGES); 设置了标识，以声明广播不发给已停止的进程，层层调用后最终在 IntentResolver 的 buildResolveList 方法中实现过滤。
在原生Android的设计逻辑中，若要突破上述限制，在 sendBroadcast 之前，给intent添加 flag：FLAG_INCLUDE_STOPPED_PACKAGES 即可。但鉴于各ROM厂商的正负优化，这个操作已经不适用了。