Android 8（O）版本适配指南
后台执行限制
每次在后台运行时，应用都会消耗一部分有限的设备资源，例如 RAM。 这可能会影响用户体验，如果用户正在使用占用大量资源的应用（例如玩游戏或观看视频），影响会尤为明显。 为了提升用户体验，Android 8.0（API 级别 26）对应用在后台运行时可以执行的操作施加了限制。
例如，用户可以在一个窗口中玩游戏，同时在另一个窗口中浏览网页，并使用第三个应用播放音乐。 如果还有更多的应用或 Service 在后台运行，则会对系统造成很大的负担，进而可能导致用户体验下降；例如，音乐应用可能会突然关闭。
为了降低发生这些问题的几率，Android 8.0 对应用在用户不与其直接交互时可以执行的操作施加了限制。 应用在两个方面受到限制：
-
后台 Service 限制：处于空闲状态时，应用可以使用的后台 Service 存在限制。 这些限制不适用于前台 Service，因为前台 Service 更容易引起用户注意。
-
广播限制：除了有限的例外情况，应用无法使用清单注册隐式广播。 它们仍然可以在运行时注册这些广播，并且可以使用清单注册专门针对它们的显式广播。
默认情况下，这些限制仅适用于适配 Android 8.0（API 级别 26）或更高版本的应用。 然而，即使应用适配的 API 级别低于 26，用户也可以从 Settings 屏幕为任意应用启用其中大多数限制。
1、后台 Service 限制
Android系统将应用分为前台和后台应用，满足以下任意条件，应用将被视为处于前台：
- 具有可见 Activity（不管该 Activity 已启动还是已暂停）。
- 具有前台 Service。
- 另一个前台应用已关联到该应用（不管是通过绑定到其中一个 Service，还是通过使用其中一个内容提供程序）。 例如以下应用绑定到应用的 Service，那么应用也会处于前台。
输入法
壁纸 Service
通知侦听器
语音或文本 Service
如果以上条件均不满足，应用将被视为处于后台。
应用处于前台时，可以自由创建和运行前台与后台 Service。 进入后台时，在一个持续数分钟的时间窗内，应用仍可以创建和使用 Service。 在该时间窗结束后，应用将被视为处于空闲状态。 此时，系统将停止应用的后台 Service，就像应用已经调用 Service 的 Service.stopSelf() 方法一样。
在很多情况下都可以使用 JobScheduler 作业替换后台 Service。 例如，CoolPhotoApp 需要检查用户是否已经收到好友共享的照片，即使该应用未在前台运行也需如此。 之前，应用使用一种会检查其云存储的后台 Service。 为了迁移到 Android 8.0（API 级别 26），开发者使用一个计划作业替换了这种后台 Service，该作业将按一定周期启动，查询服务器，然后退出。
在 Android 8.0 之前，创建前台 Service 的方式通常是先创建一个后台 Service，然后将该 Service 推到前台。 Android 8.0 有一项复杂功能：系统不允许后台应用创建后台 Service。 因此，Android 8.0 引入了一种全新的方法，即 startForegroundService()，以在前台启动新 Service。 在系统创建 Service 后，应用有五秒的时间来调用该 Service 的 startForeground() 方法以显示新 Service 的用户可见通知。 如果应用在此时间限制内未调用startForeground()，则系统将停止此 Service 并声明此应用为 ANR。
2、广播限制
如果应用注册为接收广播，则在每次发送广播时，应用的接收器都会消耗资源。 如果多个应用注册为接收基于系统事件的广播，则会引发问题：触发广播的系统事件会导致所有应用快速地连续消耗资源，从而降低用户体验。 为了缓解这一问题，Android 7.0（API 级别 24）对广播施加了一些限制，如后台优化中所述。 Android 8.0（API 级别 26）让这些限制更为严格。
- 适配 Android 8.0 或更高版本的应用无法继续在其清单中为隐式广播注册广播接收器。 隐式广播是一种不专门针对该应用的广播。 例如，
[ACTION_PACKAGE_REPLACED](https://developer.android.google.cn/reference/android/content/Intent#ACTION_PACKAGE_REPLACED)就是一种隐式广播，因为该广播将被发送给所有已注册侦听器，让后者知道设备上的某些软件包已被替换。 不过，ACTION_MY_PACKAGE_REPLACED 不是隐式广播，因为不管已为该广播注册侦听器的其他应用有多少，它都会只被发送给软件包已被替换的应用。 - 应用可以继续在它们的清单中注册显式广播。
- 应用可以在运行时使用 Context.registerReceiver() 为任意广播（不管是隐式还是显式）注册接收器。
- 需要签名权限的广播不受此限制所限，因为这些广播只会发送到使用相同证书签名的应用，而不是发送到设备上的所有应用。
在许多情况下，之前注册隐式广播的应用使用 JobScheduler 作业可以获得类似的功能。 例如，一款社交照片应用可能需要不时地执行数据清理，并且倾向于在设备连接到充电器时执行此操作。 之前，应用已经在清单中为ACTION_POWER_CONNECTED 注册了一个接收器；当应用接收到该广播时，它会检查清理是否必要。 为了迁移到 Android 8.0 或更高版本，应用将该接收器从其清单中移除。 应用将清理作业安排在设备处于空闲状态和充电时运行。
权限
在 Android 8.0 之前，如果应用在运行时请求权限并且被授予该权限，系统会错误地将属于同一权限组并且在清单中注册的其他权限也一起授予应用。
对于针对 Android 8.0 的应用，此行为已被纠正。系统只会授予应用明确请求的权限。然而，一旦用户为应用授予某个权限，则所有后续对该权限组中权限的请求都将被自动批准。
例如，假设某个应用在其清单中列出 READ_EXTERNAL_STORAGE 和 WRITE_EXTERNAL_STORAGE。应用请求 READ_EXTERNAL_STORAGE，并且用户授予了该权限。如果该应用针对的是 API 级别 24 或更低级别，系统还会同时授予 WRITE_EXTERNAL_STORAGE，因为该权限也属于同一 STORAGE 权限组并且也在清单中注册过。如果该应用针对的是 Android 8.0，则系统此时仅会授予 READ_EXTERNAL_STORAGE；不过，如果该应用后来又请求 WRITE_EXTERNAL_STORAGE，则系统会立即授予该权限，而不会提示用户。
提醒窗口
使用 SYSTEM_ALERT_WINDOW 权限的应用无法再使用以下窗口类型来在其他应用和系统窗口上方显示提醒窗口：
相反，应用必须使用名为 TYPE_APPLICATION_OVERLAY 的新窗口类型。
使用 TYPE_APPLICATION_OVERLAY 窗口类型显示应用的提醒窗口时，请记住新窗口类型的以下特性：
- 应用的提醒窗口始终显示在状态栏和输入法等关键系统窗口的下面。
- 系统可以移动使用 TYPE_APPLICATION_OVERLAY 窗口类型的窗口或调整其大小，以改善屏幕显示效果。
- 通过打开通知栏，用户可以访问设置来阻止应用显示使用 TYPE_APPLICATION_OVERLAY 窗口类型显示的提醒窗口。
隐私性
Android 8.0 对平台做出了以下与隐私性有关的变更。
-
现在，平台改变了标识符的处理方式。
-
对于在 OTA 之前安装到某个版本 Android 8.0（API 级别 26）的应用，除非在 OTA 后卸载并重新安装，否则 ANDROID_ID 的值将保持不变。要在 OTA 后在卸载期间保留值，开发者可以使用密钥/值备份关联旧值和新值。
- 对于安装在运行 Android 8.0 的设备上的应用，ANDROID_ID 的值现在将根据应用签署密钥和用户确定作用域。应用签署密钥、用户和设备的每个组合都具有唯一的 ANDROID_ID 值。因此，在相同设备上运行但具有不同签署密钥的应用将不会再看到相同的 Android ID（即使对于同一用户来说，也是如此）。
- 只要签署密钥相同（并且应用未在 OTA 之前安装到某个版本的 O），ANDROID_ID 的值在软件包卸载或重新安装时就不会发生变化。
- 即使系统更新导致软件包签署密钥发生变化，ANDROID_ID 的值也不会变化。
要借助一个简单的标准系统实现应用获利，请使用广告 ID。广告 ID 是 Google Play 服务针对广告服务提供的唯一 ID，此 ID 可由用户重置。
-
查询
net.hostname系统属性返回的结果为空。
