Android Serviceサービスが殺されない妙技です。

ServiceはAndroidシステムの一つのコンポーネントで、Activityと同じレベルですが、彼は自分で運転できなくて、バックグラウンドでしか動作できません。他のコンポーネントと対話できます。
Androidの開発過程では、startServiceを呼び出すたびに、Serviceの対象となるオンストップCommand（Intent，int，int）方法を呼び出して、オンストップCommand方法で処理します。
Android公式文書から、onStartCommandは4つのintの戻り値があることを知っています。まず、簡単にintの戻り値の役割を説明します。
一、onStartCommandは4種類の戻り値があります。
START_STICKY：serviceプロセスがkillによって失われた場合、serviceの状態は開始状態となりますが、配信されたintentオブジェクトは保留されません。その後、システムはserviceの再作成を試みます。サービス状態はスタート状態ですので、サービスを作成すると必ずオンストップCommand（Intent，int）メソッドを呼び出します。この期間中に任意の起動コマンドがserviceに渡されない場合、パラメータIntentはnullになります。
START_NOT_STICKY：「非粘性的」です。これを使って値を返した場合、ワンストップCommandを実行した後、サービスが異常にキルトされ、システムは自動的にサービスを再開しません。
START_REDELIVER_INTENT：Intentを再送します。これを使って値を返した場合、ワンストップを実行した後、サービスが異常にキルトされ、システムが自動的にサービスを再開し、Intentの値を入力します。
START_STICKY_COMPATIBILITY：START_STICKYの互換版ですが、サービスがキルによって再開されることは保証されていません。
二、殺されないサービスを作成する。
1.serviceに次の方法を書き換える方法は、3つの戻り値、START_があります。STICKY（またはSTART_）STICKY_COMPATIBILITYはserviceがkillに掉われてから自動的に書き換えて作成します。

@Override
 public int onStartCommand(Intent intent, int flags, int startId)
 {
 return START_STICKY_COMPATIBILITY;
 //return super.onStartCommand(intent, flags, startId);
 }

または

 @Override
 public int onStartCommand(Intent intent, int flags, int startId)
 {
 flags = START_STICKY;
 return super.onStartCommand(intent, flags, startId);
 // return START_REDELIVER_INTENT;
 }
@Override
public void onStart(Intent intent, int startId)
{
//         
IntentFilter localIntentFilter = new IntentFilter("android.intent.action.USER_PRESENT");
localIntentFilter.setPriority(Integer.MAX_VALUE);//      
myReceiver searchReceiver = new myReceiver();
registerReceiver(searchReceiver, localIntentFilter);
super.onStart(intent, startId);
}

2.Serviceのon Destroy（）でServiceを再起動します。

 public void onDestroy()
 {
 Intent localIntent = new Intent();
 localIntent.setClass(this, MyService.class); //        Service
 this.startService(localIntent);
 }

3.ラジオを作成する

public class myReceiver extends BroadcastReceiver
{
 @Override
 public void onReceive(Context context, Intent intent)
 {
 context.startService(new Intent(context, Google.class));
 }
}

4.Android Manifest.xmlに登録放送myReceiverとMyServiceサービス

<receiver android:name=".myReceiver" >
      <intent-filter android:priority="2147483647" ><!--      -->
        <!--            -->
        <action android:name="android.intent.action.BOOT_COMPLETED" />       
        <!--          -->
        <action android:name="android.intent.action.USER_PRESENT" />
        <!--        -->
        <action android:name="android.media.RINGER_MODE_CHANGED" />       
      </intent-filter>
</receiver>
<service android:name=".MyService" >

注：ロック解除、起動、シーンの切り替え放送には、起動完了、携帯電話の状態などの権限が必要です。

<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
<uses-permission android:name="android.permission.READ_PHONE_STATE" />

 ZTE U 795携帯電話Android 4.0.4バージョンadb pushからsystem\ap下android：persistent="true"
コアプログラムとなり、360で殺すプロセスの時も、myReceiverは相変わらず有効で、serviceの再生を保証します。えっと、
KILL問題：
1.settings中stop service
on Destroyメソッドでは、startServiceを呼び出してServiceの再起動を行います。
2.settingsにおけるforce stopアプリケーション
捕捉システムで放送する（actionはandroid.intent.actions.PACKAGE_RESTART ED）
3.第三者の助けを借りてキルダウンタンスキーを適用する
serviceの優先度を上げて、プログラム署名、またはadb pushからsystem\apなどに行く。
data/ap下のアプリケーションに比べて、そのManifest.xmlファイルにpersistent属性をtrueとすると、out-off-memory killerの影響を受けないように、system/ap下のアプリケーションがより多くの特権を享受することができる。アプリケーション'Phone'のAndroid Manifest.xmlファイルのようです。

  <application android:name="PhoneApp"
         android:persistent="true"
         android:label="@string/dialerIconLabel"
         android:icon="@drawable/ic_launcher_phone">
     ...
  </application>

設定後、アプリはシステムのコアレベルにアップします。