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一起使用,而不是單獨的使用一個隊列來進行管理。