内容简介:Android O 推出出了Background Execution Limits,减少后台应用内存使用及耗电,一个很明显的应用就是不准后台应用通过startService启动服务,这里有两个问题需要弄清楚,第一:什么状态下startService的属于后台启动service;第二:如果想要在后台startService,如何兼容,因此分如下几个问题分析下对于普通APP而言,我们不考虑系统的各种白名单,一般后台startService服务分下面两种:而每种又可以分不同的小场景,通过其他应用startServ
Android O 推出出了Background Execution Limits,减少后台应用内存使用及耗电,一个很明显的应用就是不准后台应用通过startService启动服务,这里有两个问题需要弄清楚,第一:什么状态下startService的属于后台启动service;第二:如果想要在后台startService,如何兼容,因此分如下几个问题分析下
- 后台startService的场景
- 后台startService的Crash原理分析
- 如何修改达到兼容
对于普通APP而言,我们不考虑系统的各种白名单,一般后台startService服务分下面两种:
- 通过其他应用startService
- 通过自己应用startService
而每种又可以分不同的小场景,通过其他应用startService已经不被推荐,所以先看看自己应用startService。
本文基于Android P源码
通过自己应用在后台startService限制
可以通过一个简单的实验观察什么情况属于后台startService, 注意:如果是自己APP启动Service,那么自身应用必定已经起来了 。通过延迟执行就复现该场景。比如:通过click事件,延迟执行一个startService操作,延迟时间是65s( 要超过一分钟,后面会看到这是个阈值 ),然后点击Home键,回到桌面,之后等待一分钟就可复现Crash:
@OnClick(R.id.first) void first() { new Handler().postDelayed(new Runnable() { @Override public void run() { Intent intent = new Intent(LabApplication.getContext(), BackGroundService.class); startService(intent); LogUtils.v("延迟执行"); } },1000*65); } 复制代码
大概一分多钟之后,延迟消息被执行,然后会有如下Crash日志被打印:
--------- beginning of crash 2019-06-17 19:47:43.148 25916-25916/com.snail.labaffinity E/AndroidRuntime: FATAL EXCEPTION: main Process: com.snail.labaffinity, PID: 25916 java.lang.IllegalStateException: Not allowed to start service Intent { cmp=com.snail.labaffinity/.service.BackGroundService }: app is in background uid UidRecord{9048c2c u0a73 LAST bg:+1m4s376ms idle change:idle procs:1 seq(0,0,0)} at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1577) at android.app.ContextImpl.startService(ContextImpl.java:1532) at android.content.ContextWrapper.startService(ContextWrapper.java:664) at com.snail.labaffinity.activity.MainActivity$2.run(MainActivity.java:41) at android.os.Handler.handleCallback(Handler.java:873) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:193) at android.app.ActivityThread.main(ActivityThread.java:6669) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858) 复制代码
就会看到很经典的startService限制信息:
Not allowed to start service Intent XXX : app is in background uid UidRecord 复制代码
也就是说,当前退到后台的APP已经属于后台应用,不能通过startService启动服务。Why?跟踪源码看下 startService会调用ContextImpl 的startServiceCommon,进而通过Binder调用AMS启动Service,根据返回值选择性抛出IllegalStateException异常:
ContextImpl.java
private ComponentName startServiceCommon(Intent service, boolean requireForeground, UserHandle user) { try { validateServiceIntent(service); service.prepareToLeaveProcess(this); ComponentName cn = ActivityManager.getService().startService( mMainThread.getApplicationThread(), service, service.resolveTypeIfNeeded( getContentResolver()), requireForeground, getOpPackageName(), user.getIdentifier()); if (cn != null) { <!--返回值是?的情况下就是后台启动service的异常--> if (cn.getPackageName().equals("?")) { throw new IllegalStateException( "Not allowed to start service " + service + ": " + cn.getClassName()); } } 复制代码
什么时候ActivityManager.getService().startService的返回值包名 ? ,核心代码在AMS端,AMS进一步调用ActiveServices.java的startServiceLocked:
ActiveServices.java
ComponentName startServiceLocked(IApplicationThread caller, Intent service, String resolvedType, int callingPid, int callingUid, boolean fgRequired, String callingPackage, final int userId) throws TransactionTooLargeException { final boolean callerFg; if (caller != null) { final ProcessRecord callerApp = mAm.getRecordForAppLocked(caller); ... callerFg = callerApp.setSchedGroup != ProcessList.SCHED_GROUP_BACKGROUND; } else { callerFg = true; } ServiceLookupResult res = retrieveServiceLocked(service, resolvedType, callingPackage, callingPid, callingUid, userId, true, callerFg, false, false); ... ServiceRecord r = res.record; // If we're starting indirectly (e.g. from PendingIntent), figure out whether // we're launching into an app in a background state. This keys off of the same // idleness state tracking as e.g. O+ background service start policy. <!--通过PendingIntent启动的也要检查--> // 是否当前Uid Active 不过不是activity就是后台启动 final boolean bgLaunch = !mAm.isUidActiveLocked(r.appInfo.uid); // If the app has strict background restrictions, we treat any bg service // start analogously to the legacy-app forced-restrictions case, regardless // of its target SDK version. boolean forcedStandby = false; <!--appRestrictedAnyInBackground 一般人不会主动设置,所以这个经常是返回false--> if (bgLaunch && appRestrictedAnyInBackground(r.appInfo.uid, r.packageName)) { ... forcedStandby = true; } <!--forcedStandby可以先无视 这里注意两点,第一点 :r.startRequested标志是通过startService调用启动过,第一次进来的时候是false,第二:对于普通是starServicefgRequired是false--> if (forcedStandby || (!r.startRequested && !fgRequired)) { <!--检测当前app是否允许后台启动--> final int allowed = mAm.getAppStartModeLocked(r.appInfo.uid, r.packageName, r.appInfo.targetSdkVersion, callingPid, false, false, forcedStandby); <!--如果不允许 Background start not allowed--> if (allowed != ActivityManager.APP_START_MODE_NORMAL) { ... <!--返回 ? 告诉客户端现在处于后台启动状态,禁止你--> return new ComponentName("?", "app is in background uid " + uidRec); } } 复制代码
假设我们是第一次startService,那么(!r.startRequested && !fgRequired)就等于true,进而走进mAm.getAppStartModeLocked,看看当前进程是否处于后台非激活状态,如果是的话 ,就不会允许startService:
ActivityManagerService.java
int getAppStartModeLocked(int uid, String packageName, int packageTargetSdk, int callingPid, boolean alwaysRestrict, boolean disabledOnly, boolean forcedStandby) { UidRecord uidRec = mActiveUids.get(uid); <!--UidRecord是关键 alwaysRestrict || forcedStandby 传入的都是false,忽略 --> if (uidRec == null || alwaysRestrict || forcedStandby || uidRec.idle) { boolean ephemeral; ... final int startMode = (alwaysRestrict) ? appRestrictedInBackgroundLocked(uid, packageName, packageTargetSdk) : appServicesRestrictedInBackgroundLocked(uid, packageName, packageTargetSdk); ... return startMode; } return ActivityManager.APP_START_MODE_NORMAL; } 复制代码
这里UidRecord是关键,UidRecord为null,则说明整个APP没有被启动,那么就一定属于后台启动Service,如果UidRecord非null,则要判断应用是否属于后台应用,而这个关键就是uidRec.idle,如果idle是true,就说明应用处于后台状态,继续调用 appServicesRestrictedInBackgroundLocked看看是否是O以后的,走Crash逻辑:
int appServicesRestrictedInBackgroundLocked(int uid, String packageName, int packageTargetSdk) { <!--永久进程 --> // Persistent app? if (mPackageManagerInt.isPackagePersistent(packageName)) { return ActivityManager.APP_START_MODE_NORMAL; } <!--白名单--> // Non-persistent but background whitelisted? if (uidOnBackgroundWhitelist(uid)) { return ActivityManager.APP_START_MODE_NORMAL; } <!--白名单--> // Is this app on the battery whitelist? if (isOnDeviceIdleWhitelistLocked(uid, /*allowExceptIdleToo=*/ false)) { return ActivityManager.APP_START_MODE_NORMAL; } // 普通进程 return appRestrictedInBackgroundLocked(uid, packageName, packageTargetSdk); } 复制代码
对于普通进程看看O限制
int appRestrictedInBackgroundLocked(int uid, String packageName, int packageTargetSdk) { <!--对于targetSDKVersion>O 的直接 返回ActivityManager.APP_START_MODE_DELAYED_RIGID--> if (packageTargetSdk >= Build.VERSION_CODES.O) { return ActivityManager.APP_START_MODE_DELAYED_RIGID; } // 否则仅仅对老版本做兼容性限制 int appop = mAppOpsService.noteOperation(AppOpsManager.OP_RUN_IN_BACKGROUND, uid, packageName); if (DEBUG_BACKGROUND_CHECK) { Slog.i(TAG, "Legacy app " + uid + "/" + packageName + " bg appop " + appop); } switch (appop) { case AppOpsManager.MODE_ALLOWED: // If force-background-check is enabled, restrict all apps that aren't whitelisted. if (mForceBackgroundCheck && !UserHandle.isCore(uid) && !isOnDeviceIdleWhitelistLocked(uid, /*allowExceptIdleToo=*/ true)) { return ActivityManager.APP_START_MODE_DELAYED; } ... } 复制代码
appServicesRestrictedInBackgroundLocked仅仅是根据是否是O以后,返回ActivityManager.APP_START_MODE_DELAYED_RIGID,只是兼容,核心还是UidRecord的idle,下面就重点看看UidRecord跟其idle的值,这个值是应用是否位于后台的核心指标,应用未启动的不考虑,未启动肯定也属于”后台“的一种极端。
不是特别老的Android版本都不允许没有LAUNCHER Activity的应用,不然压根没法编译运行,也就说普通场景通过桌面启动应用的时候,都是通过startActivity直接启动APP的,在启动App的时候,UidRecord会被新建(AMS端),UidRecord构造函数中默认 idle = true。
public UidRecord(int _uid) { uid = _uid; idle = true; reset(); } 复制代码
其启动流程调用堆栈如下:
也就是启动APP时候,刚好一开UidRecord中idle的值是true,被看做后台应用,那么一定有某个地方设置为false,设置为前台应用。
前后台应用切换时机与原理
一个应用可以有一个或者多个进程,当任何一个进程变为被转换成前台可见进程的时候,APP都会被认作前台应用(对于startService应用而言),resumetopActivity是一个非常明确的切换时机,
会调用
final void scheduleIdleLocked() { mHandler.sendEmptyMessage(IDLE_NOW_MSG); } 复制代码
会通过updateOomAdjLocked修改当前即将可见Activity应用的idle状态,updateOomAdjLocked在期间可能会被调用多次,
@GuardedBy("this") final void updateOomAdjLocked() { ... for (int i=mActiveUids.size()-1; i>=0; i--) { final UidRecord uidRec = mActiveUids.valueAt(i); int uidChange = UidRecord.CHANGE_PROCSTATE; if (uidRec.curProcState != ActivityManager.PROCESS_STATE_NONEXISTENT && (uidRec.setProcState != uidRec.curProcState || uidRec.setWhitelist != uidRec.curWhitelist)) { ... if (ActivityManager.isProcStateBackground(uidRec.curProcState) && !uidRec.curWhitelist) { ... } else { <!--设置为false 标记为前台进程--> if (uidRec.idle) { uidChange = UidRecord.CHANGE_ACTIVE; EventLogTags.writeAmUidActive(uidRec.uid); uidRec.idle = false; } <!--清零后台进程锚点时间--> uidRec.lastBackgroundTime = 0; } 复制代码
对于即将可见的APP而言 ActivityManager.isProcStateBackground为false,所以走else逻辑设置uidRec.idle = false,uidChange = UidRecord.CHANGE_ACTIVE,之后通过enqueueUidChangeLocked最后设置相对应的idle = false。相对应,上一个被切换走的应用可能会触发设置idle = true的操作,不过设置为true的操作不是即可执行的,而是延迟执行的,延迟时间60s:
final void updateOomAdjLocked() { ... for (int i=mActiveUids.size()-1; i>=0; i--) { final UidRecord uidRec = mActiveUids.valueAt(i); int uidChange = UidRecord.CHANGE_PROCSTATE; if (uidRec.curProcState != ActivityManager.PROCESS_STATE_NONEXISTENT && (uidRec.setProcState != uidRec.curProcState || uidRec.setWhitelist != uidRec.curWhitelist)) { if (ActivityManager.isProcStateBackground(uidRec.curProcState) && !uidRec.curWhitelist) { // UID is now in the background (and not on the temp whitelist). Was it // previously in the foreground (or on the temp whitelist)? if (!ActivityManager.isProcStateBackground(uidRec.setProcState) || uidRec.setWhitelist) { <!--切换后台时候更新lastBackgroundTime--> uidRec.lastBackgroundTime = nowElapsed; if (!mHandler.hasMessages(IDLE_UIDS_MSG)) { <!--60s后更新--> mHandler.sendEmptyMessageDelayed(IDLE_UIDS_MSG, mConstants.BACKGROUND_SETTLE_TIME); } } 复制代码
延迟60s是为了防止60s之内多次切换APP导致的重复更新,系统只要保证60s内有一次就可以了。
private static final long DEFAULT_BACKGROUND_SETTLE_TIME = 60*1000; 复制代码
60s之后调用idleUids更新idle字段
final void idleUids() { synchronized (this) { final int N = mActiveUids.size(); if (N <= 0) { return; } final long nowElapsed = SystemClock.elapsedRealtime(); final long maxBgTime = nowElapsed - mConstants.BACKGROUND_SETTLE_TIME; long nextTime = 0; for (int i=N-1; i>=0; i--) { final UidRecord uidRec = mActiveUids.valueAt(i); <!--刚才切后台的时候已经更新过uidRec.lastBackgroundTime--> final long bgTime = uidRec.lastBackgroundTime; if (bgTime > 0 && !uidRec.idle) { <!--标准:后台存在时间超过mConstants.BACKGROUND_SETTLE_TIME--> if (bgTime <= maxBgTime) { uidRec.idle = true; uidRec.setIdle = true; doStopUidLocked(uidRec.uid, uidRec); } else { 如果被提前执行了,则在下一个60s到达的时候执行 if (nextTime == 0 || nextTime > bgTime) { nextTime = bgTime; } } } } if (nextTime > 0) { mHandler.removeMessages(IDLE_UIDS_MSG); mHandler.sendEmptyMessageDelayed(IDLE_UIDS_MSG, nextTime + mConstants.BACKGROUND_SETTLE_TIME - nowElapsed); } } } 复制代码
之前是前台,现在变后台,那么uidRec.lastBackgroundTime = nowElapsed赋值,再次切前台,uidRec.lastBackgroundTime清零,简而言之, 应用变为前台,UID状态马上变更为active状态,应用变为后台,即procState大于等于PROCESS_STATE_TRANSIENT_BACKGROUND时,如果持续在后台60s后,UID状态会变更为idle=true状态,不能startService;
通过其他应用startService的情况
跨应用startService已经不被推荐了,不过也容易模拟,在A应用中通过setAction+setPackage就可以startService:
var intent = Intent(); intent.setAction("com.snail.BackGroundService"); intent.setPackage("com.snail.labaffinity"); startService(intent) 复制代码
当然在B应用中AndroidManifest要暴露出来:
<service android:name=".service.BackGroundService" <!--是否独立进程,无关紧要--> android:process=":service" android:exported="true"> <intent-filter> <action android:name="com.snail.BackGroundService" /> </intent-filter> </service> 复制代码
这样A中startService同样要遵守不准后台启动的条件。比如如果B没启动过,直接在A中startService,则会Crash,如果B启动了,还没变成后台应用(退到后台没超过60S),则不会Crash。个人觉得通过adb命令startService也属于这种范畴,通过如下命令可以达到相同的效果。
am startservice -n com.snail.labaffinity/com.snail.labaffinity.service.BackGroundService 复制代码
如果APP没有启动就会看到如下日志:
app is in background uid null 复制代码
如果启动了,但是属于后台应用,就会看到如下日志,跟自己APP后台启动Service类似:
Not allowed to start service Intent { cmp=com.snail.labaffinity/.service.BackGroundService }: app is in background uid UidRecord{72bb30d u0a238 SVC idle change:idle|uncached procs:1 seq(0,0,0)} 复制代码
其实,startService不是看调用的APP处于何种状态,而是看Servic所在APP处于何种状态,因为看的是Servic所处的UidRecord的状态,UidRecord仅仅跟APP安装有关系,跟进程pid没关系。
特殊场景:进程通过Service恢复的场景
先看下如下代码,APP在启动的时候,在Application的onCreate中通过startService启动了一个服务,并且没有stop,这种场景下第一次通过Launcher冷启动没问题,如果我们在后台杀死APP,由于存在一个未stop的服务,系统会重新拉起该服务,也就是会重启一个进程,然后启动服务。
public class LabApplication extends Application { @Override public void onCreate() { super.onCreate(); Intent intent = new Intent( this, BackGroundService.class); startService(intent); } } public class BackGroundService extends Service { @Nullable @Override public IBinder onBind(Intent intent) { return null; } @Override public int onStartCommand(Intent intent, int flags, int startId) { LogUtils.v("onStartCommand"); } } 复制代码
在这个过程中,应用重启会复现如下Crash(禁止后台启动Service的Crash Log):
java.lang.RuntimeException: Unable to create application com.snail.labaffinity.app.LabApplication: java.lang.IllegalStateException: Not allowed to start service Intent { cmp=com.snail.labaffinity/.service.BackGroundService }: app is in background uid UidRecord{72bb30d u0a238 SVC idle change:idle|uncached procs:1 seq(0,0,0)} at android.app.ActivityThread.handleBindApplication(ActivityThread.java:5925) at android.app.ActivityThread.access$1100(ActivityThread.java:200) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1656) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loop(Looper.java:193) at android.app.ActivityThread.main(ActivityThread.java:6718) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858) 复制代码
Why?为什么冷启动没问题,后台杀死自启动恢复就有问题,看日志是因为当app is in background,Not allowed to start service,也就是后台进程不能通过startService启动服务,在LabApplication的onCreate中我们确实主动startService(intent),这个就是crash的原因,那为什么第一次没问题?在前文我们知道,通过Laucher启动应用是通过startActivity启动的,也就是存在一个resumeTopActivity的时机,在这个时机,APP的idle会被设置为false,也就是非后台应用,但是对于后台杀死又恢复的场景,他不是通过startActivity启动的,所以APP就算重启了,APP的idle还是true,是非激活的状态,也就是属于后台应用,不准通过startService启动服务(假设单进程)。
因为第一次冷启动时候,走正常启动Activity流程,新建进程,然后去AMS attachApplication,
@GuardedBy("this") private final boolean attachApplicationLocked(IApplicationThread thread, int pid, int callingUid, long startSeq) { ... <!-- 通知APP端创建Application--> thread.bindApplication(processName, appInfo, providers, app.instr.mClass, profilerInfo, app.instr.mArguments,...); ... boolean badApp = false; boolean didSomething = false; // See if the top visible activity is waiting to run in this process... if (normalMode) { try { <!-- 需要启动的Activity 关键点 --> if (mStackSupervisor.attachApplicationLocked(app)) { didSomething = true; } if (!badApp) { try { <!-- 需要恢复的Service--> didSomething |= mServices.attachApplicationLocked(app, processName); checkTime(startTime, "attachApplicationLocked: after mServices.attachApplicationLocked"); } 复制代码
第一次启动APP的时候,thread.bindApplication首先通知APP端启动Application,并执行onCreate,不过onCreate中的startService要等待AMS端上一个消息执行完毕(Handler保证),这个过程中mStackSupervisor.attachApplicationLocked(app)中会调用realStartActivityLocked启动Activity,先将UidRecord的idle给更新为false,attachApplicationLocked执行之后,才有可能轮到下一个消息startService执行,这个时候APP已经不是后台应用了,所以不会Crash。
boolean attachApplicationLocked(ProcessRecord app) throws RemoteException { final String processName = app.processName; boolean didSomething = false; ... final int size = mTmpActivityList.size(); <!--存在要启动的Activity--> for (int i = 0; i < size; i++) { final ActivityRecord activity = mTmpActivityList.get(i); if (activity.app == null && app.uid == activity.info.applicationInfo.uid && processName.equals(activity.processName)) { try { <!--走realStartActivityLocked--> if (realStartActivityLocked(activity, app, top == activity /* andResume */, true /* checkConfig */)) 复制代码
realStartActivityLocked会更新oom,并设置idle为false,因为有Activity要启动,就不在是后台进程,调用流程如下:
但是对于而对于杀死并通过Service恢复的进程,没有明确的startActivity,所以size = mTmpActivityList.size()这里size是0,不会走realStartActivityLocked,也就在进程恢复阶段,不会将APP归为前台应用,这个时候再AMS执行下一个消息启动Service的时候,就会告诉APP端,不能在后台启动应用。
如何解决这个问题
既然不能再后台偷偷启动,那只能显示启动,Google提供的方案是:startForegroundService()。并且在系统创建Service后,需要在一定时间内调用startForeground()让Service为用户可见通知,否则则系统将停止此Service,抛出ANR,如果不像让用户可见可以参考JobScheduler。不过本篇只看startForegroundService:
@Override public ComponentName startService(Intent service) { warnIfCallingFromSystemProcess(); return startServiceCommon(service, false, mUser); } @Override public ComponentName startForegroundService(Intent service) { warnIfCallingFromSystemProcess(); return startServiceCommon(service, true, mUser); } 复制代码
同普通startService的区别那就是startServiceCommon的第二参数boolean requireForeground 是true:
ComponentName startServiceLocked(IApplicationThread caller, Intent service ...} <!--fgRequired为true,不会检测启动后台限制--> 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) { return new ComponentName("?", "app is in background uid " + uidRec); } } ... <!--ServiceRecord赋值r.fgRequired 后面会用到--> r.fgRequired = fgRequired; <!--添加后面回调StartItem--> r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(), service, neededGrants, callingUid)); 复制代码
在AMS端startForegroundService跟普通startService区别, ServiceRecord的fgRequired被设置为true,然后走后续流程bringUpServiceLocked->realStartServiceLocked-> sendServiceArgsLocked,在sendServiceArgsLocked的时候,Service其实已经创建并启动(可以看Service启动流程),
private final void sendServiceArgsLocked(ServiceRecord r, boolean execInFg, boolean oomAdjusted) throws TransactionTooLargeException { ... ArrayList<ServiceStartArgs> args = new ArrayList<>(); while (r.pendingStarts.size() > 0) { ServiceRecord.StartItem si = r.pendingStarts.remove(0); ... if (r.fgRequired && !r.fgWaiting) { if (!r.isForeground) { <!--监听是否5S内startForeground--> scheduleServiceForegroundTransitionTimeoutLocked(r); } ... try { r.app.thread.scheduleServiceArgs(r, slice); } 复制代码
可以看到对于要求前台启动的Service fgRequired = true,并且第一次r.fgWaiting=false,所以会走scheduleServiceForegroundTransitionTimeoutLocked,
void scheduleServiceForegroundTransitionTimeoutLocked(ServiceRecord r) { if (r.app.executingServices.size() == 0 || r.app.thread == null) { return; } Message msg = mAm.mHandler.obtainMessage( ActivityManagerService.SERVICE_FOREGROUND_TIMEOUT_MSG); msg.obj = r; r.fgWaiting = true; mAm.mHandler.sendMessageDelayed(msg, SERVICE_START_FOREGROUND_TIMEOUT); } 复制代码
r.fgWaiting会被设置为true,scheduleServiceForegroundTransitionTimeoutLocked过一次后,就不会再次走。
static final int SERVICE_START_FOREGROUND_TIMEOUT = 10*1000; 复制代码
看9.0代码,是10s完成调用startForeground,否则在10s后Handler处理这一消息的时候,会停止该服务,并抛出Service的ANR异常。
void serviceForegroundTimeout(ServiceRecord r) { ProcessRecord app; synchronized (mAm) { if (!r.fgRequired || r.destroying) { return; } app = r.app; r.fgWaiting = false; stopServiceLocked(r); } if (app != null) { mAm.mAppErrors.appNotResponding(app, null, null, false, "Context.startForegroundService() did not then call Service.startForeground(): " + r); } } 复制代码
抛出异常栈如下
--------- beginning of crash E/AndroidRuntime: FATAL EXCEPTION: main Process: com.snail.labaffinity, PID: 21513 android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground() at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1768) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loop(Looper.java:164) at android.app.ActivityThread.main(ActivityThread.java:6494) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807) 复制代码
解决方案就是及时调用startForeground,对于O以后的还要注意Notification需要一个ChannelID
public class BackGroundService extends Service { @Override public void onCreate() { super.onCreate(); startForeground(); } private void startForeground() { String CHANNEL_ONE_ID = "com.snail.labaffinity"; String CHANNEL_ONE_NAME = "Channel One"; NotificationChannel notificationChannel = null; if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.O) { notificationChannel = new NotificationChannel(CHANNEL_ONE_ID, CHANNEL_ONE_NAME, NotificationManager.IMPORTANCE_DEFAULT); NotificationManager manager = (NotificationManager) getSystemService(NOTIFICATION_SERVICE); assert manager != null; manager.createNotificationChannel(notificationChannel); startForeground(1, new NotificationCompat.Builder(this, CHANNEL_ONE_ID).build()); } } } 复制代码
startForeground主要就是讲Service至于前台可见,同时取消掉刚才的那个延时Message,这样就不会检测并抛出异常了。
private void setServiceForegroundInnerLocked(final ServiceRecord r, int id, Notification notification, int flags) { <!--id不能为0--> if (id != 0) { ... if (r.fgRequired) { <!--设置fgRequired = false--> r.fgRequired = false; <!--设置 fgWaiting = false--> r.fgWaiting = false; alreadyStartedOp = true; <!--移除ActivityManagerService.SERVICE_FOREGROUND_TIMEOUT_MSG消息--> mAm.mHandler.removeMessages( ActivityManagerService.SERVICE_FOREGROUND_TIMEOUT_MSG, r); } 复制代码
不过不过这样的话,状态栏会有一个xxx正在运行的通知,体验不太好,如果是要完成某项任务完成后,最好主动stop掉。还有一个要注意的问题:在调用startForGround前不准调stop,否则也会抛出异常:
private final void bringDownServiceLocked(ServiceRecord r) { ... if (r.fgRequired) { r.fgRequired = false; r.fgWaiting = false; mAm.mAppOpsService.finishOperation(AppOpsManager.getToken(mAm.mAppOpsService), AppOpsManager.OP_START_FOREGROUND, r.appInfo.uid, r.packageName); mAm.mHandler.removeMessages( ActivityManagerService.SERVICE_FOREGROUND_TIMEOUT_MSG, r); if (r.app != null) { Message msg = mAm.mHandler.obtainMessage( ActivityManagerService.SERVICE_FOREGROUND_CRASH_MSG); msg.obj = r.app; msg.getData().putCharSequence( ActivityManagerService.SERVICE_RECORD_KEY, r.toString()); mAm.mHandler.sendMessage(msg); } } 复制代码
如果调用了startForegroundService,但是没有调用startForGround,此时调用stopService时,r.fgRequired = true,那么bringDownServiceLocked就会直接移除ActivityManagerService.SERVICE_FOREGROUND_TIMEOUT_MSG消息,并抛出ActivityManagerService.SERVICE_FOREGROUND_CRASH_MSG异常,其实只要在onCreate中startForeground就行了。
总结
- startService抛异常不是看调用的APP处于何种状态,而是看Servic所在APP处于何种状态,因为看的是UID的状态,所以这里重要的是APP而不仅仅是进程状态
- 不要通过Handler延迟太久再startService,否则可能会有问题
- 应用进入后台,60s之后就会变成idle状态,无法start其中的Service,但是可以通过startForegroundService来启动
- Application里面不要startService,否则恢复的时候可能有问题
- startForGround 要及时配合startForegroundService,否则会有各种异常。
以上所述就是小编给大家介绍的《Android O 后台startService限制浅析》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Java核心技术及面试指南
金华、胡书敏、周国华、吴倍敏 / 北京大学出版社 / 2018-9-1 / 59.00
本书根据大多数软件公司对高级开发的普遍标准,为在Java 方面零基础和开发经验在3 年以下的初级程序员提供了升级到高级工程师的路径,并以项目开发和面试为导向,精准地讲述升级必备的技能要点。具体来讲,本书围绕项目常用技术点,重新梳理了基本语法点、面向对象思想、集合对象、异常处理、数据库操作、JDBC、IO 操作、反射和多线程等知识点。 此外,本书还提到了对项目开发很有帮助的“设计模式”和“虚拟......一起来看看 《Java核心技术及面试指南》 这本书的介绍吧!