Nothing makes an android developer more crazy than a new version of Android.
Android O 在 2017 年 8 月已经正式发布了,Android P 的预览版也已推出,今年下半年也将正式发布。
由于公司的产品面向海外用户较多,大多都已经是 Android 最新版本,且 Google 明确提出:从 2018 年 8 月起,所有向 Google Play 提交的新应用都必须使用 API level 26 (Android 8.0) 及以上版本开发;2018 年 11 月起,所有 Google Play 的现有应用更新同样必须使用 API level 26 及以上版本。因此必须对 Android O 作全面的适配。
1. Android O 新特性
官方文档已经详细描述了 Android O 的新特性和 API,对开发者而言适配 Android O 需要关注以下行为变更:
- 后台服务限制
- 隐式广播限制
- 后台位置限制
- 通知渠道
- 权限
2. 后台服务限制
2.1 什么是前台应用
满足以下任意条件的应用被视为处于前台:
- 具有可见的 Activity
- 具有前台服务
- 另一个前台应用关联到该应用,如输入法、壁纸服务、语音服务等
如果以上条件均不满足,应用将被视为处于后台。
2.2 为什么要限制后台服务
后台服务(如网络下载、数据同步等)会消耗手机的内存和电量,影响性能。如果大量应用都开启了后台服务,会严重影响用户体验。
后台服务限制和隐式广播限制从根本上杜绝了后台应用异常消耗系统资源,有助于大幅度降低应用后台行为对设备体验的影响。
2.3 什么是后台服务限制
应用在后台期间保留其后台服务的能力将受到限制。如果应用处于后台时调用了 startService()
将会抛出 IllegalStateException
,除非:
- 应用已经处于前台,则可以调用
startService()
,不会抛出IllegalStateException
,但一旦进入后台,后台应用将被置于一个临时白名单中,位于白名单中时,应用可以无限制地启动服务,其后台服务也可以运行。但这个时间窗一过,应用进入空闲状态,后台服务就会被销毁(Nexus 5X 8.0 系统上测试不到1分钟) - 启动前台服务
- 绑定服务,即使应用处于后台也不受影响
如果
targetSdkVersion < 26
,是否可以绕过这些限制?
不可以,即使 targetSdkVersion < 26
,用户也可以在 Android O 的设备上选择开启这些限制。
2.4 解决方案
- Job Scheduler
- Foreground Service
- Firebase Cloud Messaging and Temporary Service Whitelist
2.5 Job Scheduler
JobScheduler is smarter about when jobs should be run and can batch them together so that devices stay asleep as much as possible.
Google 在 Android 5.0 中引入 JobScheduler
来执行一些需要满足特定条件但不紧急的后台任务,利用 JobScheduler
来执行这些特殊的后台任务来减少电量的消耗。可以将其理解成定时任务,以替代 IntentService + AlarmManager
。
开发者可以设定需要执行的任务 JobService
,以及任务执行的条件 JobInfo
,JobScheduler
会将任务加入到队列。在特定的条件满足时 Android 系统会去批量的执行所有应用的这些任务,而非对每个应用的每个任务单独处理。这样可以减少设备被唤醒的次数。
2.5.1 JobService
先来看一下 JobService
, 它继承自 Service
,除了 Service
的一些生命周期方法,又增加了 onStartJob
和 onStopJob
来处理自定义任务。
public class MyJobService extends JobService {
@Override
public boolean onStartJob(JobParameters params) {
Log.i(TAG, "onStartJob");
doJob(params);
return true;
}
@Override
public boolean onStopJob(JobParameters params) {
Log.i(TAG, "onStopJob");
// whether or not you would like JobScheduler to automatically retry your failed job.
return false;
}
private void doJob(JobParameters params) {
// I am on the main thread, so if you need to do background work,
// be sure to start up an AsyncTask, Thread, or IntentService!
}
}
使用 JobService
需要在清单里申请 android.permission.BIND_JOB_SERVICE
权限。
需要注意的是,在 com.android.server.job.JobServiceContext
类中声明了 EXECUTING_TIMESLICE_MILLIS
。
/** Amount of time a job is allowed to execute for before being considered timed-out. */
private static final long EXECUTING_TIMESLICE_MILLIS = 10 * 60 * 1000; // 10mins.
经过测试,不管应用是否处于前台,JobService
都不能无限期运行,有 10 分钟的超时时间,会自动销毁,在 Android L 上这个时间是 1 分钟。因此 Job Scheduler
适用于短耗时的后台任务,不适用于连续的长时间的后台服务。
2.5.2 使用 Job Scheduler
实施一个 Job 包含以下步骤:
-
JobInfo
:采用 Builder 模式,设置 Job 执行的条件和时机 -
JobService
:Service
的子类,Job 执行时的具体行为 -
android.permission.BIND_JOB_SERVICE
:JobService
的子类需要授予该权限 -
JobScheduler
:将一个 Job 添加到工作队列中,调用JobScheduler.enqueue()
或者JobScheduler.schedule
。当工作队列运行时,它可以将待定的工作从队列中剥离并处理(替代IntentService
)。
void scheduleJob() {
ComponentName componentName = new ComponentName(this, MyService.class);
JobInfo.Builder builder = new JobInfo.Builder(JOB_ID, componentName)
.setMinimumLatency(2000)
.setOverrideDeadline(5000)
// ...
.setRequiredNetworkType(JobInfo.NETWORK_TYPE_NONE);
JobScheduler jobScheduler = (JobScheduler) getSystemService(Context.JOB_SCHEDULER_SERVICE);
jobScheduler.schedule(builder.build());
}
具体使用可以参考 Scheduling jobs like a pro with JobScheduler
2.5.3 在 API 低于 21 使用 Job Scheduler
JobScheduler
是Google 在 API 21 引入 的,那么对于 API 小于 21 该如何处理。
- minSdkVersion >= 21:JobScheduler
- minSdkVersion < 21:Firebase JobDispatcher,API 和
JobScheduler
基本相似,但需要引入 Google Play Services,会增加 apk 的大小。 - 如果 minSdkVersion < 21,可以做一层封装,业务方只调一套,也可以只用Firebase JobDispatcher 兼容,看业务方需求。
2.5.4 JobIntentService
JobIntentService
继承自 Service
,可以用来简化处理任务。调用 JobIntentService.enqueueWork()
,即可执行任务。它会根据 API 版本进一步执行
- 在 Android O 及之后的设备上,调用
JobScheduler.enqueue()
- 在 Android O 之前的设备上,调用
Context.startService()
。
JobIntentService
需要 android.permission.WAKE_LOCK
的权限
2.6 Foreground Service
Job Scheduler
只适用于短耗时的后台任务,如果需要在后台执行长期的任务,推荐使用 Foreground Service
。这样应用会在通知栏展示进行中
的通知,以告知用户你的应用正在运行后台任务。
在 Android O 之前,创建前台服务的方式通常是先创建一个后台服务,然后将该服务推到前台。
但对于 Android O,系统不允许后台应用创建后台服务。 因此,Android O 引入了一种全新的方法,即
ContextCompat.startForegroundService()
,以在前台启动新服务。
调用
ContextCompat.startForegroundService()
可以创建一个前台服务,相当于创建一个后台服务并将它推到前台。创建一个用户可见的
Notification
。必须立即(在5秒内)调用该服务的
startForeground(id: Int, notification: Notification)
方法,否则将停止服务并抛出android.app.RemoteServiceException: Context.startForegroundService() did not then call Service.startForeground()
异常。
2.7 Firebase Cloud Messaging and Temporary Service Whitelist
使用 FCM 需要引入不低于 10.2.1 的 Google Play Services SDK。
当应用出现以下情况时,该应用可以被暂时加入到一个白名单里,应用可以像跑前台服务一样跑后台服务:
- 处理高优先级的 FCM 消息
- 接收广播,如短信/彩信消息
- 点击通知执行 PendingIntent
这种情况常用的一个场景是,我们的应用需要通过请求后台服务更新数据,可以给我们的应用发送一个高优先级的 FCM 消息,即使系统处于休眠状态,也能马上收到 FCM 消息,被加到白名单后,就可以启动一个后台服务来更新数据了。
通过以上情况启动的也必须是短耗时的任务,如
JobScheduler
或者JobIntentService
。
2.8 解决方案
- 对于短耗时的特定任务,采用
Job Scheduler
。 - 对于需要长期执行的服务,采用
Foreground Service
。 - 对于一些三方的服务,无法修改,如果没有适配 Android O,可以在启动这些服务前启动一个空的
Foreground Service
,这样应用处于前台,就可以启动这些后台服务了。
如果在应用初始化后启动一个空的
Foreground Service
,保证应用处于前台,则旧的Service
都可以正常,修改量最小。但不推荐。
3. 隐式广播限制
3.1 为什么要限制隐式广播
如果在 AndroidManifest.xml
中随意地声明隐式广播,那么任何时候收到响应系统事件都会唤醒应用,即使应用当前处于休眠状态,导致异常消耗系统资源。
3.2 什么是隐式广播限制
应用无法在 AndroidManifest.xml
中声明隐式广播接收器,以获得绝大部分响应系统事件的后台能力。
显式广播依然能在
AndroidManifest.xml
中注册。
3.3 解决方案
- Broadcast Whitelist
- Scheduling Jobs
- Dynamic Broadcasts
3.3.1 白名单
以下事件依然能在 AndroidManifest.xml
中声明隐式广播接收器,可以正常使用。
- ACTION_LOCKED_BOOT_COMPLETED, ACTION_BOOT_COMPLETED
- ACTION_USER_INITIALIZE
- ACTION_LOCALE_CHANGED
- ACTION_USB_ACCESSORY_ATTACHED, ACTION_USB_ACCESSORY_DETACHED, ACTION_USB_DEVICE_ATTACHED, ACTION_USB_DEVICE_DETACHED
- ACTION_HEADSET_PLUG
- ACTION_CONNECTION_STATE_CHANGED, ACTION_CONNECTION_STATE_CHANGED, ACTION_ACL_CONNECTED, ACTION_ACL_DISCONNECTED
- ACTION_CARRIER_CONFIG_CHANGED
- LOGIN_ACCOUNTS_CHANGED_ACTION
- ACTION_PACKAGE_DATA_CLEARED
- ACTION_PACKAGE_FULLY_REMOVED
- ACTION_NEW_OUTGOING_CALL
- ACTION_DEVICE_OWNER_CHANGED
- ACTION_EVENT_REMINDER
- ACTION_MEDIA_MOUNTED, ACTION_MEDIA_CHECKING, ACTION_MEDIA_UNMOUNTED, ACTION_MEDIA_EJECT, ACTION_MEDIA_UNMOUNTABLE
- SMS_RECEIVED_ACTION, WAP_PUSH_RECEIVED_ACTION
3.3.2 JobScheduler
JobScheduler
可以用来执行一些需要满足特定条件的后台任务,如设备网络状态变化、设备充电状态变化、低电量等。因此大多数情况下,之前注册隐式广播的应用使用 JobScheduler
可以获得类似的功能。
3.3.3 动态注册广播
依然能用 Context.registerReceiver()
动态的注册隐式广播,不受影响。但务必在不需要的时候(如生命周期结束)调用 Context.unregisterReciever()
。
4. 后台位置限制
在 Android O 上,应用处于后台时降低了后台应用接收位置更新的频率,具体的位置行为和受影响的 API 可以查看官方文档。
5. 通知渠道
所有通知的实现都需要提供通知渠道(Notification ChannelId),否则通知在 Android O 系统上无法正常展示,会弹 Toast
提示 Developer warning for package XXX,Failed to post notification on channel “null”.
。
if (Build.VERSION.SDK_INT>= Build.VERSION_CODES.O) {
NotificationManager manager = (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);
NotificationChannelGroup group = new NotificationChannelGroup(GROUP_ID, GROUP_NAME);
manager.createNotificationChannelGroup(group);
NotificationChannel channel = new NotificationChannel(CHANNEL_ID, CHANNEL_NAME, NotificationManager.IMPORTANCE_DEFAULT);
channel.setGroup(GROUP_ID);
// ...
manager.createNotificationChannel(channel);
notification = new Notification.Builder(getApplicationContext(), CHANNEL_ID)
// ...
.build();
} else {
notification = new NotificationCompat.Builder(getApplicationContext(), CHANNEL_ID)
// ...
.build();
}
6. 权限
Android O 之前,申请一个子权限(如写外部存储权限),会自动获取权限组中其他子权限(读外部存储权限)。组内其他子权限可以直接使用,无需申请。
Android O 修复了这个错误。在 Android O 上,申请一个子权限,组内其他子权限不会自动获取,需要再次申请才能使用。但不会弹出系统的权限申请框,将被自动批准。
7. Reference
- Android Oreo
- Keep those background Services working when targeting Android Oreo (26)
- Exploring Background Execution Limits on Android Oreo
- How to handle background services in ANDROID O?
- Preparing for Android 0: The Death of Background Services
- Meeting Google Play requirements for target API level
本文是 慌不要慌 原创,发表于 https://danke77.github.io/,请阅读原文支持原创 https://danke77.github.io/2018/06/09/target-android-o/,版权归作者所有,转载请注明出处。