Transizione attività: esecuzione dell'arresto dell'attività non ripristinata

Question

Sto provando a utilizzare la nuova API per la transizione delle attività solo su lollipop (sto utilizzando la versione compatta tho), quindi sto implementando un'animazione dall'attività A all'attività B, in attività a:

getWindow().setReenterTransition(null); 
getWindow().setExitTransition(null); 
getWindow().setAllowEnterTransitionOverlap(false); 
getWindow().setAllowReturnTransitionOverlap(false); 

perché io non sono interessato a entrare o uscire di questa attività, gli unici animazioni che voglio vedere sono nella visualizzazione condivisa con l'Activity B.

Per l'avvio dell'attività B:

ActivityCompat.startActivity(this, intent, ActivityOptionsCompat.makeSceneTransitionAnimation(this, fabButton, getString(R.string.transition_fab)).toBundle()); 

E la messa a punto di attività B:

getWindow().setEnterTransition(new EmptyTransition()); 
getWindow().setReturnTransition(null); 
getWindow().setAllowEnterTransitionOverlap(false); 
getWindow().setAllowReturnTransitionOverlap(false); 
getWindow().getEnterTransition().addListener(listener). 

Anche in questo caso non mi interessa entrare nel passaggio di transizione di ritorno perché il contenuto è nascosto fino alla transizione metodo di entrare ascoltatore 'onTransitionEnd' si chiama, quindi la mia transizione è tutto basato sull'elemento condiviso che si sposta/cresce dall'Attività A all'attività B e quando questa transizione è terminata sto portando il contenuto.

Tutto funziona bene, ma su dispositivi non molto potenti (quindi tutti i non- Nexus) di volta in volta l'attività A si blocca silenziosamente con:

java.lang.RuntimeException: Performing stop of activity that is not resumed: {com.transferwise.android.debug/com.transferwise.android.activity.LoggedInMainActivity} 

E la transizione dell'elemento condiviso si verifica ma il listener non viene chiamato (non evento TransitionStart), quindi il contenuto non viene inserito. L'app non si arresta, l'utente può comunque tornare indietro e "riprovare" ma non è un ottimo UX.

È difficile testarlo perché accade una volta ogni 10/20 volte e solo su alcuni dispositivi specifici (succede più su un Sony Xperia Z3 compatto).

anche:

Danieles-MacBook-Pro-2:~ danielebottillo$ adb shell dumpsys activity p | grep com.package.main.debug 
    *APP* UID 10349 ProcessRecord{3b27508d 18371:com.package.main.debug/u0a349} 
    dir=/data/app/com.package.main.debug-1/base.apk publicDir=/data/app/com.package.main.debug-1/base.apk data=/data/data/com.package.main.debug 
    packageList={com.package.main.debug} 
     - ActivityRecord{2f07bdf8 u0 com.package.main.debug/com.package.main.activity.ActivityA t1196} 
     - ActivityRecord{1e871eb3 u0 com.package.main.debug/com.package.main.activity.ActivityB t1196} 
     - 28ea3e28/com.android.providers.settings/.SettingsProvider->18371:com.package.main.debug/u0a349 s1/1 u0/0 +27m9s645ms 
     - ReceiverList{40f2178 18371 com.package.main.debug/10349/u0 remote:39e102db} 
     - ReceiverList{2e7456a6 18371 com.package.main.debug/10349/u0 remote:dde3801} 
     - ReceiverList{39e2f1b7 18371 com.package.main.debug/10349/u0 remote:362300b6} 
     - ReceiverList{3afa7bd5 18371 com.package.main.debug/10349/u0 remote:33e4088c} 
    ProC# 0: fore F/A/T trm:10 18371:com.package.main.debug/u0a349 (top-activity) 
    PID #18371: ProcessRecord{3b27508d 18371:com.package.main.debug/u0a349} 

Answer 1

A giudicare dalle altre risposte qui, posso vedere un paio di possibilità.

Memory: è possibile che il dispositivo stia esaurendo la memoria, quindi Android sta uccidendo attività non in primo piano. Forse sta cercando di fare qualcosa con fabButton dopo che l'attività A viene uccisa. Puoi ridurre il consumo di memoria e vedere se questo riduce o elimina il problema?

Lifecycle: se si sta passando dall'attività A all'attività B dal metodo onStart() dell'Attività A, allora l'attività A potrebbe essere interrotta prima che possa essere eseguita onResume(). Se hai codice significativo in onStart(), prova a spostarlo su onResume(). Questo dovrebbe impedire che l'attività A venga uccisa prima che arrivi a onResume().