Android: vuelve a invocar la aplicación si el administrador de tareas mata

El hilo de la aplicación se cierra si el administrador de tareas lo mata. Necesidad de volver a invocar la aplicación como si su matado por otra aplicación o administrador de tareas. ¿Alguna idea?

Debe ejecutar el servicio de fondo con el comando START_STICKY. Sólo extiende Service y anula onCommand como esto:

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

Al igual que esto, su servicio se reinicia cuando está cerca (por sistema o cualquier otra cosa)

Sólo tiene que comprobar su servicio (onCreate por ejemplo) si la aplicación se está ejecutando o no y volver a iniciarlo si no. Supongo que PackageManager le permite comprobar esto o simplemente poner un static boolean is_alive para ver si su actividad siempre se está ejecutando.

Saludos Jim

Error en Android 2.3 con START_STICKY

Necesitaba mantener vivo un Servicio con todas mis fuerzas. Si el servicio se está ejecutando en cualquier momento, puede hacer clic en la interfaz de usuario.

 onDestroy() 

Se relanzará.

No se puede desinstalar la aplicación, ya que tiene un Administrador de dispositivos.

Es una especie de control parental, el usuario sabe que está allí. La única forma de detener es quitar el Administrador de dispositivos y desinstalarlo, pero al eliminar Administrador de dispositivos bloqueará el teléfono como Kaspersky.

Hay un botín de receptores de braodcast, como el arranque finshed, presen usuario, pantalla encendido, pantalla apagado …, muchos otros, todo el servicio de inicio, se puede hacer con la interfaz de usuario también. O en el servicio de verificación si su actividad con vida, visible, si no, que pop.

Espero que utilice con buena razón la información!

Editar: reiniciar el fragmento de código de servicio:

  // restart service: Context context = getApplicationContext(); Intent myService = new Intent(context, MyService.class); context.startService(myService); 

Edit2: agrega spippet para comprobar si el servicio se está ejecutando en … una carga de transmisiones

  public static boolean isMyServiceRunning(Context context) { ActivityManager manager = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE); for (RunningServiceInfo service : manager.getRunningServices(Integer.MAX_VALUE)) { if (MyService.class.getName().equals(service.service.getClassName())) { Log.d("myTag", "true"); return true; } } Log.d("myTag", "false"); return false; } 

Edit3 inicio de otros servicios:

  public static void startTheService(Context context) { Intent myService = new Intent(context, MyService.class); context.startService(myService); } 

No te olvides de Android 2.3 bug: hacer la lógica para la inicialización en

 @Override public void onCreate() 

Y no en:

  @Override public int onStartCommand(Intent intent, int flags, int startId) 

Mientras que mire el código de fuente oficial del producto de Google IO he encontrado el siguiente

 ((AlarmManager) context.getSystemService(ALARM_SERVICE)) .set( AlarmManager.RTC, System.currentTimeMillis() + jitterMillis, PendingIntent.getBroadcast( context, 0, new Intent(context, TriggerSyncReceiver.class), PendingIntent.FLAG_CANCEL_CURRENT)); 

URL para el código

Usted puede comenzar un servicio pegajoso y registrar un encargado de la alarma que compruebe una y otra vez que es su uso está vivo si no entonces lo funcionará.

También puede hacer un receptor y registrarlo para <action android:name="android.intent.action.BOOT_COMPLETED" /> entonces puede iniciar su servicio desde su receptor. Creo que debería haber algún mensaje de difusión cuando OS o mata algún servicio / aplicación.

Sólo para darle una idea aproximada He hecho esto y su funcionamiento 1) receptor de registro Código del receptor:

@Override public void onReceive (Contexto contextual, intención de intención) {

  try { this.mContext = context; startService(intent.getAction()); uploadOnWifiConnected(intent); } catch (Exception ex) { Logger.logException(ex); Console.showToastDelegate(mContext, R.string.msg_service_starup_failure, Toast.LENGTH_LONG); } } private void startService(final String action) { if (action.equalsIgnoreCase(ACTION_BOOT)) { Util.startServiceSpawnProcessSingelton(mContext, mConnection); } else if (action.equalsIgnoreCase(ACTION_SHUTDOWN)) { } } 

Código de servicio:

 @Override public int onStartCommand(Intent intent, int flags, int startId) { Logger.logInfo("Service Started onStartCommand"); return Service.START_STICKY; } 

Prefiero no hacer nada en onStartCommand porque se llamará cada vez que inicie el servicio, pero onCreate sólo se llama servicio de primera vez se inicia, así que hago la mayor parte del código en onCreate, de esa manera realmente no me preocupo por el servicio de tiempo ya es Funcionando o no.

De acuerdo con @RetoMeyer de Google, la solución es hacer la aplicación "pegajosa".

Para ello, debe establecer START_STICKY en su gestión de servicios de intenciones.

Compruebe esta referencia del desarrollador android

Sí, una vez que el problema de memoria baja viene android os comienza a matar la aplicación para compensar la memoria necesaria. Utilizando los servicios que usted puede lograr, su servicio debe funcionar paralelamente con su aplicación, pero ver, algunos de los casos, incluso su servicio también se matan al mismo tiempo. Después de matar si la memoria es suficiente, el android os intenta reiniciar la aplicación en todos los casos. Finalmente no hay una regla dura y rápida para volver a invocar su aplicación una vez muerta por os en todos los casos depende de os y comportamientos internos.

FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.