L'attività viene riavviata in chiusura forzata

Possiedo un'applicazione con un'attività singola radice. Recentemente ho notato che qualsiasi tipo di Force Close sulla mia attività ne provoca il riavvio e non ho idea del motivo per cui ciò potrebbe accadere. Se forzo un'eccezione non rilevata o utilizzo l'opzione 'premere a lungo indietro per forzare la chiusura', entrambi risultano nello stesso modo.L'attività viene riavviata in chiusura forzata

La mia unica ipotesi sarebbe stata una qualche forma di stranezza relativa ai riferimenti conservati in qualche parte dell'attività, solo che non ho alcun elemento esterno a qualche voce WeakReference a livello di applicazione.

voci logcat rilevanti:

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}

Tutte le idee da dove cominciare, anche frugando riconoscente sarebbe ricevuto!

MODIFICA: Questo è stato causato da me impostando android: stateNotNeeded = "true" nel mio manifest. Mentre non ho bisogno dello stato, questo ha causato che Android decidesse che era meglio rilanciare la mia app sul presupposto che l'utente avrebbe voluto.

fonte

2011-05-25 Zulaxia

Here è alcune informazioni utili:

Per quanto riguarda quando un'attività viene riavviato - se il processo in esecuzione l'attività di primo piano va via, il sistema buttare via che l'attività se non lo fa avere uno stato salvato valido per esso (in genere significa che è in pausa e ha fornito al sistema il risultato di onSaveInstanceState da prima della pausa ). Una volta che ha deciso se buttare o meno quell'attività, lo riprenderà qualsiasi attività sia ora in cima allo stack. Se questo è una delle vostre attività - sia perché si ha un altro dietro quella che si è schiantato, o quello che si è schiantato era in qualche modo il costante stato di pausa - allora ricomincerà il processo per dimostrare che l'attività in alto.

fonte

2011-05-25 08:07:51 inazaruk

Grazie, buona informazione. Spero solo di poterlo usare :) L'ho segnato come utile per ora e accetto se risulta essere in pausa stabilita. – Zulaxia

Si è rivelato essere l'informazione perfetta, ma non per la parte che ho pensato. Mi sono accorto di averlo menzionato buttandolo via se non avesse uno stato salvato valido, solo che avevo Android: stateNotNeeded = "true" nel mio manifest. Quindi ha sempre pensato che fosse il caso di riavviarlo (dal momento che tecnicamente era). Ho accettato la tua risposta, grazie! – Zulaxia

Allo stesso modo, giusta idea, ma aveva bisogno di una soluzione diversa. Quando ho iniziato la nuova attività, ho usato i flag: Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK | \t \t Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS. Questo avvia l'attività su una nuova discussione e assicura che tutte le occorrenze precedenti della tua app siano state rimosse dal backstack. –

Ciò può essere causato chiamando un'API di sistema che non è disponibile sul dispositivo di destinazione. Mi sono imbattuto in un problema simile cercando di chiamare ActivityManager.MemoryInfo.totalMem su un dispositivo 4.0.x. Non ho ricevuto errori di compilazione poiché avevo come target il 4.2.2 e ActivityManager.MemoryInfo.totalMem è stato aggiunto in API16 (4.1)

fonte

2013-05-10 16:57:08 TheDeputy

se l'app ha Android: persistent = "true" in manifest, verrà riavviato quando verrà ucciso .

fonte

2016-09-23 04:26:19

L'attività viene riavviata in chiusura forzata

risposta

Problemi correlati