原文:https://source.android.com/devices/tech/power/app_mgmt
在Android 9及更高版本中,平台能监测应用程序对设备的电池寿命产生负面影响的行为。平台使用并评估设置规则以提供一个用户体验流程,使用户可以选择限制违反规则的应用程序。
在Android 8.0及更早版本中,通过Doze、App Standby、后台限制和后台定位限制等功能进行了限制。然而,一些应用程序继续表现出不良行为,其中一些在Android vitals中有所描述。Android 9引入了一个操作系统基础架构,可以根据可以随时更新的设置规则来检测和限制应用程序。
后台限制
用户可以选择限制应用程序,系统也会提示检测到的对设备运行状况产生负面影响的应用程序。
受限的应用:
- 仍然可以被用户启动。
- 无法运行作业/闹钟或在后台使用网络。
- 无法运行前台服务。
- 可以被用户改为不受限制的应用程序。
设备实现者可以为应用添加其他限制:
- 限制应用程序自动重启。
- 限制服务受限(高风险)。
当受限应用程序处于后台时,它们不会消耗任何设备资源,例如内存、CPU和电池。当用户未主动使用这些应用时,后台受限应用不应影响设备运行状况。但是,当用户启动应用程序时,相同的应用程序应该完全正常运行。
使用自定义实现
设备实现者可以继续使用其自定义方法对应用程序应用限制。
警告:未来版本可能会破坏设备实施者的自定义。我们建议在AOSP中采用Android 9 App Restrictions架构。
集成应用程序限制
以下部分概述了如何在设备上定义和集成应用程序限制。如果您使用Android 8.x或更早版本的应用限制方法,请仔细阅读以下各节,了解Android 9中的更改。
设置AppOpsManager标志
限制应用时,在 AppOpsManager
中设置相应的标记。以下是
packages/apps/Settings/src/com/android/settings/fuelgauge/BatteryUtils.java
中的示例代码段:
public void setForceAppStandby(int uid, String packageName,
int mode) {
final boolean isPreOApp = isPreOApp(packageName);
if (isPreOApp) {
// 控制O以前的app是否可以在后台运行
mAppOpsManager.setMode(AppOpsManager.OP_RUN_IN_BACKGROUND, uid, packageName, mode);
}
// 控制app是否可以在后台运行
mAppOpsManager.setMode(AppOpsManager.OP_RUN_ANY_IN_BACKGROUND, uid, packageName, mode);
}
确保isBackgroundRestricted返回true
限制应用时,确保 ActivityManager.isBackgroundRestricted()返回 true。
记录限制的原因
限制应用程序时,记录限制的原因。以下是packages/apps/Settings/src/com/android/settings/fuelgauge/batterytip/actions/RestrictAppAction.java
中记录的示例代码段 :
mBatteryUtils.setForceAppStandby(mBatteryUtils.getPackageUid(packageName), packageName,AppOpsManager.MODE_IGNORED);
if (CollectionUtils.isEmpty(appInfo.anomalyTypes)) {
// 无异常类型(anomalyTypes)时只记录上下文
mMetricsFeatureProvider.action(mContext,
MetricsProto.MetricsEvent.ACTION_TIP_RESTRICT_APP, packageName,
Pair.create(MetricsProto.MetricsEvent.FIELD_CONTEXT,metricsKey));
} else {
// 记录所有异常类型(anomalyTypes)
for (int type : appInfo.anomalyTypes) {
mMetricsFeatureProvider.action(mContext,
MetricsProto.MetricsEvent.ACTION_TIP_RESTRICT_APP, packageName,
Pair.create(MetricsProto.MetricsEvent.FIELD_CONTEXT, metricsKey),
Pair.create(MetricsProto.MetricsEvent.FIELD_ANOMALY_TYPE, type));
}
}
type
应被 AnomalyType
的值替换。
设备实现者可以使用的常量定在src/com/android/settings/fuelgauge/batterytip/StatsManagerConfig.java
文件中:
public @interface AnomalyType {
// 表示异常检测中的错误条件
int NULL = -1;
// 异常类型与任何其他定义的类型都不匹配
int UNKNOWN_REASON = 0;
// 在未充电的情况下,应用程序持有局部(屏幕关闭)唤醒锁超过了时间阈值
int EXCESSIVE_WAKELOCK_ALL_SCREEN_OFF = 1;
// 在未充电的情况下,应用程序在后台超过了最大唤醒次数
int EXCESSIVE_WAKEUPS_IN_BACKGROUND = 2;
// 在未充电的情况下,应用程序过于频繁地进行了未经优化的蓝牙扫描
int EXCESSIVE_UNOPTIMIZED_BLE_SCAN = 3;
// 应用程序在后台运行超过了时间阈值
int EXCESSIVE_BACKGROUND_SERVICE = 4;
// 在未充电的情况下,应用程序超过了最大WiFi扫描次数
int EXCESSIVE_WIFI_SCAN = 5;
// 应用程序超过最大闪存写入次数
int EXCESSIVE_FLASH_WRITES = 6;
// 应用程序在后台使用的内存超过了最大内存
int EXCESSIVE_MEMORY_IN_BACKGROUND = 7;
// 应用程序的渲染率大于700毫秒,超过了帧数的最大百分比
int EXCESSIVE_DAVEY_RATE = 8;
// 应用程序的渲染率大于16毫秒,超过了帧数的最大百分比
int EXCESSIVE_JANKY_FRAMES = 9;
// 应用程序超过了最大冷启动时间(自上次系统启动以来,应用程序尚未启动,已死亡或被杀死)
int SLOW_COLD_START_TIME = 10;
// 应用程序超过了最长热启动时间 (应用程序和Activity已经在内存中)
int SLOW_HOT_START_TIME = 11;
// 应用程序超出了最大热启动时间
//(应用程序已经在内存中,但Activity 尚未创建或已从内存中删除)
int SLOW_WARM_START_TIME = 12;
// 应用程序在后台超过了最大同步次数
int EXCESSIVE_BACKGROUND_SYNCS = 13;
// 应用程序在后台超过了最大GPS扫描次数
int EXCESSIVE_GPS_SCANS_IN_BACKGROUND = 14;
// 在未充电的情况下,应用程序计划作业超过了最大数目
int EXCESSIVE_JOB_SCHEDULING = 15;
// 应用程序在后台超过了最大移动网络流量
int EXCESSIVE_MOBILE_NETWORK_IN_BACKGROUND = 16;
// 在未充电的情况下,应用程序持有的WiFi锁定超过了最大时长
int EXCESSIVE_WIFI_LOCK_TIME = 17;
// 应用程序安排的一个作业运行超时
int JOB_TIMED_OUT = 18;
// 应用程序在后台执行未经优化的蓝牙扫描超时
int LONG_UNOPTIMIZED_BLE_SCAN = 19;
// 应用程序超过了后台最大ANR率
int BACKGROUND_ANR = 20;
// 应用程序超过了后台最大crash 率
int BACKGROUND_CRASH_RATE = 21;
// 应用程序超过了最大ANR循环速率
int EXCESSIVE_ANR_LOOPING = 22;
// 应用程序超过了最大ANR率
int EXCESSIVE_ANRS = 23;
// 应用程序超过了最大crash 率
int EXCESSIVE_CRASH_RATE = 24;
// 应用程序超过了最大crash循环速率
int EXCESSIVE_CRASH_LOOPING = 25;
// 应用程序因无更多文件描述符可用而崩溃
int NUMBER_OF_OPEN_FILES = 26;
}
当用户或系统删除应用程序的限制时,您必须记录删除限制的原因。以下是packages/apps/Settings/src/com/android/settings/fuelgauge/batterytip/actions/UnrestrictAppAction.java
中记录的示例代码段 :
public void handlePositiveAction(int metricsKey) {
final AppInfo appInfo = mUnRestrictAppTip.getUnrestrictAppInfo();
// 清除强制应用程序待机状态,然后应用程序可以在后台运行
mBatteryUtils.setForceAppStandby(appInfo.uid, appInfo.packageName,
AppOpsManager.MODE_ALLOWED);
mMetricsFeatureProvider.action(mContext,
MetricsProto.MetricsEvent.ACTION_TIP_UNRESTRICT_APP, appInfo.packageName,
Pair.create(MetricsProto.MetricsEvent.FIELD_CONTEXT, metricsKey));
}
测试应用程序限制
要在Android 9.x及更高版本中测试应用限制的行为,请使用以下命令之一:
- 将应用程序置于应用程序限制中:
$ appops set package-name RUN_ANY_IN_BACKGROUND ignore
- 要将其移出并恢复默认行为:
$ appops set package-name RUN_ANY_IN_BACKGROUND allow
- 让应用程序在后台立即空闲:
$ am make-uid-idle [--user user-id | all | current] package-name
- 将一个
package
添加进tempwhitelist
一段时间:
$ cmd deviceidle tempwhitelist [-u user] [-d duration] [package package-name]
- 从用户
whitelist
中添加或删除package
:
$ cmd deviceidle whitelist [+/-]package-name
- 检测
jobscheduler
和alarm manager
的内部状态:
$ dumpsys jobscheduler
$ dumpsys alarm
App Standby
App Standby通过推迟用户未主动使用的应用程序的后台网络活动和作业来延长电池寿命。
App Standby生命周期
平台检测非活动应用程序并将其置于App Standby中,直到用户开始主动使用应用程序。
侦测 | App Standby期间 | 退出 |
---|---|---|
当设备未充电且用户未直接或间接地启动应用程序达特定时间量的时间以及特定量的屏幕开启时间时,平台侦测应用程序处于非活动状态。(当前台应用程序访问第二个应用程序中的服务时,会发生间接启动。) | 平台防止应用程序每天多次访问网络,从而推迟应用程序同步和其他作业。 | 在以下情况下,平台使应用程序从App Standby退出:1. 应用变得活跃。 2. 设备已插入并正在充电。 |
活动应用程序不受App Standby的影响。应用程序处于活动状态时:
- 当前处于前台的进程(作为活动或前台服务,或由其他活动或前台服务使用),例如通知侦听器,可访问性服务,动态壁纸等。
- 用户查看的通知,例如锁定屏幕或通知托盘。
- 由用户明确发布。
如果在一段时间内没有发生上述活动,则应用程序处于非活动状态。
测试App Standby
您可以使用以下adb 命令手动测试App Standby :
$ adb shell dumpsys battery unplug
$ adb shell am set-idle package-name true
$ adb shell am set-idle package-name false
$ adb shell am get-idle package-name