A. android os进程长时间处于“保持唤醒状态”，什么原因
我也在找这个问题解决办法，但是很遗憾 还没有！下边有一篇文章写的比较清楚：只有飞行模式有办法解决！而且还有个问题：今天半天时间看了下流量，这个进程居然一下耗费了13M多的流量，真的不知道是什么情况！！
------------------------------以下转自网络--------------------------------
Android OS 进程耗电多的问题是否有解决办法？
简单的说就是Android手机（根据查阅，各种型号Android手机均有可能出现此情况）变得异常费电，查看电量信息，android os进程耗电最大，待机时占用到60%+的电量。
网友总结有以下特点：
1.关掉背景同步和各种谷歌服务，无效
2.用钛同步冻结各种有可能在待机时工作的服务和软件（包括各种谷歌服务），无效
3.能挪到SD卡的程序统统挪到SD卡，无效
4.关掉WLAN，GPS，数据传输，数据漫游，无效
5.打开USB调试，无效
6.充满电以后重启一次，无效
7.用CPU大师设置屏幕关闭时自动降频至384MHZ或者192MHZ，无效
8.用PLUS工具箱提高超频电压，因为不能设置1.2GHZ以上的值，尝试设置成56-800一类的若干组高电压数值，无效
9.飞行模式，有效
10.考虑到9有效，综合考虑4，因此在4的基础上，手动指定运营商为联通，并设置为2G网络，无效
11.用PLUS工具箱切换了O2，港版，新欧版等几种基带配置，无效
12.刷ROM，无效
13.用autostart关掉各种自启动关联，无效
网友分析得出的原因：
“不
正常耗电是因为android os在待机时不断唤醒设备造成的。至于具体是什么子进程在不断让android os工作，可以通过wake
lock的使用情况来确定。所以安装模拟终端，用take
wakelock的方式得到/proc/wakelock文件，然后进行查看，结果数次查看的结果都是mmc_delayed_work进程非常频繁的使
用wake lock。（1小时5000次以上）然后重启在充电和飞行模式下做同样的测试，结果mmc_delayed_work进程使用wake
lock的次数几乎可以忽略（只有几次），据此基本可以确定，是mmc_delayed_work在不插电的情况下工作不正常，不断请求CPU资源，导致了android os一直唤醒待机时的设备，造成异常耗电。此问题基本上和谷歌服务什么的没任何关系。”
那么，这种情况应该如何解决呢？这样的好点基本导致手机无法正常使用了，但纯待机都到不了12小时，希望有高人给用户些建议
B. 你好，我想问一下，手机开机一段时间后显示异常重启是怎么回事
第一请您在再次提问中详细描述手机的各种参数及使用情况。一般电子设备的问题有很多原因：有本身硬件设计及生产缺陷，有频繁使用中及在恶劣环境下使用造成设备硬件损坏，也有软件bug造成手机系统不稳定等。
以下是手机异常重启常见原因，其您参考：
硬件：
1.主板在高温下或长期使用后各电子元件发生松动或线路老化造成手机卡屏，运行慢等问题。这种情况下只能换手机或凑合用了
2.存储芯片(ROM)老化或损坏,就像电脑硬盘损坏后电脑由于频繁读取硬盘数据而造成系统异常。处理方法与上相同
3.随机存储单元（RAM，简称内存）老化或损坏，造成内存中的数据异常丢失而使系统被迫重启重新向内存存入数据。处理方法与上相同
软件
手机系统厂商在系统文件及内存管理及沉积上做的不太到位。如现在热议的安卓和苹果IOS系统在长期使用上不同：安卓手机会越用越慢（系统文件沉积使手机运行速度及系统效率受影响） 苹果IOS虽在这上做的相当不错但由此带来的系统缓存空间过多而使存储低的8g苹果手机使用用户头疼不已。如现在流行的解决方式：刷机或使用软件清理系统缓存文件
系统安装了占用内存过多的应用或应用本身的内存管理缺陷造成的内存溢出现象（也就是内存被非系统应用占满而使系统无法向内存储数据）。一般这种情况在大型游戏在系统后台中运行时发生。如三星的内存管理：在内存无法读取情况下被迫重启并使用低内存杀手（一种内存强制清除程序）清理不常用的应用程序
注：如不清楚内部存储及运存，请自己网络一下
打字这么多，请给我好评喔！！！
C. 如何解决安卓手机频繁唤醒的问题
这个问题的话，你可以在设置里面进行解决手机频繁唤醒对于一个正常人来说是非常令人头痛的事情，然后的话你设定好每个天只能唤醒一次就可以了，在那个时间段他才会自动打开，在其他的时间段是不会允许的。
D. “Android操作系统”一直唤醒，该怎么解决
1、在更换SD卡 得到解决 2、只要用USB存储模式连接电脑 就会引起耗电 只有重启才能解决 3、因为替换了系统的状态栏 引起耗电 替换回原版 得到解决 4、因为谷歌服务框架引起 替换别的版本谷歌服务框架 得到解决 5、 因为装了某个软件引起 卸载后 得到解决 6、 刷ROM 得到解决 7、刷机换了内核 得到解决 8.关闭wifi
E. 使用手机时，有时会弹出“系统异常 方法调用异常”的信息，后面是一串字母和数字。不知是什么问题。
解决方法：
打开手机设定；
点击开发人员选项；
点击指针位置，把对应的勾去掉。
开发人员选项的作用：
提交错误报告：将本机上安卓系统的出错日志以及硬件设备信息发送给谷歌。建议：当然不想泄露自己隐私的话，不要使用。
桌面密码备份：设置或更新桌面完整备份的密码。
保持唤醒状态不锁定屏幕：充电时屏幕不会休眠。建议：关闭
启用蓝牙HCI信息收集日志：蓝牙互传文件会被记录日志。
进程统计信息：安卓4.4新增给力功能，每个进程的运行时长百分比，ram使用率，相关后台服务统计情况一目了然。
USB调试：允许外部程序尤其是PC端程序通过adb命令管理手机。安卓系统最有趣也是最吸引人的开放性就是由它控制的。
撤销USB调试授权：撤销所有已连接过的电脑调试授权，下次连接又要重新安装驱动。
F. 安卓系统不同的软件总是被唤醒是怎么回事
安卓系统不同的软件总是被唤醒是因为软件被允许在后台运行，有消息就自动唤醒。
解决方法：设置-自启管理里关闭软件自动后台启动。
或者在安装软件完成时禁止软件后台运行。
G. 如何解决安卓手机频繁唤醒的问题
若手机/平板电脑锁屏状态下屏幕自动亮起，建议：
1.部分手机/平板电脑支持轻松开启屏幕功能：设置-辅助功能-敏捷度和互动-轻松开启屏幕-关闭。
2.若非以上情况，请解锁屏幕后查看是否有新信息通知。若有，可能是由于将“在锁定屏幕上显示通知”设置为“不显示通知”导致。
3.若无新信息提示，请检查是否使用第三方主题软件，建议更换自带主题尝试。
4.若无效，请将手机/平板电脑更新至最新版本。注：升级前请备份设备中数据。
5.若已是最新版本，请备份手机/平板电脑中数据然后恢复出厂设置尝试。
若问题依然存在，建议您携带机器、购机发票、包修卡至当地的三星售后服务中心进行检测。
H. 在Android系统上启动知乎app时会唤醒微信是什么原因
本回答信息来自针对微信Android客户端以及知乎Android客户端的分析。
我手机上装了一键清理的软件，平时从来不让微信在后台运行，但是每当打开知乎，不出三秒，微信消息就来了，消息并不固定，只是感觉微信被打开了，我在想知乎是不是跟微信合作，后台打开微信，然后以此来赚钱的呢？
首先针对题主的疑问，准备的回答：不是
实际的情况是，知乎调用微信sdk中分享的相关接口，微信sdk的相关接口里面，给微信发送了一个广播，微信app就被唤醒了，这不是知乎的主观行为，而是微信的（而且结合实际的分析来看，这个应该也算是正常的功能）。
以下是详细分析：
1 首先说一下app的被唤醒（自启动）机制。
app自启动，基本上都是依靠Android的广播来实现的，而且是静态注册的广播（在AndroidManifest.xml文件中进行配置的广播），发送广播的方法在一般情况下是sendBroadcast。
2 按照惯例，反编译一下微信apk，然后搜索一下它能够由哪些静态广播进行唤醒，同时抓取广播相关的log。
结合微信的AndroidManifest.xml文件以及抓取的log，可以知道相关的BroadcastReceiver是EntryReceiver，相关的action 为
com.tencent.mm.plugin.openapi.Intent.ACTION_HANDLE_APP_REGISTER
com.tencent.mm.plugin.openapi.Intent.ACTION_HANDLE_APP_UNREGISTER
从其名称上看，是和注册/注销相关,具体接收到广播之后做了哪些处理，这些就不赘述了。
I/ActivityManager( 1107): Start proc com.tencent.mm for broadcast com.tencent.mm/.plugin.base.stub.WXEntryActivity$EntryReceiver: pid=28779 uid=10131 gids={50131, 3003, 1028, 1015, 3002, 3001}
<receiver android:name="com.tencent.mm.plugin.base.stub.WXEntryActivity$EntryReceiver">
<intent-filter>
<action android:name="com.tencent.mm.plugin.openapi.Intent.ACTION_HANDLE_APP_REGISTER"/>
<action android:name="com.tencent.mm.plugin.openapi.Intent.ACTION_HANDLE_APP_UNREGISTER"/>
</intent-filter>
3 接下来分析知乎的代码
搜索一下知乎反编译之后的smali文件(sendBroadcast),其中只有一条是和微信相关的
hu_2.0.3_176/smali/com/tencent/mm/sdk/openapi/j.smali: invoke-virtual {v0, v4, v1}, Landroid/content/Context;->sendBroadcast(Landroid/content/Intent;Ljava/lang/String;)V
再看一下反编译的java文件，能够比较清楚的看到，就是利用com.tencent.mm.plugin.openapi.Intent.ACTION_HANDLE_APP_REGISTER
这个action来进行注册，检查一些必要的信息。
根据这些信息，结合微信和知乎反编译之后的文件，已经可以完整的分析具体发生了哪些事情了。
com.tencent.mm.sdk.openapi.j
public final boolean a(String paramString)
{
if (!b("com.tencent.mm"))
{
com.tencent.mm.sdk.platformtools.a.a("MicroMsg.SDK.WXApiImplV10", "register app failed for wechat app signature check failed");
return false;
}
this.b = paramString;
com.tencent.mm.sdk.platformtools.a.b("MicroMsg.SDK.WXApiImplV10", "register app " + this.a.getPackageName());
Context localContext = this.a;
String str1 = "weixin://registerapp?appid=" + this.b;
String str2 = "com.tencent.mm" + ".permission.MM_MESSAGE";
Intent localIntent = new Intent("com.tencent.mm.plugin.openapi.Intent.ACTION_HANDLE_APP_REGISTER");
String str3 = localContext.getPackageName();
localIntent.putExtra("_mmessage_sdkVersion", 553910273);
localIntent.putExtra("_mmessage_appPackage", str3);
localIntent.putExtra("_mmessage_content", str1);
localIntent.putExtra("_mmessage_checksum", b.a(str1, str3));
localContext.sendBroadcast(localIntent, str2);
com.tencent.mm.sdk.platformtools.a.b("MicroMsg.SDK.MMessage", "send mm message, intent=" + localIntent + ", perm=" + str2);
return true;
}
4 最后，因为偷懒，所以我只是大概的静态分析了相关代码，没发现知乎和微信做了什么丧失的事情，然后大概加了段log check了一下，从中也可以看出的确是和分享有关，至于使用时机及频率是否合适，这个和问题没什么关系，不做讨论。
D/hillwind( 5766): java.lang.Throwable
D/hillwind( 5766): at com.hillwind.android.util.RLog.printStackTrace(RLog.java:11)
D/hillwind( 5766): at com.tencent.mm.sdk.openapi.j.a(Unknown Source)
D/hillwind( 5766): at com.hu.android.util.af.b(WeChatHelper.java:43)
D/hillwind( 5766): at com.hu.android.widget.a.b(ActivityChooserModel.java:721)
D/hillwind( 5766): at com.hu.android.widget.ShareActionProvider.setShareIntent(ShareActionProvider.java:98)
D/hillwind( 5766): at com.hu.android.ui.fragment.bx.a(QuestionViewerFragment.java:221)
D/hillwind( 5766): at android.support.v4.app.j.a(FragmentManager.java:1973)
D/hillwind( 5766): at android.support.v4.app.g.onCreatePanelMenu(FragmentActivity.java:226)
D/hillwind( 5766): at android.support.v7.a.b.a(ActionBarActivity.java:233)
D/hillwind( 5766): at android.support.v7.a.g.a(ActionBarActivityDelegateICS.java:146)
D/hillwind( 5766): at android.support.v7.a.b.onCreatePanelMenu(ActionBarActivity.java:200)
D/hillwind( 5766): at android.support.v7.a.g$a.onCreatePanelMenu(ActionBarActivityDelegateICS.java:293)
D/hillwind( 5766): at com.android.internal.policy.impl.PhoneWindow.preparePanel(PhoneWindow.java:472)
D/hillwind( 5766): at com.android.internal.policy.impl.PhoneWindow.doInvalidatePanelMenu(PhoneWindow.java:878)
D/hillwind( 5766): at com.android.internal.policy.impl.PhoneWindow$1.run(PhoneWindow.java:257)
D/hillwind( 5766): at android.os.Handler.handleCallback(Handler.java:733)
D/hillwind( 5766): at android.os.Handler.dispatchMessage(Handler.java:95)
D/hillwind( 5766): at android.os.Looper.loop(Looper.java:136)
D/hillwind( 5766): at android.app.ActivityThread.main(ActivityThread.java:5140)
D/hillwind( 5766): at java.lang.reflect.Method.invokeNative(Native Method)
D/hillwind( 5766): at java.lang.reflect.Method.invoke(Method.java:515)
D/hillwind( 5766): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:786)
D/hillwind( 5766): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:602)
D/hillwind( 5766): at dalvik.system.NativeStart.main(Native Method)
I. 晚上异常耗电，显示一直在唤醒，如何查看是哪个app
我用过的办法比较笨，但很靠谱。
就是逐个杀进程，杀到谁手机正常了，就是谁了。
杀进程的方法很多，比较老土的是进设置-应用那里，找到某应用“强行停止”。
手机自带的“管家”“卫士”之类如果有应用自启管理最好，除了必要的都不能自启，而且不能“关联启动”。现在一些APP一但启动，就耍流氓呼朋唤友把它的“战略合作伙伴”都给启动了，限制自启都没用，手机不堪重负！
也可以装个什么清理大师之类，全面整治。
J. 如何查找唤醒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一起使用,而不是单独的使用一个队列来进行管理。