如何绕过 Android 8.0 startService 限制

应用在后台运行时，会消耗一部分有限的设备资源，例如 RAM。这可能会影响用户体验，如果用户正在使用占用大量资源的应用（例如玩游戏或观看视频），影响会尤为明显。为了提升用户体验，Android 8.0（API 级别 26）对应用在后台运行时可以执行的操作施加了限制。

限制了什么？

• 1. 后台应用对后台服务的访问受到限制

  在不与用户直接交互的后台应用中，运行 Service 会消耗系统资源，这可能会影响前台应用的正常运行。Android 8.0 及更高版本「不允许后台应用运行后台服务」，需要通过 startForegroundService() 指定为前台服务运行，或者使用 JobScheduler 替代。

• 1. 注册隐式广播接收器受到限制

  对于一些系统隐式广播（非全部），系统不允许应用在 AndroidManifest 中注册对应的广播接收器，从而避免系统广播导致诸多应用快速、连续消耗系统资源，从而影响用户体验，需要通过 Context.registerReceiver() 动态注册或 JobScheduler 代替。

• 1. 降低了后台应用接收位置更新的频率

  为节约电池电量、保持良好的用户体验和确保系统健康运行，在运行 Android 8.0 的设备上使用后台应用时，降低了后台应用接收位置更新的频率。

什么是前台应用?

系统可以区分前台和后台应用。如果满足以下任意条件，应用将被视为处于前台：

• 1. 具有可见 Activity

• 1. 具有前台 Service

• 1. 另一个前台应用已关联到该应用（绑定 Service 或使用 content providers）

如果以上条件均不满足，应用将被视为处于后台。

正确理解后台服务限制

「不允许后台应用运行后台服务」

官网的这句描述很简单，但你真的明白它的含义吗？顺着这句话推导一下：

后台应用无法启动后台服务

-> 前台应用可以启动后台服务

-> A 为前台应用，则 A 就能启动后台服务

基于这个结论，再结合后台服务的种类，对以下三种场景实践验证，结果如下：

• 1. 若后台服务属于 A 应用进程，则能正常启动

• 1. 若后台服务属于 B 应用进程，且 B 是前台应用，则能正常启动

• 1. 若后台服务属于 B 应用进程，且 B 是后台应用，则无法启动！

通过第三种场景的验证结果，可以知道 不允许后台应用运行后台服务 这个描述是不准确、有歧义的，更精准的描述应该是：

「不允许启动属于后台应用的后台服务」

后台服务限制源码分析

若在 Android 8.0 设备上通过 startService 启动一个属于后台应用的后台服务，会直接崩溃：

Caused by: java.lang.IllegalStateException: Not allowed to start service Intent
        { act=intent.action.ServerService pkg=com.server }: app is in background uid null
   at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1577)
   at android.app.ContextImpl.startService(ContextImpl.java:1532)
   at android.content.ContextWrapper.startService(ContextWrapper.java:664)
   ...

下面以此异常为线索，一步一步来看源码中是如何限制的。异常在 ContextImpl 中抛出：

private ComponentName startServiceCommon(Intent service, boolean requireForeground,
        UserHandle user) {
    ...
    ComponentName cn = ActivityManager.getService().startService(
        mMainThread.getApplicationThread(), service, service.resolveTypeIfNeeded(
                    getContentResolver()), requireForeground,
                    getOpPackageName(), user.getIdentifier());
    if (cn != null) {
        if (cn.getPackageName().equals("!")) {
            ...
        } else if (cn.getPackageName().equals("?")) {
            //这里抛出启动服务限制的异常
            throw new IllegalStateException(
                    "Not allowed to start service " + service + ": " + cn.getClassName());
        }
    }
    return cn;
}

可见关键点是 cn.getPackageName().equals("?") 条件成立， 继续看 AMS startService 方法中是如何返回这个 ComponentName 的：

public ComponentName startService(IApplicationThread caller, Intent service,
        String resolvedType, boolean requireForeground, String callingPackage, int userId)
        throws TransactionTooLargeException {
    ...
    ComponentName res;
    try {
        res = mServices.startServiceLocked(caller, service,
                resolvedType, callingPid, callingUid,
                requireForeground, callingPackage, userId);
    } finally {
        Binder.restoreCallingIdentity(origId);
    }
    return res;
}

AMS 中转调 ActiveServices 的 startServiceLocked 方法去处理服务的启动，关键代码如下：

ComponentName startServiceLocked(IApplicationThread caller, Intent service, String resolvedType,
        int callingPid, int callingUid, boolean fgRequired, String callingPackage,
        final int userId, boolean allowBackgroundActivityStarts)
        throws TransactionTooLargeException {
    ...
    //非前台服务，需要检测是否满足后台服务启动条件，不满足则限制启动
    if (forcedStandby || (!r.startRequested && !fgRequired)) {
        final int allowed = mAm.getAppStartModeLocked(r.appInfo.uid, r.packageName,
                r.appInfo.targetSdkVersion, callingPid, false, false, forcedStandby);
        if (allowed != ActivityManager.APP_START_MODE_NORMAL) { //不满足启动条件
            if (allowed == ActivityManager.APP_START_MODE_DELAYED || forceSilentAbort) {
                //这里返回 null 代表此场景下静默的限制启动，不通知应用
                return null;
            }
            ...
            //这里代表用户应知道此场景下不允许启动，所以返回 ComponentName，明确的通知应用
            //注意返回了 "?"，是导致应用崩溃的原因
            UidRecord uidRec = mAm.mProcessList.getUidRecordLocked(r.appInfo.uid);
            return new ComponentName("?", "app is in background uid " + uidRec);
        }
    }
}

