什麼時候會造成STOPPED狀態：

重未啟動過的應用，原生的系統中，當應用初次啟動後就會被標識為非STOPPED狀態，而且再也沒有機會被打回原形除非重新安裝應用；但是一些定製系統，在清理應用時加入了將應用重置為STOPPED的邏輯。

與系統Service捆綁

Android系統提供給我們一系列的Service，注意這裡我們所指的系統Service並非“SystemService”提供的那些玩意，而是類似於系統廣播的便於我們使用的Service，常見常用的就是IntentService，當然還有其它更多更不常用的系統Service，那麼為什麼愛哥要在這裡提到這玩意呢？因為某些系統Service一旦繫結就像擁有開了掛一樣的許可權，這在大部分機型包括某些深度定製系統上簡直就像BUG般存在，以最BUG的NotificationListenerService為例，大家可能很少會用到這玩意，這玩意是用來讀取通知的，也就是說只要是通知不管你誰發的，NotificationListenerService都可以檢測到，使用它也很簡單，和IntentService一樣定義一個類繼承一下即可：

package com.aigestudio.daemon.core;

import android.service.notification.NotificationListenerService;
import android.service.notification.StatusBarNotification;

/**
 * @author AigeStudio
 * @since 2016-05-05
 */
public class DService extends NotificationListenerService {
    @Override
    public void onNotificationPosted
 
(StatusBarNotification sbn) {
    }

    @Override
    public void onNotificationRemoved(StatusBarNotification sbn) {
    }
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18

裡面什麼邏輯都不用實現，是的你沒聽錯，什麼邏輯都不需要，然後在AndroidManifest中宣告許可權：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package
 
="com.aigestudio.daemon">

    <application>
        <service
            android:name=".core.DService"
            android:permission="android.permission.BIND_NOTIFICATION_LISTENER_SERVICE"
            android:process=":service">
            <intent-filter>
                <action android:name="android.service.notification.NotificationListenerService" />
            </intent-filter>
        </service>
    </application>
</manifest>

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14

這裡為了區別主程序，我將該Service置於一個單獨的程序中，然後啟動應用，注意，這裡我們的應用什麼邏輯都沒有，剔除掉上面所做的所有有關程序保護的邏輯，執行之後你發現看不到你NotificationListenerService所在的程序：

AigeStudio:Android AigeStudio$ adb shell
root@vbox86p:/ # ps|grep aigestudio
u0_a61    9513  339   1002012 30452 ffffffff f74aa3b5 S com.aigestudio.daemon

• 1
• 2
• 3

• 1
• 2
• 3

先別急，NotificationListenerService是個特殊的系統Service，需要非常特別的許可權，需要你手動在“設定－提示音和通知－通知使用許可權”中開啟，注意這個“通知使用許可權”選項，如果你裝置裡沒有需要使用通知使用許可權換句話說就是沒有含有NotificationListenerService的應用的話，這個設定選項是不可見的： 

這時我們勾選我們的應用，會彈出一個提示框： 

所以，你想好如何騙你的使用者勾選這個勾勾了麼，一旦勾上，一發不可收拾，這時你就會看到我們的程序啟動起來了：

[email protected]:/ # ps|grep aigestudio                                            
u0_a61    9513  339   1003044 30532 ffffffff f74aa3b5 S com.aigestudio.daemon
u0_a61    12869 339   993080 23792 ffffffff f74aa3b5 S com.aigestudio.daemon:service

• 1
• 2
• 3

• 1
• 2
• 3

好了，這時候，見證奇蹟的時候來了，不管是某米、某族還是某某，請嘗試下它們的一鍵清理，你會發現不管怎麼殺，我們的程序都還在，除了一小部分名不經傳的手機因為修改系統邏輯將其殺死外，絕大部分手機都不會殺掉該程序，為什麼呢？好事的朋友一定會去check該程序的adj值：

root@vbox86p:/ # ps|grep aigestudio                                            
u0_a61    12869 339   993080 23792 ffffffff f74aa3b5 S com.aigestudio.daemon:service
root@vbox86p:/ # cat /proc/12869/oom_adj
0

• 1
• 2
• 3
• 4

• 1
• 2
• 3
• 4

你會發現我們的程序被置為前臺程序了，而且不僅僅是這樣哦，即便你重啟裝置開機，它也會首先被啟動，因為其內部邏輯會使其在系統啟動時繫結並開始監聽通知，當然我們這裡並沒有任何關於通知的邏輯，那麼你可能會問愛哥這又有什麼用呢？我們又不能在NotificationListenerService裡處理與通知不相關的邏輯，沒錯，是這樣，但是我們也沒必要啊，我們只需新建一個Service並使其與NotificationListenerService在同一程序下，那麼我們的這個Sefvice不就一樣不死了嗎：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.aigestudio.daemon">

    <application>
        <service
            android:name=".services.DaemonService"
            android:process=":service" />
        <service
            android:name=".core.DService"
            android:permission="android.permission.BIND_NOTIFICATION_LISTENER_SERVICE"
            android:process=":service">
            <intent-filter>
                <action android:name="android.service.notification.NotificationListenerService" />
            </intent-filter>
        </service>
    </application>
</manifest>

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17

這種方式唯一的一個缺點就是你需要欺騙使用者手動去開啟通知許可權，需要給使用者一個合理的理由，所以對於跟通知許可權根本不沾邊的應用想想還是算了吧，用了這種方式安全軟體都拿你沒辦法了。 

KFC外帶全家桶

以全家桶的方式去相互喚醒相互拉活是目前來說最穩定最安全的方式，各大牛逼點的應用都有類似行為，當然對於很多小應用來說，沒有BAT那樣的實力，不過你依然可以使用一些第三方的網路服務，比如XX推送，一旦裝置上的某應用通過XX的推送獲得訊息時，是可以間接喚醒其它應用並推送與其相關的訊息的。好了，就先扯這麼多。