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值。