android休眠唤醒

❶ Android 休眠唤醒频繁问题分析的一些工具

大家都知道目前的手机，平板等电子设备耗电都比较大，Android系统因为历史和开源等原因，一直对耗电支持的不是很好。特别现在很多apk完全不care耗电，动不动给你装上全家桶，还会相互间互相唤醒进程，简直就是流氓软件。从现有的应用来说，为了他们商业目的，有很多是类似要求长期后台运行的，或者定时运行的，这些服务对耗电影响都非常大。

虽然Android每次版本大更新，都对其进行了优化，加入了很多特性。比如在Android 5.0加入了JobScheler API机制（批处理）；在Android 6.0加入App Standby（应用待机），Doze休眠机制;并且在Android7.0谷歌对Doze休眠机制做了进一步的优化，只要手动在后台删掉应用卡片，关屏后该应用就会被很快深度休眠。

但是应用开发工程师由于各种原因没有使用新的特性，导致用户感觉设备耗电还是很大。所以国内很多手机厂家都有对android系统的耗电进行优化，从原理来说，目前这些厂家也是主要对两方面进行优化：

1.减少定时休眠唤醒频率，比如合并应用申请的定时唤醒闹钟来唤醒已经休眠的设备。

2.减少wake lock的频率和时间。只要系统中存在任一有效的wake_lock，系统就不能进入深度休眠，但可以进行设备的浅度休眠操作。wake_lock一般在关闭lcd、tp但系统仍然需要正常运行的情况下使用，比如听歌、传输很大的文件等。

可通过如下打印来确认唤醒源：

<4>[ 1321.989235] wakeup gpio0: 00000010

具体意思如下：

gpio0：表示是GPIO0

00000010：表示的是GPIO分组从高到低四个字节分别是：DCBA，每个字节的0-7bit就表示D7-D0  C7-C0  B7-B0  A7-A0.

从这里可以看出上面唤醒的GPIO是：GPIO0 PA4，对应的是RTC的中断脚。

通过mpsys alarm命令打印可以看到哪个应用唤醒次数比较多，和总共占用的时间：

这里的唤醒统计的是：应用申请 RTC_WAKEUP 或 ELAPSED_REALTIME_WAKEUP 的Alarm。不管系统是否在休眠，都会产生Alarm，所以这里的Alarm次数与第一章中说的kernel中统计的被RTC中断唤醒的次数是匹配不上的，前都会大于后者。

看下Android系统定义的休眠唤醒不同的类型。

这个信息可以通过Project Volta里的工具historian.py将其图形化显示。

先导出bugreport

将其转换成图形化结果（目前好像只有网络浏览器才能打开这个html）

简单说明如下：

1.横轴是时间

2. wifi_scan指的是wifi处于扫描

3. wifi_running指的是wifi打开状态

4. screen指的是屏亮的状态

5. plugged指的是插入外设

6. wake_lock指的是kernel中被锁住的状态

可通过screen与wake_lock来初步确认系统是否被唤醒，如果screen是关的，然后又有wake_lock，也表明系统被唤醒并被锁住一段时间。

把上层的唤醒和wifi唤醒都关了，测试了39个小时消耗30%电量

有以下几个问题：

1.唤醒次数的确少了，但是healthd每10分钟唤醒在图上体现不出来

2.有2次唤醒后，系统被锁住10多钟才休眠下去

查看Alarm状态，可以很明显看到上层没有再去wake up

但是驱动中还看到有被RTC唤醒，经过验证是healthd唤醒的，不插充电的时候10分钟，插充电的时候1分钟间隔。这个唤醒后就更新battery的信息，上层Baterry更新下，UI刷新下。

系统被锁住10几分钟，通过log分析在wifi断开的时候，gms刚好去连接服务器，通讯很久造成wake 比较久。从下面的信息可以判断，系统目前wake lock线程最多的是gms线程。

Wake lock 在Android的电源管理系统中扮演一个核心的角色，wakelock是一种锁的机制, 只要有task拿着这个锁, 系统就无法进入休眠, 可以被用户态进程和内核线程获得。这个锁可以是有超时的或者是没有超时的, 超时的锁会在时间过去以后自动解锁。如果没有锁了或者超时了, 内核就会启动标准linux的那套休眠机制机制来进入休眠。

