android廣播喚醒

㈠ android系統後台喚醒怎麼關閉

Android 系統支持應用程序及服務在待機前保存程序運行狀態，如待機前關閉文件讀寫、usb 操作、暫停音樂播放；也支持喚醒後的程序狀態恢復，如恢復打開文件進行讀寫操作，恢復 usb 操作、恢復音樂播放等。這些狀態的保存和恢復功能可以保證系統在待機喚醒後能正常工作。
主要提供兩種方式：
1、待機廣播消息和喚醒廣播消息。
2、Wakelock 鎖機制。

分為兩個部分說明一下：
1、android 系統待機處理機制
待機廣播消息和喚醒廣播消息
系統在 PowerManagerService 類中注冊了 2 個廣播分別用於待機前和喚醒後發送。
void initInThread(){
//喚醒後：
mScreenOnIntent=newIntent(Intent.ACTION_SCREEN_ON);//喚醒後發送
mScreenOnIntent.addFlags(Intent.FLAG_RECEIVER_REGISTERED_ONLY);
//待機前：
mScreenOffIntent=newIntent(Intent.ACTION_SCREEN_OFF);//待機時發送
mScreenOffIntent.addFlags(Intent.FLAG_RECEIVER_REGISTERED_ONLY);
}
這里順帶說明一下廣播接收的優先順序問題：
接收者按照在 Manifest.xml 文件中設置的接收順序依次接收Intent，順序執行的，接收的優先順序可以在系統配置文件中設置：
聲明在intent-filter元素的android:priority 屬性中，數值越大優先順序別越高，其取值范圍為-1000到1000。當然也可以在調用IntentFilter對象的setPriority()方法進行設置
Wakelock 鎖機制：
應用程序可以通過申請 wakelock 鎖的機制來對系統是否待機作出投票，當有任何一個應用申請了 wakelock 鎖，待機時沒有釋放掉，系統是不會進入待機的，直到所有應用的 wakelock 鎖都釋放掉了，才會進入待機。

㈡ Android 使用廣播系統解決app開機自啟動問題

關注 【網羅開發】微信公眾號，回復【160】便可領取。
網羅天下方法，方便你我開發 ，更多Android技術干貨等待領取，所有文檔會持續更新，歡迎關注一起成長！

總結一下使用ACTION_BOOT_COMPLETED的廣播，解決app開機自啟動的問題
1.首先在你的工程上建一個廣播接受的類，繼承BroadcastReceiver：

2.然後要在AndroidManifest.xml中加入許可權和配置相關信息：

3.在application標簽中，配置以下相關信息：

補充說明：
1.查看系統中是否安裝了類似360管家的軟體，為了加快開機速度，默認是關閉掉開機廣播的，只需要在設置中打開即可。
2.如果監聽不到廣播，可以嘗試同時監聽廣播和sd卡。
3.同時監聽廣播和sd卡，在application標簽中，配置以下相關信息：

㈢ Android後台進程保活方案

思想： 使用 Linux 中的 fork 機制創建 Native 進程，在 Native 進程中監控主進程的存活，當主進程掛掉後，在 Native 進程中立即對主進程進行拉活。

原理： 在 Android 中所有進程和系統組件的生命周期受 ActivityManagerService 的統一管理。Android5.0以下通過 Linux 的 fork 機制創建的進程為純 Linux 進程，其生命周期不受 Android 的管理。

該方案主要適用於 Android5.0 以下版本手機。

該方案不受 forceclose 影響，被強制停止的應用依然可以被拉活，在 Android5.0 以下版本拉活效果非常好。
詳情

對於 Android5.0 以上手機，系統雖然會將native進程內的所有進程都殺死，這里其實就是系統「依次」殺死進程時間與拉活邏輯執行時間賽跑的問題，如果可以跑的比系統邏輯快，依然可以有效拉起。在 某些 Android 5.0 以上機型有效。
詳情

https://github.com/Marswin/MarsDaemon

