La actividad se reinicia al cerrar la fuerza

Tengo una aplicación con una sola actividad raíz. Hace poco me llamó la atención que cualquier tipo de Cierre de la fuerza en mi Actividad resulta en que se reinicie y no tengo idea de por qué esto podría suceder. Si fuerzo una excepción no detectada o uso la opción "pulsación larga para forzar el cierre", ambos resultan en lo mismo.La actividad se reinicia al cerrar la fuerza

Mi única conjetura habría sido alguna forma de peculiaridad relacionada con las referencias retenidas a alguna parte de la Actividad, solo que no tengo ninguna fuera de algunas entradas de WeakReference en el nivel de Aplicación.

entradas LogCat pertinentes:

05-25 08:25:49.137: INFO/ActivityManager(18449): Displayed uk.co.randomicon.rstb/.TreeBuilderActivity: +8s82ms 
05-25 08:25:54.222: DEBUG/dalvikvm(18546): GC_EXPLICIT freed 12K, 57% free 3640K/8327K, external 8323K/10136K, paused 72ms 
05-25 08:25:55.373: WARN/InputManagerService(18449): Got RemoteException sending setActive(false) notification to pid 19122 uid 10069 
05-25 08:25:59.217: DEBUG/dalvikvm(18646): GC_EXPLICIT freed 128K, 48% free 2980K/5703K, external 0K/0K, paused 67ms 
05-25 08:26:00.238: DEBUG/dalvikvm(18991): GC_CONCURRENT freed 343K, 51% free 2794K/5639K, external 303K/532K, paused 3ms+3ms 
05-25 08:26:02.950: INFO/Process(18449): Sending signal. PID: 19554 SIG: 9 
05-25 08:26:02.980: INFO/ActivityManager(18449): Process uk.co.randomicon.rstb (pid 19554) has died. 
05-25 08:26:02.990: ERROR/InputDispatcher(18449): channel '40a16ec8 uk.co.randomicon.rstb/uk.co.randomicon.rstb.TreeBuilderActivity (server)' ~ Consumer closed input channel or an error occurred. events=0x8 
05-25 08:26:02.990: ERROR/InputDispatcher(18449): channel '40a16ec8 uk.co.randomicon.rstb/uk.co.randomicon.rstb.TreeBuilderActivity (server)' ~ Channel is unrecoverably broken and will be disposed! 
05-25 08:26:02.990: INFO/WindowManager(18449): WINDOW DIED Window{40a16ec8 uk.co.randomicon.rstb/uk.co.randomicon.rstb.TreeBuilderActivity paused=false} 
05-25 08:26:03.010: WARN/WindowManager(18449): Failed looking up window 
05-25 08:26:03.010: WARN/WindowManager(18449): java.lang.IllegalArgumentException: Requested window [email protected] does not exist 
05-25 08:26:03.010: WARN/WindowManager(18449):  at com.android.server.WindowManagerService.windowForClientLocked(WindowManagerService.java:8177) 
05-25 08:26:03.010: WARN/WindowManager(18449):  at com.android.server.WindowManagerService.windowForClientLocked(WindowManagerService.java:8168) 
05-25 08:26:03.010: WARN/WindowManager(18449):  at com.android.server.WindowManagerService$WindowState$DeathRecipient.binderDied(WindowManagerService.java:7026) 
05-25 08:26:03.010: WARN/WindowManager(18449):  at android.os.BinderProxy.sendDeathNotice(Binder.java:385) 
05-25 08:26:03.010: WARN/WindowManager(18449):  at dalvik.system.NativeStart.run(Native Method) 
05-25 08:26:03.010: INFO/WindowManager(18449): WIN DEATH: null 
05-25 08:26:03.020: INFO/ActivityManager(18449): Start proc uk.co.randomicon.rstb for activity uk.co.randomicon.rstb/.TreeBuilderActivity: pid=19565 uid=10069 gids={1015}

¿Alguna idea de dónde comienzan incluso meter sería recibida con gratitud!

EDITAR: Esto fue causado por mí configuración android: stateNotNeeded = "true" en mi Manifiesto. Si bien no necesito el estado, esto provocó que Android decidiera que era mejor reiniciar mi aplicación en el supuesto de que el usuario quisiera eso.

Fuente

2011-05-25 Zulaxia

Here es algo de información útil:

Por lo que cuando se reinicia una actividad - si el proceso que ejecuta el actividad de primer plano desaparece, el sistema tirará que la actividad si no lo hace tiene un estado válido de guardado (lo que significa que está en pausa y le ha dado al sistema el resultado de onSaveInstanceState antes de la pausa ). Una vez que ha decidido si desecha o no esa actividad, reanudará cualquier actividad que esté ahora en la parte superior de la pila. Si esto es una de sus actividades, ya sea porque tiene otra detrás de la que se estrelló , o la que se coló fue de alguna manera el estado de pausa establecido - entonces comenzará su proceso nuevamente para mostrar esa actividad principal.

Fuente

2011-05-25 08:07:51 inazaruk

Gracias, buena información. Solo espero poder usarlo :) Lo he marcado como útil por ahora y lo aceptaré si resulta en una pausa establecida. – Zulaxia

Resultó ser la información perfecta, pero no para la parte que yo pensaba. Me di cuenta de que mencionaba tirarlo si no tenía un estado válido, solo que tenía android: stateNotNeeded = "true" en mi manifiesto. Por lo tanto, siempre pensó que estaba bien reiniciarlo (ya que técnicamente lo era). Acepté tu respuesta, ¡gracias! – Zulaxia

Del mismo modo, idea correcta, pero necesitaba una solución diferente. Al comenzar la nueva actividad, utilicé las banderas: Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK | \t \t Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS. Esto inicia la tarea en un nuevo hilo y se asegura de que todas las apariciones previas de su aplicación hayan desaparecido de la backstack. –

Esto puede deberse a una API del sistema que no está disponible en su dispositivo de destino. Me encontré con un problema similar al tratar de llamar ActivityManager.MemoryInfo.totalMem en un dispositivo 4.0.x. No he tenido ningún errores de compilación como lo estaba apuntando a 4.2.2 y ActivityManager.MemoryInfo.totalMem se añadió en API16 (4,1)

Fuente

2013-05-10 16:57:08 TheDeputy

si la aplicación tiene androide: persistente = "true" en el manifiesto, se reiniciará cuando fueron asesinados .

Fuente

2016-09-23 04:26:19

La actividad se reinicia al cerrar la fuerza

Respuesta

Cuestiones relacionadas