提高电池续航，也就意味着减少系统和程序的电量消耗。为此 经过测试发现，每次唤醒设备，1-2秒的时候，都会消耗2分钟（个别应用更久）的待机电量，可见每次唤醒设备的时候，不仅仅是点亮了屏幕，系统也在后台处理很多事情。

电池消耗比较大，从系统的行为上分析，有两个地方影响最大

1.系统在被唤醒的期间，被一些应用wake lock比较久，造成很久时间无法再进入二级休眠。

2.系统频繁的被唤醒，系统被唤醒目前包含三个唤醒源

（1）.系统上层通过AlarmMananger的接口注册rtc唤醒，

（2）.wifi芯片自动唤醒，

（3）.电池healthd定频唤醒。

所以如果应用比较多的时候，应用在唤醒期间动作比较多，容易造成系统被wake lock，从而不会很快的进入二级休眠。

通过上述的分析来看，系统可以优化的地方有4个方面。

1).查看系统wake lock最多的线程，看能不能优化。

2).系统上层过滤的应用唤醒行为，从而降低唤醒频率。AlarmManager包含四种类型定时策略，AlarmManager.ELAPSED_REALTIME、AlarmManager.ELAPSED_REALTIME_WAKEUP、AlarmManager.RTC、AlarmManager.RTC_WAKEUP、AlarmManager.POWER_OFF_WAKEUP。

其中应用申请RTC_WAKEUP或ELAPSED_REALTIME_WAKEUP的Alarm在系统休眠的情况下会唤醒系统。通过建立白名单或者黑名单的方式过滤此种应用的唤醒行为

3）. 定时批处理一批操作，压缩硬件唤醒时间，就像心跳一样，让硬件充分休息，还有就是精确监测应用请求，智能安排请求执行时间，让资源利用最大化。

4).扩大healthd的定频唤醒间隔（适度不然造成电池电量不准）

最后改一张调整过的电池状态图：

❷ 怎样让android系统休眠啊，关屏后还一直唤醒着，很耗电

让android系统休眠，关屏后还一直唤醒着，很耗电的解决办法如下：

1. 系统运行的时候有很多软件后台运行着，可以卸载一些不常用的软件，来减低系统的负荷。

2. 可以将系统屏幕关闭时间减少，来减少屏幕开启时间过长，打开手机设置，点击显示，找到屏幕自动关闭选项，将时间设置到最低。

3. 

❸ Android-WakeLock(唤醒锁与CPU休眠/屏幕常亮)

参考：
https://blog.csdn.net/wh_19910525/article/details/8287202
http://landerlyoung.github.io/blog/2014/10/31/androidzhong-de-wakelockshi-yong/

: https://www.jianshu.com/p/2cfd179ef8dc
CSDN: https://blog.csdn.net/qq_32115439/article/details/80169222
GitHub博客: http://lioil.win/2018/05/02/Android-WakeLock.html
Coding博客: http://c.lioil.win/2018/05/02/Android-WakeLock.html

❹ 如何查找唤醒android系统

如果在休眠中系统被中断或者其他事件唤醒,接下来的代码就会开始执行,这个唤醒的顺序是和休眠的循序相反的,所以系统设备和总线会首先唤醒，使能系统中断,使能休眠时候停止掉的非启动CPU,以及调用suspend_ops->finish(),而且在suspend_devices_and_enter()函数中也会继续唤醒每个设备,使能虚拟终端,最后调用suspend_ops->end().

在返回到enter_state()函数中的,当suspend_devices_and_enter()返回以后,外设已经唤醒了,但是进程和任务都还是冻结状态,这里会调用suspend_finish()来解冻这些进程和任务,而且发出Notify来表示系统已经从suspend状态退出,唤醒终端.

到这里,所有的休眠和唤醒就已经完毕了,系统继续运行了.

Android系统Suspend和resume的函数流程
Android 休眠(suspend)介绍
在一个打过android补丁的内核中,state_store()函数会走另外一条路,会进入到request_suspend_state()中,这个文件在earlysuspend.c中.这些功能都是android系统加的,后面会对earlysuspend和lateresume进行介绍。