作者5.0以下系統用一個java進程和一個fork出來的純native進程雙管道互鎖監聽對方的狀態，無論哪個被殺後都拉起第三個進程，第三個進程來拉活常駐進程，實現拉活。
5.0以上同一進程組的進程會被同時殺死，所以5.0以上使用雙java進程在native層互鎖文件實現監聽，但任務管理器會在短時間內殺死所有進程，只能用反射提前初始化pacel，在進程被殺的時候和系統搶那幾十毫秒的時間發送一個拉活的廣播。用4個文件來讓兩個進程實現互鎖來做監聽，但實際效果很一般，測試了幾個5.0以上的國產機型都不行，效果是根本監聽不到進程被殺，目測原因是當任務管理器查殺進程的時候將所有的進程都掛起了，隨後全部殺掉，並在一段時間內禁止進程啟動。

PersistedJobService.java

BootReceiver.java靜態注冊BroadcastReceiver

注冊，開機，網路切換、拍照、拍視頻時候，利用系統產生的廣播也能喚醒app，不過Android N已經將這三種廣播取消了

常用的拉活許可權

BackgroundService.java
WakeLock

作為前台應用運行，提高應用存活幾率

service被關掉後自動啟動

START_STICKY
如果系統在onStartCommand返回後被銷毀，系統將會重新創建服務並依次調用onCreate和onStartCommand（注意：根據測試Android2.3.3以下版本只會調用onCreate根本不會調用onStartCommand，Android4.0可以辦到），這種相當於服務又重新啟動恢復到之前的狀態了）。

START_NOT_STICKY
如果系統在onStartCommand返回後被銷毀，如果返回該值，則在執行完onStartCommand方法後如果Service被殺掉系統將不會重啟該服務。

START_REDELIVER_INTENT
START_STICKY的兼容版本，不同的是其不保證服務被殺後一定能重啟。

service注冊，許可權設置為高優先順序

KeepAliveService.java
注冊，在新的獨立進程內啟動，適用5.0以下的原生系統，5.0以上同樣會被殺死

他的局限性在於：
第一，用戶會在系統設置的賬戶列表裡面看到一個不認識的賬戶；
第二，同步的事件間隔是有限制的，最短1分鍾，見源碼，如果小雨60秒，置為60秒。而且各種國產機怎麼改的源碼我們未可知，是不是都能用仍然未可知；
第三，很致命，某些手機比如note3需要手動設置賬戶，你如何騙你的用戶給你手動設置賬戶完了之後不卸載你；
第四，也很致命，必須聯網！google提供這個組件是讓你同步賬戶信息，不聯網你同步個鬼，我們要保活，可以不聯網不做事，但是不能不聯網就死

集成三方推送平台sdk，友盟極光等

㈣ Android保活——藍牙喚醒（主動kill掉也可喚醒）

項目需要後台保活，但無論怎麼保活，只要用戶主動kill掉，app依然是活不了。

發現了藍牙喚醒這個方式，用戶主動kill掉也可行。

Android 8.0開始提供了 startscan的方法，

public void startScan(ScanCallback callback)

public void startScan(List<ScanFilter> filters,ScanSettings settings,ScanCallback callback)

public int startScan(List<ScanFilter> filters,ScanSettings settings,PendingIntent callbackIntent)

第一個沒有過濾條件，鎖屏就停止掃描

第二個可以加過濾條件，鎖屏不影響掃描 

第三個的掃描結果由PendingIntent發送，即使app沒有在運行，系統也可以掃描後喚醒app，這就是我們要的方法了。

PendingIntent是對Intent的封裝，是滿足某些條件或觸發某些事件後才執行指定的行為，主要用於鬧鍾、通知、桌面部件。Android的四大組件之間通信用Intent，跨進程通信用PendingIntent。

Android 8.0 引進了Context.startForegroundService()，在系統創建服務後，應用需要在ANR發生前調用startForeground(int ,android.app.Notification)，如果未及時調用該方法，系統將報ANR錯誤 。系統給前台服務的ANR時間是20秒。

用startScan藍牙喚醒的原理是：app向系統訂閱了掃描結果（預先加了過濾條件），當藍牙連接斷開的時候，設備就會發廣播，這時系統就可以掃描到對應的廣播，喚醒對應的service，這時想做什麼操作就根據你的項目需要了。至於系統會為你掃描多久，這個還沒測試。

