Android应用电源管理

原文: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
  • 检测jobscheduleralarm 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
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,163评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,301评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,089评论 0 352
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,093评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,110评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,079评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,005评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,840评论 0 273
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,278评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,497评论 2 332
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,667评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,394评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,980评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,628评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,796评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,649评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,548评论 2 352

推荐阅读更多精彩内容