涉及到的文件:

linux_source/kernel/power/main.c

linux_source/kernel/power/earlysuspend.c

linux_source/kernel/power/wakelock.c

特性介绍

1）EarlySuspend

Early suspend是android引进的一种机制,这个机制作用在关闭显示的时候,一些和显示有关的设备,比如LCD背光,重力感应器,触摸屏,这些设备都会关掉，但是系统可能还是在运行状态(这时候还有wakelock)进行任务的处理，例如在扫描SD卡上的文件等.在嵌入式设备中,背光是一个很大的电源消耗，所以android会加入这样一种机制。

2）LateResume

Late Resume是和suspend配套的一种机制,是在内核唤醒完毕开始执行的，主要就是唤醒在EarlySuspend的时候休眠的设备.

当所有的唤醒已经结束以后,用户进程都已经开始运行了,唤醒通常会是以下的几种原因:

来电

如果是来电,那么Modem会通过发送命令给rild来让rild通知WindowManager有来电响应,这样就会远程调用PowerManagerService来写"on"到/sys/power/state来执行lateresume的设备,比如点亮屏幕等.

用户按键用户按键事件会送到WindowManager中,WindowManager会处理这些按键事件,按键分为几种情况,如果案件不是唤醒键(能够唤醒系统的按键)那么WindowManager会主动放弃wakeLock来使系统进入再次休眠,如果按键是唤醒键,那么WindowManger就会调用PowerManagerService中的接口来执行Late Resume.

Late Resume会依次唤醒前面调用了EarlySuspend的设备.

3）WakeLock

Wake Lock在Android的电源管理系统中扮演一个核心的角色.Wake Lock是一种锁的机制,只要有人拿着这个锁，系统就无法进入休眠,可以被用户态程序和内核获得。这个锁可以是有超时的或者是没有超时的,超时的锁会在时间过去以后自动解锁。如果没有锁了或者超时了,内核就会启动休眠的那套机制来进入休眠。

3）AndroidSuspend

当用户写入mem或者standby到/sys/power/state中的时候,state_store()会被调用,然后Android会在这里调用request_suspend_state()而标准的Linux会在这里进入enter_state()这个函数.如果请求的是休眠,那么early_suspend这个workqueue就会被调用,并且进入early_suspend状态。调用request_suspend_state()后在suspend_work_queue工作线程上面注册一个early_suspend_work工作者，

然后又通过staticDECLARE_WORK(early_suspend_work, early_suspend);注册一个工作任务early_suspend。所以系统最终会调用early_suspend函数。

注册加入suspend和resume流程
platform_device_register()-->platform_device_add()-->device_add()-->device_pm_add()-->，最终加入到了dpm_list的链表中，在其中的dpm_suspend和dpm_suspend中通过遍历这个链表来进行查看哪个device中包含suspend和resume项。

系统唤醒和休眠

Kernel层[针对AndroidLinux2.6.28内核]:

其主要代码在下列位置:

Drivers/base /main.c

kernel/power /main.c

kernel/power/wakelock.c

kernel/power/earlysuspend.c

其对Kernel提供的接口函数有

EXPORT_SYMBOL(wake_lock_init);//初始化Suspendlock,在使用前必须做初始化

EXPORT_SYMBOL(wake_lock);//申请lock,必须调用相应的unlock来释放它

static DEFINE_TIMER(expire_timer,expire_wake_locks, 0, 0);//定时时间到，加入到suspend队列中；

EXPORT_SYMBOL(wake_unlock);//释放lock

EXPORT_SYMBOL_GPL(device_power_up);//打开特殊的设备

EXPORT_SYMBOL_GPL(device_power_down);//关闭特殊设备

EXPORT_SYMBOL_GPL(device_resume);//重新存储设备的状态；

EXPORT_SYMBOL_GPL(device_suspend);:保存系统状态，并结束掉系统中的设备；

EXPORT_SYMBOL(register_early_suspend);//注册earlysuspend的驱动

EXPORT_SYMBOL(unregister_early_suspend);//取消已经注册的earlysuspend的驱动

Android的suspent执行流程
函数的流程如下所示：

