Una de mis aplicaciones hace algo muy similar. Para reactivar el servicio después de un período determinado recomiendo postDelayed()
tienen un campo manejador:
private final Handler handler = new Handler();
y un repaso Runnable
private final Runnable refresher = new Runnable() {
public void run() {
// some action
}
};
Puede disparar sus notificaciones en el ejecutable.
En la construcción de servicios, y después de cada ejecución empezar así:
handler.postDelayed(refresher, /* some delay in ms*/);
En onDestroy()
retirar el anuncio
handler.removeCallbacks(refresher);
Para iniciar el servicio en tiempo de arranque que necesita un motor de arranque automático. Esto va en el manifiesto
<receiver android:name="com.example.ServiceAutoStarter">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>
y la ServiceAutoStarter
se ve así:
public class ServiceAutoStarter extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
context.startService(new Intent(context, UpdateService.class));
}
}
parando el sistema operativo de matar el servicio es complicado. Además, su aplicación puede tener un RuntimeException
y bloquearse, o su lógica puede bloquearse.
En mi caso, pareció ayudar a actualizar siempre el servicio en pantalla con un BroadcastReceiver
. Entonces, si la cadena de actualizaciones se detiene, resucitará cuando el usuario use su teléfono.
En el servicio:
private BroadcastReceiver screenOnReceiver;
En su servicio onCreate()
screenOnReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
// Some action
}
};
registerReceiver(screenOnReceiver, new IntentFilter(Intent.ACTION_SCREEN_ON));
A continuación, anular el registro su servicio en onDestroy()
con
unregisterReceiver(screenOnReceiver);
normalmente me gusta sus respuestas, pero este ... no tanto. :-(Por ejemplo, está proponiendo que el servicio registre un receptor para que se resucite una vez asesinado. El receptor será asesinado junto con el servicio, por lo tanto, esto no debería tener ningún efecto. Además, todo el concepto de un servicio eterno es horrible en Android y es la razón por la que los usuarios están luchando con asesinos de tareas o la pantalla Servicios en ejecución en la aplicación Configuración. Hay muy pocos casos en los que se necesita un servicio verdaderamente duradero; la gran mayoría de las veces, 'AlarmManager' será suficiente. – CommonsWare
Gracias CWare, probablemente debería haber aclarado que el resurrector debe protegerse contra fallas lógicas y las muchas cosas que pueden detener la cadena de eventos que activan el servicio, ya que lo que se atribuye al cierre del sistema del sistema a menudo puede ser otra cosa Examinaré el enfoque del gestor de alarmas, recuerdo vagamente haber intentado esto hace algún tiempo y no poder hacerlo funcionar. –