Android O 是下一代 android 系统，Android O Developer Preview 计划将为开发者提供针对下一个版本的 Android 系统提升您应用的兼容性和开发应用所需的所有功能。该软件是免费的，只需下载预览版工具使用即可。
附录官网计划预览：https://developer.android.com/preview/overview.html#timeline ，可查看有关该计划的介绍。
有关android O 的一些行为变更官网地址：https://developer.android.com/preview/behavior-changes.html
以下主要介绍一下androd O 中关于后台执行限制变更。
后台执行限制
每当应用程序在后台运行时，它会消耗某些设备的有限资源，如RAM。这可能会影响用户的使用体验，特别是如果用户正在使用资源密集型应用程序，例如玩游戏或观看视频。为了改善用户体验，Android O在后台运行时对应用程序可以执行的操作施加限制。
－OverView
Android系统中的许多应用和服务可以同时运行。例如，用户可以在一个窗口中玩游戏，同时在另一个窗口中浏览网页，在另一应用中播放音乐。一次运行的应用程序越多，系统上的负载就越多。如果其他应用程序或服务在后台运行，则会在系统上增加额外的负载，可能音乐应用程序会突然关闭，这会导致用户体验不佳;
为了降低这些问题的机会，Android O对用户不直接与他们进行交互的应用程序可以执行哪些操作。应用程式有两种限制：
后台服务限制：当应用程序空闲时，使用后台服务有限制。这不适用于对用户更为重要的前台服务。
广播限制：除了有限的例外，应用程序不能使用其清单来注册隐式广播。他们仍然可以在运行时注册这些广播，他们可以使用清单来注册针对他们的应用的明确的广播。
注意：默认情况下，这些限制仅适用于以 Android O 为目标的应用。但是，即使该应用尚未定位到Android O，用户也可以从“设置”界面为任何应用启用这些限制。
在大多数情况下，应用程序可以通过使用 JobScheduler 作业解决这些限制。该方法允许应用程序安排在应用程序没有正常运行时执行工作，但仍然给予系统以不影响用户体验的方式安排这些作业的余地。Android O提供了一些改进JobScheduler，可以更轻松地用计划的作业来替换服务和广播接收器;
－后台服务限制
在后台运行的服务可能会消耗设备资源，这也会导致更用户体验。为了减轻此问题，系统对服务应用了一些限制。
系统区分 前台 和 后台 应用程序。（为了服务限制的目的，背景的定义与内存管理所使用的定义不同;一个应用程序可能在内存管理方面属于后台，但在前台涉及其启动服务的能力。）符合一下条件之一的应用程序会被认为是在前台：
１有一个可见的活动，无论活动是启动还是暂停。
２有一个前台服务。
３另一个前台应用程序通过绑定到其中一个服务或通过使用其内容提供者之一连接到应用程序。如以下处于前台的应用程序：
● IME
● Wallpaper service
● Notification listener
● Voice or text service
不符合以上条件，应用程序则被认为是在后台。
注意：这些规则不会以任何方式影响绑定的服务。如果应用程序定义了绑定的服务，则其他组件可以绑定到该服务，无论您的应用程序是否在前台。
当应用程序处于前台时，它可以自由创建和运行前台和后台服务。当应用程序进入后台时，它有一个几分钟的窗口，它仍然允许创建和使用服务。在该窗口的最后，该应用被认为是空闲的。在这个时候，系统会停止应用的后台服务，就像应用程序调用了服务的Service.stopSelf()方法一样。
在许多情况下，您的应用程序可以使用 JobScheduler 作业替换后台服务。例如，CoolPhotoApp 需要检查用户是否收到了来自朋友的共享照片，即使应用程序未在前台运行。以前，该应用程序使用后台服务来检查应用程序的云存储。要迁移到Android O，开发人员可以使用定期启动的计划作业来替换后台服务，定期启动，查询服务器，然后退出。
在Android O之前，创建前台服务的通常方法是创建后台服务，然后将该服务提升到前台。但在Android O 中，系统不允许后台应用创建后台服务。因此，Android O引入了 Context.startForegroundService() 在前台启动新服务的新方法。系统创建服务后，应用程序有五秒钟可以调用该服务的 startForeground() 方法来显示一个用户可见的有关该服务的通知。如果该应用在时间限制内没有 startForeground()，系统将停止该服务并声明该应用为ANR。
－广播限制
如果应用程序注册接收广播，则应用程序的接收方在每次发送广播时都会消耗资源。如果太多的应用程序注册以基于系统事件接收广播，触发广播的系统事件可能导致所有这些应用程序快速连续地消耗资源，从而削弱用户体验。为了减轻这个问题，Android 7.0（API 25级）对广播进行了限制，如背景优化所述。Android O使这些限制更加严格。
针对Android O的应用程序不能再在其 manifest 文件中注册隐式广播接收器。一个隐式广播 是没有指定一个专门的应用程序的广播。例如，ACTION_PACKAGE_REPLACED是一个隐式广播，因为它被发送到所有注册的监听器，让他们知道设备上的某些包被替换。然而，ACTION_MY_PACKAGE_REPLACED这不是一个隐含的广播，因为它只发送到包被被替换的应用程序，无论有多少其他应用程序已经注册了该广播的监听器。
应用程序可以继续在其清单中注册显式广播。
应用程序可以Context.registerReceiver()在运行时动态注册接收器进行任何广播，无论是隐式还是显式。
需要签名许可的广播将免除此限制，因为这些广播仅发送到使用相同证书签署的应用程序，而不是设备上的所有应用程序。
在许多情况下，以前注册为隐式广播的应用程序可以通过使用JobScheduler作业获得类似的功能。例如，社交照片应用程序可能需要不时对其数据执行清理，并且在设备连接到充电器时更喜欢这样做。以前，应用程序ACTION_POWER_CONNECTED在其 manifest 文件中注册了一个接收器;当应用程序收到广播时，它会检查是否需要清理。为了迁移应用到Android O，需在应用程序的 manifest 文件中删除该接收器，而应用程序会自己调度，在设备空闲并充电时运行的清理作业。
注意：现在许多隐性广播不受此限制。应用程序可以继续在其manifest 文件中注册这些广播的接收者，无论应用程序的API级别如何。有关免除广播的列表，请参阅隐式广播例外。