至此可以知道关键在于 mAm.getAppStartModeLocked 方法，如果返回 APP_START_MODE_NORMAL 则代表满足启动条件，不会被限制。

mAm 为 ActivityManagerService，继续看 ActivityManagerService 的 getAppStartModeLocked 方法：

int getAppStartModeLocked(int uid, String packageName, int packageTargetSdk,
        int callingPid, boolean alwaysRestrict, boolean disabledOnly, boolean forcedStandby) {
    UidRecord uidRec = mProcessList.getUidRecordLocked(uid);
    //注意传入的 alwaysRestrict、forcedStandby 都为 false，暂不关注
    if (uidRec == null || alwaysRestrict || forcedStandby || uidRec.idle) {
        ...
        final int startMode = (alwaysRestrict)
                ? appRestrictedInBackgroundLocked(uid, packageName, packageTargetSdk)
                : appServicesRestrictedInBackgroundLocked(uid, packageName,
                        packageTargetSdk);
        return startMode;
    }
    return ActivityManager.APP_START_MODE_NORMAL;
}

uidRec 为该服务所在应用，uidRec == null 代表应用还未启动，uidRec.idle 代表应用处于后台。应用未启动可以看作处于后台，当然也是不允许启动后台服务的。

继续看 appServicesRestrictedInBackgroundLocked 方法：

int appServicesRestrictedInBackgroundLocked(int uid, String packageName, int packageTargetSdk) {
    if (mPackageManagerInt.isPackagePersistent(packageName)) {
        //系统永久应用不做限制
        return ActivityManager.APP_START_MODE_NORMAL;
    }
    if (uidOnBackgroundWhitelist(uid)) {
        //白名单应用不做限制
        return ActivityManager.APP_START_MODE_NORMAL;
    }
    if (isOnDeviceIdleWhitelistLocked(uid, false)) {
        //白名单应用不做限制
        return ActivityManager.APP_START_MODE_NORMAL;
    }
    // 其他应用走通用的限制策略
    return appRestrictedInBackgroundLocked(uid, packageName, packageTargetSdk);
}

普通应用会走通用的限制策略，继续看 appRestrictedInBackgroundLocked 方法：

int appRestrictedInBackgroundLocked(int uid, String packageName, int packageTargetSdk) {
    if (packageTargetSdk >= Build.VERSION_CODES.O) {
        return ActivityManager.APP_START_MODE_DELAYED_RIGID;
    }
    //tartget API 小于 8.0 的应用走旧的限制策略，众所周知的不会被限制
    ...
}

可以看到这里对 tartget API 做的限制，8.0 及以上的应用会被限制启动服务，是上层抛出异常的根本原因。

适配 Android 8.0 startService 限制策略

了解了系统的限制原理后，结合上文对 AMS 启动服务限制的源码分析，列举可能的适配方案：

• 1. 使用 startForegroundService 代替

• 1. 使用 JobScheduler 代替

• 1. 设置应用为 Persisten 系统永久应用类型

• 1. 将应用加入到系统白名单

• 1. 将应用的 targetSdkVersion 调整为小于 Android 8.0 的版本

• 1. 启动服务前，先将服务所在应用从后台切换到前台

方案 1 是工作量较小的兼容旧代码方案，但会显示一条通知，这可能不是我们想要的

方案 2 是官方建议方案，兼容工作量比方案 1 多

方案 3 和方案 4 需要系统侧配合，适用于系统或预装应用，对绝大多数的第三方应用来说不可行

方案 5 可行，但极不推荐这种固步自封的方式

方案 6 可行，但不符合谷歌推进此限制策略的意愿，违背提高用户体验的初衷

如何绕过 Android 8.0 startService 限制？

别忘了标题，最终想要实现的是绕过 Android 8.0 startService 的限制，即不修改为前台服务，调用 startService 方法，仍旧可以启动属于后台应用的后台服务，怎么实现呢？

通过上面的方案 6 ：「启动服务前，先将服务所在应用从后台切换到前台」 便可实现，如何将应用从后台切换到前台呢？上文介绍了应用被视为处于前台的条件：

1. 具有可见 Activity

2. 具有前台 Service

3. 另一个前台应用已关联到该应用

依据条件 1 可想到一种实现方案：

如果应用处于后台，就启动一个透明的、用户无感知的 Activity，将应用切换到前台，然后再通过 startService 启动服务，随后 finish 掉透明 Activity。

调用端这样 startService ：

Intent serviceIntent = new Intent();
serviceIntent.setAction("com.ahab.server.service");
serviceIntent.setPackage(context.getPackageName());
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    try{
        context.startService(serviceIntent);
    }catch (Exception e){
        Intent activityIntent = new Intent();
        activityIntent.setAction("com.ahab.server.TranslucentActivity");
        activityIntent.setPackage(context.getPackageName());
        activityIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
        context.startActivity(activityIntent);
    }
}else{
    context.startService(serviceIntent);
}

启动透明 Activity 后 startService：

public class TranslucentActivity extends Activity {

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Intent serviceIntent = new Intent();
        serviceIntent.setAction("com.ahab.server.service");
        serviceIntent.setPackage(context.getPackageName());
        context.startService(serviceIntent);
        finish();
    }
}

可以看到代码实现十分简单。

上面都是围绕 startService 启动方式来讲，没有提及 「bindService」 方式，系统并未限制 bindService 启动后台服务，所以通过 bindService 绕过 Android 8.0 startService 的限制，也是可行的。