应用程序通过对/sys/power/state的写入操作可以使系统进行休眠的状态，会调用/kernel/power/main.c中的state_store函数。pm_states包括：

PM_SUSPEND_ON，PM_SUSPEND_STANDBY，PM_SUSPEND_MEM满足的状态。

1）当状态位PM_SUSPEND_ON的状态的时候，request_suspend_state()；当满足休眠的状态的时候，调用request_suspend_state在suspend_work_queue工作线程上创建early_suspend_work队列，queue_work(suspend_work_queue,&early_suspend_work)。

2）然后通过DECLARE_WORK(early_suspend_work,early_suspend);在early_suspend_work工作队列中添加工作任务调用early_suspend，所以early_suspend函数会被调用。

3）early_suspend函数中通过

list_for_each_entry(pos,&early_suspend_handlers, link) {

if (pos->suspend != NULL)

pos->suspend(pos)；

在链表中找注册的suspend函数，这个suspend是early的。early_suspend后面调用wake_unlock函数。语句：wake_unlock(&main_wake_lock);

4）wake_unlock()中调用mod_timer启动expire_timer定时器，当定时时间到了，则执行expire_wake_locks函数，将suspend_work加入到suspend_work_queue队列中，分析到这里就可以知道了early_suspend_work和suspend_work这两个队列的先后顺序了（先执行early，定义一段时间后才执行suspend_work），然后会在suspend_work队列中加入suspend的工作任务，所以wakelock.c中的suspend函数会被调用。

5）suspend调用了pm_suspend，通过判断当前的状态，选择enter_state()，在enter_state中，经过了suspend_prepare，suspend_test和suspend_device_and_enter()，在suspend_device_and_enter中调用dpm_suspend_start()，然后调用dpm_suspend()。

6）dpm_suspend中利用while循环在dpm_list链表查找所有devic，然后调用device_suspend来保存状态和结束系统的设备。到了这里，我们就又可以看见在初始化的时候所看到的队列dpm_list。

dpm_list链表的添加是在device_pm_add中完成，请看上一节中。

Wake Lock
我们接下来看一看wakelock的机制是怎么运行和起作用的,主要关注wakelock.c文件就可以了。

wake lock有加锁和解锁两种状态,加锁的方式有两种,一种是永久的锁住,这样的锁除非显示的放开,是不会解锁的,所以这种锁的使用是非常小心的.第二种是超时锁,这种锁会锁定系统唤醒一段时间,如果这个时间过去了,这个锁会自动解除.

锁有两种类型:

WAKE_LOCK_SUSPEND这种锁会防止系统进入睡眠

WAKE_LOCK_IDLE这种锁不会影响系统的休眠,作用我不是很清楚.

在wakelock中,会有3个地方让系统直接开始suspend(),分别是:

1）在wake_unlock()中,如果发现解锁以后没有任何其他的wakelock了,就开始休眠

2）在定时器都到时间以后,定时器的回调函数会查看是否有其他的wakelock,如果没有,就在这里让系统进入睡眠.

3）在wake_lock()中,对一个wakelock加锁以后,会再次检查一下有没有锁,我想这里的检查是没有必要的,更好的方法是使加锁的这个操作原子化,而 不是繁冗的检查.而且这样的检查也有可能漏掉.

Android于标准Linux休眠的区别

pm_suspend()虽然会调用enter_state()来进入标准的Linux休眠流程，但是还是有一些区别:

当进入冻结进程的时候，android首先会检查有没有wakelock，如果没有,才会停止这些进程，因为在开始suspend和冻结进程期间有可能有人申请了wake lock,如果是这样,冻结进程会被中断.

在suspend_late()中,会最后检查一次有没有wakelock,这有可能是某种快速申请wakelock,并且快速释放这个锁的进程导致的,如果有这种情况,这里会返回错误,整个suspend就会全部放弃.如果pm_suspend()成功了,LOG的输出可以通过在kernelcmd里面增加"no_console_suspend"来看到suspend和resume过程中的log输出。

Android的电源管理主要是通过Wakelock来实现的，在最底层主要是通过如下队列来实现其管理：

LIST_HEAD(dpm_list);

系统正常开机后进入到AWAKE状态,，Backlight会从最亮慢慢调节到用户设定的亮度,系统screenoff timer(settings->sound & display-> Display settings ->Screen timeout)开始计时，在计时时间到之前，如果有任何的activity事件发生,如Touchclick, keyboard pressed等事件,则将Resetscreen off timer, 系统保持在AWAKE状态.如果有应用程序在这段时间内申请了Fullwake lock,那么系统也将保持在AWAKE状态,除非用户按下powerkey.在AWAKE状态下如果电池电量低或者是用AC供电screenoff timer时间到并且选中Keepscreen on while pluged in选项,backlight会被强制调节到DIM的状态。

如果Screenoff timer时间到并且没有Fullwake lock或者用户按了powerkey,那么系统状态将被切换到NOTIFICATION,并且调用所有已经注册的early_suspend_handlers函数,通常会把LCD和Backlight驱动注册成earlysuspend类型,如有需要也可以把别的驱动注册成earlysuspend,这样就会在第一阶段被关闭.接下来系统会判断是否有partialwake lock acquired, 如果有则等待其释放,在等待的过程中如果有useractivity事件发生,系统则马上回到AWAKE状态;如果没有partialwake lock acquired, 则系统会马上调用函数pm_suspend关闭其它相关的驱动,让CPU进入休眠状态。

系统在Sleep状态时如果检测到任何一个Wakeupsource,则CPU会从Sleep状态被唤醒,并且调用相关的驱动的resume函数,接下来马上调用前期注册的earlysuspend驱动的resume函数,最后系统状态回到AWAKE状态.这里有个问题就是所有注册过earlysuspend的函数在进Suspend的第一阶段被调用可以理解,但是在resume的时候,Linux会先调用所有驱动的resume函数,而此时再调用前期注册的earlysuspend驱动的resume函数有什么意义呢?个人觉得android的这个earlysuspend和lateresume函数应该结合Linux下面的suspend和resume一起使用,而不是单独的使用一个队列来进行管理。

❺ Android APP休眠状态下无法联网和播放音频解决方案

https://developer.android.google.cn/guide/topics/media/mediaplayer?hl=zh-cn

使用唤醒锁定

当设计在后台播放媒体内容的应用时，设备可能会在您的 Service 运行时进入休眠状态。由于 Android 系统尝试在设备处于休眠状态时节省电量，因此系统会尝试关闭手机上任何不必要的功能，包括 CPU 和 WLAN 硬件。不过，如果您的 Service 正在播放或流式传输音乐，则您需要防止系统干扰播放。

为了确保您的 Service 在这些情况下能继续运行，您必须使用“唤醒锁定”。唤醒锁定可以告诉系统：您的应用正在使用一些即使在手机处于闲置状态时也应该可用的功能。

注意 ：您应始终谨慎使用唤醒锁定，并只使其保留必要的时长，因为它们会显着缩短设备的电池续航时间。

为确保 CPU 在  MediaPlayer  播放时继续运行，请在初始化 时调用  setWakeMode()  方法。完成该操作后， MediaPlayer  会在播放时保持指定的锁定状态，并在暂停或停止播放时释放锁定：

    mediaPlayer = new MediaPlayer();// ... other initialization here ...

mediaPlayer.setWakeMode(getApplicationContext(), PowerManager.PARTIAL_WAKE_LOCK);

不过，此示例中获取的唤醒锁定只能保证 CPU 保持唤醒状态。如果您使用 WLAN 并通过网络流式传输媒体内容，则您可能也希望保持  WifiLock ，该锁定必须手动获取和释放。因此，当您开始使用远程网址准备  MediaPlayer  时，您应创建并获取 WLAN 锁定。例如：

    WifiLock wifiLock = ((WifiManager) getSystemService(Context.WIFI_SERVICE)).createWifiLock(WifiManager.WIFI_MODE_FULL, "mylock");

wifiLock.acquire();

当您暂停或停止媒体内容，或者当您不再需要网络时，应释放该锁定：

    wifiLock.release();

❻ android app被杀死 alarmmanager能不能唤醒

可以唤醒的，但是得需要注意设置进程属性。

在Android中，AlarmManager提供了不受休眠状态的系统定时功能，其一般使用方法如下。

1、创建一个BroadcastReceiver类的子类，接收定时器事件：

public class MyReceiver extends BroadcastReceiver {

......

}

2、在AndroidMenifest.xml中定义上述广播事件接收类的定义：

<receiver android:name=".MyReceiver">

</receiver>

3、在程序中在需要时设置定时器：

Intent intent = new Intent(context,MyReceiver.class);

PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);

AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);

alarmManager.set(AlarmManager.ELAPSED_REALTIME_WAKEUP , SystemClock.elapsedRealtime() + ms, pendingIntent);

经过ms毫秒之后，MyReceiver会被调用，从而实现定时触发。

❼ android 7.0低电耗Doze模式

如果用户设备未插接电源、处于静止状态一段时间且屏幕关闭，设备会进入低电耗模式。 在低电耗模式下，系统会尝试通过限制应用对网络和 CPU 密集型服务的访问来节省电量。 这还可以阻止应用访问网络并推迟其作业、同步和标准闹铃。

系统会定期退出低电耗模式一会儿，好让应用完成其已推迟的 Activity。在此维护时段内，系统会运行所有待定同步、作业和闹铃并允许应用访问网络。

而 Android 7.0 则通过在设备未插接电源且屏幕关闭状态下、但不一定要处于静止状态（例如用户外出时把手持式设备装在口袋里）时应用部分 CPU 和网络限制，进一步增强了低电耗模式。

7.0进入Doze模式分两个阶段: 对App行为的限制分为light idle(浅度doze)和deep idle(深度doze) .当设备处于非充电状态且屏幕已关闭一定时间后，设备会进入低电耗模式并应用第一部分限制(light idle)：关闭应用网络访问、推迟作业和同步。如果进入低电耗模式后设备处于静止状态达到一定时间，系统则会对 PowerManager.WakeLock、AlarmManager 闹铃、GPS 和 WLAN 扫描应用余下的低电耗模式限制(deep idle)。无论是应用部分还是全部低电耗模式限制，系统都会唤醒设备以提供简短的维护时间窗口，在此窗口期间，应用程序可以访问网络并执行任何被推迟的作业/同步。