（1）setScanMode有四個參數可以選 ：

SCAN_MODE_BALANCED：在平衡電源模式下執行藍牙LE掃描。返回掃描結果的速度能夠很好地權衡掃描頻率和功耗。

SCAN_MODE_LOW_LATENCY：掃描使用最高占空比。建議只在應用程序在前台運行時使用此模式。

SCAN_MODE_LOW_POWER：在低功耗模式下執行藍牙LE掃描。這是默認的掃描模式，因為它消耗的能量最少。如果掃描應用程序不在前台，則強制執行此模式。

SCAN_MODE_OPPORTUNISTIC：一種特殊的藍牙LE掃描模式。使用這種掃描模式的應用程序將被動地偵聽其他掃描結果，而不啟動BLE掃描本身

（2）settingBuilder.setMatchMode有兩個參數可以選：

MATCH_MODE_AGGRESSIVE：  信號弱也會報告 

MATCH_MODE_STICKY：  信號比較強和掃描到的次數比較多才會報告

（3)settingBuilder.setCallbackType也有其他參數可選，但適用的就一個

  (4)  ScanFilter  的過濾方法有幾個,如下圖，打勾的是測試了可行的，但只有第一個DeviceAddress有唯一性  

㈤ android系統睡眠狀態如何喚醒線程和廣播

不能！
（不能手動喚醒，因為肯定需要點亮屏幕（手動點亮屏幕），所以並不是真睡眠狀態）。
只能提前設置，比如鬧鍾，具體到「廣播」即收音機，那麼只建議使用第三方程序，如「蜻蜓FM」，就像鬧鍾可以定時自動開啟。

如果是自己造，相當於重新編個程序出來，需要掌握大量專業性的東西，得不償失

㈥ Android本地廣播的使用

為了解決廣播的安全性問題，Android引入了本地廣播機制，使用該機制發出的廣播只能在應用程序的內部進行傳遞，並且廣播接收器也只能接收來自本應用程序發出的廣播。

本地廣播是無法通過靜態注冊的方式來接收的。我們知道靜態注冊主要是為了在程序未啟動的情況下能接收廣播，而當我們發送本地廣播的時候，程序肯定是已經啟動的了，所以我們需要動態注冊方式創建接收器。
在這里我們創建一個繼承於BroadcastReceiver的類LocalReceiver。onReceive()處理你接收到的廣播內容，在這里我用Toast來創建一個提示接收到消息的彈窗

在activity_main.xml文件創建一個用於發送廣播的按鈕

首先通過本地廣播管理器LocalBroadcastManager的getInstance()方法獲取一個實例，並分別創建過濾器IntentFilter和自定義接收器LocalReceiver的實例。給IntentFilter的實例添加一個action：localbroadcast（接收的廣播的名稱），然後調用LocalBroadcastManager的registerReceiver()方法進行注冊，並將LocalReceiver的實例和IntentFilter的實例都傳進去。這樣本地監聽器就創建完成了。
調用LocalBroadcastManager的sendBroadcast()發送本地廣播。運行程序，點擊Send Button按鈕，我們可以看到彈窗顯示「This is in LocalReceiver」，說明本地廣播發送和接收成功了。

當然，我們最後一定不要忘了取消注冊。我們可以通過調用unregisterReceiver()方法來實現。至此，Android的標准廣播發送就完成了。

1.發送的廣播只能在本程序內傳遞，不必擔心數據泄露
2.其它程序廣播無法發送到本程序的內部，不必擔心安全漏洞隱患
3.本地廣播比系統全局廣播更加高效

㈦ Android怎樣通過廣播機制喚醒後台服務

[mw_shl_code=java,false] <receiver
android:name="com.test.DataChangeReceiver" >

<intent-filter>
<action
android:name="android.intent.action.DATE_CHANGED" />

</intent-filter>

</receiver>[/mw_shl_code]

這個是一個接收日期改變後的廣播的例子；

對應的 java文件
就一個receive

[mw_shl_code=java,true]public class DataChangeReceiver extends
BaseReceiver {

@Override
public void onReceive(Context
context, Intent intent) {}
}[/mw_shl_code]