在每个维护时段结束后，系统会再次进入低电耗模式，暂停网络访问并推迟作业、同步和闹铃。 随着时间的推移，系统安排维护时段的次数越来越少，这有助于在设备未连接至充电器的情况下长期处于不活动状态时降低电池消耗。

图中,横轴表示随着时间的推移,橙色表示设备处于唤醒运行状态,绿色表示低电耗(Doze)休眠状态;当设备处于on battery(利用电池供电,也就是未插接电源),screen off(关闭屏幕),stationary(静止状态,7.0以后非静止状态亦可)保持以上条件一段时间之后,设备就会进入Doze模式.

maintenance window (低电耗(Doze)模式提供了定期维护时段,可供应用使用网络并处理待定Activity),Doze模式下会定期的进入maintenance window,但进入的间隔越来越长

一旦用户通过移动设备、打开屏幕或连接到充电器唤醒设备，系统就会立即退出低电耗模式，并且所有应用都将返回到正常 Activity。

在低电耗模式下，您的应用会受到以下限制：

应用待机模式: 允许系统判定 应用在用户未主动使用它时,将应用置为空闲状态;通俗的说是指用户在一段时间内没有使用某个app,系统就会让这个app处于空闲状态,空闲状态会限制app访问网络,推迟app的作业和同步任务

当用户有一段时间未触摸应用,且除以下条件外,都将被标记为空闲状态

当用户将设备插入电源时，系统将从待机状态释放应用，从而让它们可以自由访问网络并执行任何待定作业和同步。 如果设备长时间处于空闲状态，系统将按每天大约一次的频率允许空闲应用访问网络。

低电耗模式

您可按以下步骤测试低电耗模式：

您可能需要多次运行第二个命令。不断地重复，直到设备变为空闲状态。

应用待机模式

要在应用待机模式下测试您的应用，请执行以下操作：

亲测MIUI 9.5执行 adb shell am set-inactive com.tencent.mobileqq true 结果始终为: Idle=false 而测试其他包名则没有异样,也就是小米针对QQ这种用户量大的即时通讯软件做了针对性处理

通过妥善管理网络连接、闹铃、作业和同步并使用 GCM 高优先级消息，几乎所有应用都应该能够支持低电耗模式。对于一小部分用例，这可能还不够。 对于此类用例，系统为部分免除低电耗模式和应用待机模式优化的应用提供了一份可配置的白名单。

在低电耗模式和应用待机模式期间，加入白名单的应用可以使用网络并保留部分 wake locks。 不过，正如其他应用一样，其他限制仍然适用于加入白名单的应用。 例如，加入白名单的应用的作业和同步将推迟（在 API 级别 23 及更低级别中），并且其常规 AlarmManager 闹铃不会触发。通过调用 ()，应用可以检查自身当前是否位于豁免白名单中。

用户可以在 Settings > Battery > Battery Optimization 中手动配置该白名单。或者，系统会为应用提供请求用户将应用加入白名单的方式。

如何将非系统app预置到Doze的白名单中

在请求用户将应用添加到白名单之前，请确保应用符合加入白名单的可接受用例。

Doze模式的实现主要在/frameworks/base/services/core/java/com/android/server/DeviceIdleController.java

以上主要内容参考自Google官方文档 .

❽ android休眠唤醒后出现竖条纹

系统bug、屏幕故障。
1、系统bug。android休眠唤醒后出现竖条纹可能是系统出现了bug，可以试试更新系统或重置。
2、屏幕故障。android休眠唤醒后出现竖条纹可能是屏幕出现故障，可以去官方店铺找工程师检查。

❾ android 如何让手机进入休眠状态，又如何唤

1.WakeLock主要代码如下：

PowerManager pm = (PowerManager)getSystemService(Context.POWER_SERVICE);
wakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, this.getClass().getName());//持有唤醒锁
wakeLock.setReferenceCounted(false);
wakeLock.acquire(30*1000);//30s亮屏
wakeLock.release();//释放锁，灭屏

2.FLAG_KEEP_SCREEN_ON代码如下
可使用 FLAG_KEEP_SCREEN_ON 替换WakeLock的方式.
this.getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);//亮屏
this.getWindow().clearFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);//灭屏

❿ android gsensor 休眠震动唤醒功能如何实现

一、唤醒源

设备休眠后，通过触发唤醒源使设备恢复正常工作模式。设备唤醒源有多种，对于Android设备常见的就有PowerKey、来电唤醒、Alarm唤醒等。

唤醒源的实现处于内核空间，本文重点讨论下PowerKey作为唤醒源的具体实现。

二、PowerKey唤醒源

PowerKey唤醒设备的原理，本质其实就是中断。

PowerKey连接到CPU的一个输入(Input)引脚(Pin)上，该Pin运行在中断模式上。一旦PowerKey按下，引发Pin中断；而该中断具有唤醒CPU的功能，于是设备得以唤醒。

三、PowerKey对应的Pin
Configuration

和PowerKey相连的Pin的具体配置位于板级dts文件中，比如如下配置：

arch/arm/boot/dts/xxxxx.dts
power-key {
/** 是CPU的哪个Pin */
gpios = <&gpio0 GPIO_A5 GPIO_ACTIVE_LOW>;
/** Key code */
linux,code = <116>;
/** 起个名字 */
label = "power";
/** 该Pin具有wakeup的功能 */
gpio-key,wakeup;
};

着重说下linux,code =
<116>，116怎么来的？

对于键盘，每一个按键都有唯一的编码，在Linux中，编码值位于：

input.h (kernelincludeuapilinux)
/*
* Keys and buttons
*/
#define KEY_RESERVED 0
#define KEY_ESC 1
#define KEY_BACKSPACE 14
#define KEY_TAB 15
#define KEY_POWER 116 /* SC System Power Down */

可知,PowerKey的编码也在该文件中，且编码值为116；一旦按下PowerKey，该值作为键值传到input_event结构体的code成员变量中：

input.h (kernelincludeuapilinux)
/*
* The event structure itself
*/

struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32 value;
};

之后我们会写个Linux应用程序读取code值。