Obteniendo la excepción “IllegalStateException: No se puede realizar esta acción después de onSaveInstanceState”

Tengo una aplicación de Android en vivo, y del mercado he recibido el siguiente seguimiento de stack y no tengo idea de por qué está sucediendo, ya que no está sucediendo en el código de la aplicación, pero se debe a algún u otro evento de la aplicación (suposición)

No estoy usando Fragmentos, aún hay una referencia de FragmentManager. Si algún cuerpo puede arrojar algo de luz sobre algunos hechos ocultos para evitar este tipo de problema:

java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState at android.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1109) at android.app.FragmentManagerImpl.popBackStackImmediate(FragmentManager.java:399) at android.app.Activity.onBackPressed(Activity.java:2066) at android.app.Activity.onKeyDown(Activity.java:1962) at android.view.KeyEvent.dispatch(KeyEvent.java:2482) at android.app.Activity.dispatchKeyEvent(Activity.java:2274) at com.android.internal.policy.impl.PhoneWindow$DecorView.dispatchKeyEvent(PhoneWindow.java:1668) at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112) at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112) at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112) at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112) at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112) at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:1112) at com.android.internal.policy.impl.PhoneWindow$DecorView.superDispatchKeyEvent(PhoneWindow.java:1720) at com.android.internal.policy.impl.PhoneWindow.superDispatchKeyEvent(PhoneWindow.java:1258) at android.app.Activity.dispatchKeyEvent(Activity.java:2269) at com.android.internal.policy.impl.PhoneWindow$DecorView.dispatchKeyEvent(PhoneWindow.java:1668) at android.view.ViewRoot.deliverKeyEventPostIme(ViewRoot.java:2851) at android.view.ViewRoot.handleFinishedEvent(ViewRoot.java:2824) at android.view.ViewRoot.handleMessage(ViewRoot.java:2011) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:132) at android.app.ActivityThread.main(ActivityThread.java:4025) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:491) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:841) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:599) at dalvik.system.NativeStart.main(Native Method) 

Este es el error más estúpido que he encontrado hasta ahora. Tenía una aplicación Fragment que funcionaba perfectamente para API <11 y Force Closing en API> 11 .

Realmente no pude entender lo que cambiaron dentro del ciclo de vida de la Activity en la llamada a saveInstance , pero así es como resolví esto:

 @Override protected void onSaveInstanceState(Bundle outState) { //No call for super(). Bug on API Level > 11. } 

Simplemente no llamo a .super() y todo funciona bien. Espero que esto te ahorre algo de tiempo.

EDITAR: después de un poco más de investigación, este es un error conocido en el paquete de soporte.

Si necesita guardar la instancia y agregar algo a su outState Bundle , puede usar lo siguiente:

 @Override protected void onSaveInstanceState(Bundle outState) { outState.putString("WORKAROUND_FOR_BUG_19917_KEY", "WORKAROUND_FOR_BUG_19917_VALUE"); super.onSaveInstanceState(outState); } 

EDIT2: esto también puede ocurrir si está intentando realizar una transacción después de que su Activity se haya ido en segundo plano. Para evitar esto, debe usar commitAllowingStateLoss()

EDIT3: Las soluciones anteriores estaban solucionando problemas en las primeras bibliotecas de support.v4 de lo que puedo recordar. Pero si todavía tienes problemas con esto, también DEBES leer el blog de @AlexLockwood : Transacciones de Fragmentos y Pérdida de Estado de la Actividad

Resumen de la publicación del blog (pero te recomiendo que lo leas):

  • NUNCA commit() transacciones después de onPause() en pre-Honeycomb, y onStop() en post-Honeycomb
  • Tenga cuidado al realizar transacciones dentro de los métodos del ciclo de vida de la Activity . Use onCreate() , onResumeFragments() y onPostResume()
  • Evite realizar transacciones dentro de los métodos de callback asincrónica
  • Utilice commitAllowingStateLoss() solo como último recurso

Si busca en el código fuente de Android las causas de este problema, ese indicador mStateSaved en la clase FragmentManagerImpl (instancia disponible en Activity) tiene el valor true. Se establece en verdadero cuando se guarda la stack de respaldo (saveAllState) en la llamada de Activity#onSaveInstanceState . Después, las llamadas de ActivityThread no reinician este indicador utilizando los métodos de reinicio disponibles de FragmentManagerImpl#noteStateNotSaved() y dispatch() .

De la forma en que lo veo, hay algunas soluciones disponibles, según lo que esté haciendo tu aplicación y utilizando:

Buenas maneras

Antes que nada: anunciaría el artículo de Alex Lockwood . Entonces, por lo que he hecho hasta ahora:

  1. Para fragmentos y actividades que no necesitan guardar ninguna información de estado, llame a commitAllowStateLoss . Tomado de la documentación:

    Permite que la confirmación se ejecute después de guardar el estado de una actividad. Esto es peligroso porque la confirmación puede perderse si la actividad necesita ser restaurada más tarde desde su estado, por lo que esto solo debe usarse para casos en los que está bien que el estado de la IU cambie inesperadamente en el usuario. Supongo que esto está bien si el fragmento muestra información de solo lectura. O incluso si muestran información editable, utilice los métodos de callback para conservar la información editada.

  2. Justo después de la confirmación de la transacción (acaba de llamar a commit() ), realice una llamada a FragmentManager.executePendingTransactions() .

No se recomiendan formas:

  1. Como mencionó anteriormente Ovidiu Latcu, no llame a super.onSaveInstanceState() . Pero esto significa que perderá todo el estado de su actividad junto con el estado de los fragmentos.

  2. Anular onBackPressed y allí solo llamar a finish() . Esto debería estar bien si su aplicación no usa Fragmentos API; como en super.onBackPressed hay una llamada a FragmentManager#popBackStackImmediate() .

  3. Si está utilizando ambos Fragmentos API y el estado de su actividad es importante / vital, entonces puede tratar de llamar usando la API de reflexión FragmentManagerImpl#noteStateNotSaved() . Pero esto es un truco, o se podría decir que es una solución. No me gusta, pero en mi caso es bastante aceptable ya que tengo un código de una aplicación heredada que usa código obsoleto ( TabActivity e implícitamente LocalActivityManager ).

A continuación se muestra el código que usa la reflexión:

 @Override protected void onSaveInstanceState(Bundle outState) { super.onSaveInstanceState(outState); invokeFragmentManagerNoteStateNotSaved(); } @SuppressWarnings({ "rawtypes", "unchecked" }) private void invokeFragmentManagerNoteStateNotSaved() { /** * For post-Honeycomb devices */ if (Build.VERSION.SDK_INT < 11) { return; } try { Class cls = getClass(); do { cls = cls.getSuperclass(); } while (!"Activity".equals(cls.getSimpleName())); Field fragmentMgrField = cls.getDeclaredField("mFragments"); fragmentMgrField.setAccessible(true); Object fragmentMgr = fragmentMgrField.get(this); cls = fragmentMgr.getClass(); Method noteStateNotSavedMethod = cls.getDeclaredMethod("noteStateNotSaved", new Class[] {}); noteStateNotSavedMethod.invoke(fragmentMgr, new Object[] {}); Log.d("DLOutState", "Successful call for noteStateNotSaved!!!"); } catch (Exception ex) { Log.e("DLOutState", "Exception on worka FM.noteStateNotSaved", ex); } } 

¡Aclamaciones!

Tal excepción ocurrirá si intenta realizar una transición de fragmento después de que se onSaveInstanceState() la actividad de fragmento onSaveInstanceState() .

Una razón por la que esto puede suceder es si deja AsyncTask una AsyncTask (o Thread ) cuando se detiene una actividad.

Cualquier transición posterior a la onSaveInstanceState() podría perderse si el sistema recupera la actividad de los recursos y la recrea posteriormente.

Simplemente llame a super.onPostResume () antes de mostrar su fragmento o mueva su código en el método PostResume () después de llamar a super.onPostResume (). ¡Esto resuelve el problema!

Esto también puede ocurrir cuando se llama a dismiss() en un fragmento de diálogo después de que la pantalla se bloqueó \ se bloqueó y se guardó el estado de la instancia del diálogo Actividad +. Para evitar esta llamada:

 dismissAllowingStateLoss() 

Literalmente, cada vez que descarto un diálogo ya no me importa su estado, así que está bien hacerlo, en realidad no estás perdiendo ningún estado.

Solución corta y funcional:

Siga los pasos simples:

Paso 1 : anula el estado SaveStateInstanceState en el fragmento respectivo. Y elimine el supermétodo de él.

 @Override public void onSaveInstanceState(Bundle outState) { }; 

Paso 2 : use CommitAllowingStateLoss (); en lugar de commit (); mientras que las operaciones de fragmento.

 fragmentTransaction.commitAllowingStateLoss(); 

esto funcionó para mí … descubrí esto por mi cuenta … ¡espero que te ayude!

1) NO tiene un FragmentManager / FragmentTransaction “estático” global.

2) onCreate, ¡SIEMPRE inicialice FragmentManager nuevamente!

muestra a continuación: –

 public abstract class FragmentController extends AnotherActivity{ protected FragmentManager fragmentManager; protected FragmentTransaction fragmentTransaction; protected Bundle mSavedInstanceState; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); mSavedInstanceState = savedInstanceState; setDefaultFragments(); } protected void setDefaultFragments() { fragmentManager = getSupportFragmentManager(); //check if on orientation change.. do not re-add fragments! if(mSavedInstanceState == null) { //instantiate the fragment manager fragmentTransaction = fragmentManager.beginTransaction(); //the navigation fragments NavigationFragment navFrag = new NavigationFragment(); ToolbarFragment toolFrag = new ToolbarFragment(); fragmentTransaction.add(R.id.NavLayout, navFrag, "NavFrag"); fragmentTransaction.add(R.id.ToolbarLayout, toolFrag, "ToolFrag"); fragmentTransaction.commitAllowingStateLoss(); //add own fragment to the nav (abstract method) setOwnFragment(); } } 

Siempre estaba obteniendo esto cuando traté de mostrar el fragmento en el método de la actividad para el resultado (), por lo que el problema era el siguiente:

  1. Mi actividad está en pausa y detenida, lo que significa que ya se ha llamado a onSaveInstanceState () (tanto para dispositivos pre Honeycomb como posteriores a Honeycomb).
  2. En caso de cualquier resultado hice una transacción para mostrar / ocultar el fragmento, lo que causa esta IllegalStateException.

Lo que hice es el siguiente:

  1. Valor agregado para determinar si se realizó la acción que deseo (por ejemplo, tomar una foto de camere – isPhotoTaken) – puede ser un valor booleano o entero, dependiendo de cuántas transacciones diferentes necesite.
  2. En el método overriden onResumeFragments (), verifiqué mi valor y después de realizar las transacciones de fragmento que necesitaba. En este caso, commit () no se realizó después de onSaveInstanceState, ya que el estado se devolvió en el método onResumeFragments ().

Resolví el problema con onconfigurationchanged. El truco es que de acuerdo con el ciclo de vida de la actividad de Android, cuando llamas explícitamente un bash (bash de cámara, o cualquier otro); la actividad está en pausa y se guarda. Se llama instancia en ese caso. Al girar el dispositivo a una posición diferente a aquella durante la cual la actividad estaba activa; hacer operaciones de fragmentos como la confirmación de fragmentos causa una excepción de estado ilegal. Hay muchas quejas al respecto. Es algo sobre la gestión del ciclo de vida de la actividad android y las llamadas al método adecuado. Para resolverlo, hice esto: 1: anule el método de su actividad onsaved, determine la orientación de la pantalla actual (vertical u horizontal) y luego configure la orientación de la pantalla antes de detener la actividad. de esa forma la actividad bloquea la rotación de la pantalla para su actividad en caso de que haya sido rotada por otra. 2-luego, anule el método de actividad y cambie su modo de orientación ahora al sensor para que después de invocar el método guardado llame una vez más a la configuración para manejar la rotación correctamente.

Puede copiar / pegar este código en su actividad para manejarlo:

 @Override protected void onSaveInstanceState(Bundle outState) { super.onSaveInstanceState(outState); Toast.makeText(this, "Activity OnResume(): Lock Screen Orientation ", Toast.LENGTH_LONG).show(); int orientation =this.getDisplayOrientation(); //Lock the screen orientation to the current display orientation : Landscape or Potrait this.setRequestedOrientation(orientation); } //A method found in stackOverflow, don't remember the author, to determine the right screen orientation independently of the phone or tablet device public int getDisplayOrientation() { Display getOrient = getWindowManager().getDefaultDisplay(); int orientation = getOrient.getOrientation(); // Sometimes you may get undefined orientation Value is 0 // simple logic solves the problem compare the screen // X,Y Co-ordinates and determine the Orientation in such cases if (orientation == Configuration.ORIENTATION_UNDEFINED) { Configuration config = getResources().getConfiguration(); orientation = config.orientation; if (orientation == Configuration.ORIENTATION_UNDEFINED) { // if height and widht of screen are equal then // it is square orientation if (getOrient.getWidth() == getOrient.getHeight()) { orientation = Configuration.ORIENTATION_SQUARE; } else { //if widht is less than height than it is portrait if (getOrient.getWidth() < getOrient.getHeight()) { orientation = Configuration.ORIENTATION_PORTRAIT; } else { // if it is not any of the above it will defineitly be landscape orientation = Configuration.ORIENTATION_LANDSCAPE; } } } } return orientation; // return value 1 is portrait and 2 is Landscape Mode } @Override public void onResume() { super.onResume(); Toast.makeText(this, "Activity OnResume(): Unlock Screen Orientation ", Toast.LENGTH_LONG).show(); setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_SENSOR); } 

Creo que el estado del ciclo de vida puede ayudar a prevenir ese locking a partir de la versión v26.1.0 de soporte de Android; puede tener la siguiente verificación:

 if (getLifecycle().getCurrentState().isAtLeast(Lifecycle.State.STARTED)){ // Do fragment's transaction commit } 

o puedes probar:

 Fragment.isStateSaved() 

más información aquí https://developer.android.com/reference/android/support/v4/app/Fragment.html#isStateSaved ()

Tuve el mismo problema al obtener IllegalStateException, pero reemplazar todas mis llamadas a commit () con commitAllowingStateLoss () no me ayudó.

El culpable fue un llamado a DialogFragment.show ().

Lo rodeo con

 try { dialog.show(transaction, "blah blah"); } catch(IllegalStateException e) { return; } 

y eso lo hizo. OK, no consigo mostrar el diálogo, pero en este caso estuvo bien.

Era el único lugar en mi aplicación donde llamé por primera vez a FragmentManager.beginTransaction () pero nunca llamé a commit (), así que no lo encontré cuando busqué “commit ()”.

Lo curioso es que el usuario nunca abandona la aplicación. En cambio, el asesino era un anuncio intersticial de AdMob que aparecía.

Mi solución para ese problema era

En fragmentos, agregue métodos:

 @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { ... guideMapFragment = (SupportMapFragment)a.getSupportFragmentManager().findFragmentById(R.id.guideMap); guideMap = guideMapFragment.getMap(); ... } @Override public void onDestroyView() { SherlockFragmentActivity a = getSherlockActivity(); if (a != null && guideMapFragment != null) { try { Log.i(LOGTAG, "Removing map fragment"); a.getSupportFragmentManager().beginTransaction().remove(guideMapFragment).commit(); guideMapFragment = null; } catch(IllegalStateException e) { Log.i(LOGTAG, "IllegalStateException on exit"); } } super.onDestroyView(); } 

Puede ser malo, pero no pudo encontrar nada mejor.

Tengo el mismo problema en mi aplicación. Me he resuelto este problema simplemente llamando al super.onBackPressed(); en la clase anterior y llamando a commitAllowingStateLoss() en la clase actual con ese fragmento.

Se invocará onSaveInstance si un usuario gira la pantalla para que pueda cargar los recursos asociados con la nueva orientación.

Es posible que este usuario haya rotado la pantalla y luego haya presionado el botón Atrás (porque también es posible que este usuario haya confundido su teléfono mientras usaba su aplicación)

Tengo este problema. Pero creo que este problema no está relacionado con commit y commitAllowStateLoss.

El siguiente mensaje de seguimiento y excepción se trata de commit ().

 java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState at android.support.v4.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1341) at android.support.v4.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:1352) at android.support.v4.app.BackStackRecord.commitInternal(BackStackRecord.java:595) at android.support.v4.app.BackStackRecord.commit(BackStackRecord.java:574) 

Pero esta excepción fue causada por onBackPressed ()

 java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState at android.support.v4.app.FragmentManagerImpl.checkStateLoss(Unknown Source) at android.support.v4.app.FragmentManagerImpl.popBackStackImmediate(Unknown Source) at android.support.v4.app.FragmentActivity.onBackPressed(Unknown Source) 

Todos fueron causados ​​por checkStateLoss ()

 private void checkStateLoss() { if (mStateSaved) { throw new IllegalStateException( "Can not perform this action after onSaveInstanceState"); } if (mNoTransactionsBecause != null) { throw new IllegalStateException( "Can not perform this action inside of " + mNoTransactionsBecause); } 

mStateSaved será verdadero después de onSaveInstanceState.

Este problema rara vez ocurre. Nunca he encontrado este problema. No puedo volver a encontrar el problema.

He encontrado el problema 25517

Pudo haber ocurrido en las siguientes circunstancias

  1. La tecla Atrás se invoca después de onSaveInstanceState, pero antes de que se inicie la nueva actividad.

  2. use onStop () en el código

No estoy seguro de cuál es la raíz del problema. Entonces usé una manera fea.

 @Override public void onBackPressed() { try{ super.onBackPressed(); }catch (IllegalStateException e){ // can output some information here finish(); } } 

Leer http://chris-alexander.co.uk/on-engineering/dev/android-fragments-within-fragments/

artículo. La comprobación fragment.isResumed () me ayuda en DestroyView sin utilizar el método onSaveInstanceState.

El mismo problema para mí y después de un análisis de un día de todos los artículos, blog y stackoverflow encontré una solución simple. No use savedInstanceState en absoluto, esta es la condición con una línea de código. En el código de fragmento:

 @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(null); ..... 

Esto sucede cada vez que intenta cargar un fragmento, pero la actividad ha cambiado su estado a onPause (). Esto ocurre, por ejemplo, cuando intenta buscar datos y cargarlos en la actividad, pero para cuando el usuario ha hecho clic en algún botón y tiene movido a la siguiente actividad.

Puedes resolver esto de dos maneras

Puede usar transaction.commitAllowingStateLoss () en lugar de transaction.commit () para cargar el fragmento, pero puede terminar perdiendo la operación de confirmación que se realiza.

o

Asegúrese de que la actividad esté en reanudación y no vaya a detener el estado al cargar un fragmento. Cree un booleano y compruebe si la actividad no va al estado onPause ().

 @Override public void onResume() { super.onResume(); mIsResumed = true; } @Override public void onPause() { mIsResumed = false; super.onPause(); } 

luego, al cargar fragmentos verifique si hay actividad presente y cargue solo cuando la actividad esté en primer plano.

 if(mIsResumed){ //load the fragment } 

Bueno, después de probar todas las soluciones anteriores sin éxito (porque básicamente no tengo transacciones).

En mi caso estaba usando AlertDialogs y ProgressDialog como fragmentos que, a veces, en la rotación, cuando se solicita el FragmentManager, el error aumenta.

Encontré una solución alternativa mezclando muchas publicaciones similares:

Es una solución de 3 pasos, todo hecho en tu FragmentActivity (en este caso, se llama GenericActivity):

 private static WeakReference activity = null; //To avoid bug for fragments: Step 1 of 3 @Override protected void onCreate(Bundle savedInstanceState){ super.onCreate(savedInstanceState); //To avoid bug for fragments: Step 2 of 3 activity = new WeakReference(this); } @Override public FragmentManager getSupportFragmentManager(){ //To avoid bug for fragments: Step 3 of 3 if (this == activity.get()) { return super.getSupportFragmentManager(); } return activity.get().getSupportFragmentManager(); } 

Cuando uso la actividad en un fragmento, obtendré esta excepción;

Cuando cambio para usar startactivityforresult, la excepción se ha ido 🙂

Entonces, la manera más fácil de solucionarlo es usar la API startActivityForResult 🙂

Obtuve esta excepción cuando estaba presionando el botón Atrás para cancelar el selector de intenciones en la actividad de fragmento de mi mapa. Resolví esto reemplazando el código de onResume () (donde estaba inicializando el fragmento y confirmando la transacción) por onStart () y la aplicación funciona bien ahora. Espero eso ayude.

Esto se soluciona en Android 4.2 y también en la fuente de la biblioteca de soporte. [*]

Para obtener más información sobre la causa (y las soluciones), consulte el informe de errores de Google: http://code.google.com/p/android/issues/detail?id=19917.

Si está utilizando la biblioteca de soporte, entonces no debería tener que preocuparse por este error (por mucho tiempo) [*]. Sin embargo, si está utilizando la API directamente (es decir, sin utilizar el FragmentManager de la biblioteca de soporte) y apuntando a una API por debajo de Android 4.2, entonces deberá probar uno de los métodos alternativos.

[*] En el momento de redactar este documento, el Administrador de Android SDK sigue distribuyendo una versión anterior que muestra este error.

Editar Voy a agregar algunas aclaraciones aquí porque, de alguna manera, he confundido a quien votó negativamente esta respuesta.

Hay varias circunstancias diferentes (pero relacionadas) que pueden provocar el lanzamiento de esta excepción . Mi respuesta anterior se refiere a la instancia específica discutida en la pregunta, es decir, un error en Android que posteriormente se ha solucionado. Si obtiene esta excepción por otro motivo, es porque está agregando / eliminando fragmentos cuando no debería (después de guardar los estados de los fragmentos). Si se encuentra en una situación así, tal vez ” Fragmentos nesteds – IllegalStateException” No se puede realizar esta acción después de onSaveInstanceState ” ” puede ser útil para usted.

Después de investigar un poco la solución a este problema es hacer tus commits de fragmentos en el resumen.

Fuente: https://wenchaojames.wordpress.com/2013/01/12/illegalstateexception-from-onactivityresult/

Mi caso de uso: utilicé el oyente en fragmentos para notificar a la actividad que sucedió algo. Hice una nueva confirmación de fragmento en el método de callback. Esto funciona perfectamente bien en la primera vez. Pero en el cambio de orientación, la actividad se recrea con el estado de instancia guardado. En ese caso, el fragmento no se crea de nuevo implica que el fragmento tiene el oyente, que es una actividad antigua destruida. De cualquier forma, el método de callback se activará en la acción. Va a la actividad destruida que causa el problema. La solución es restablecer el oyente en fragmento con la actividad actual en vivo. Esto resuelve el problema.

Lo que encontré es que si otra aplicación es de tipo de diálogo y permite que se envíen toques a la aplicación de fondo, casi cualquier aplicación de fondo se bloqueará con este error. Creo que debemos verificar cada vez que se realiza una transacción si la instancia se guardó o restauró.

En mi caso, con la misma excepción de error, puse el “onBackPressed ()” en un ejecutable (puede usar cualquiera de su vista):

 myView.post(new Runnable() { @Override public void run() { onBackPressed() } }); 

No entiendo por qué, pero funciona!

Puede estar llamando a fragmentManager.popBackStackImmediate (); cuando la actividad está en pausa La actividad no ha finalizado, pero está en pausa y no en primer plano. Debe verificar si la actividad está pausada o no antes de popBackStackImmediate ().

Gracias @gunar, pero creo que hay una mejor manera.

De acuerdo con el documento:

  * If you are committing a single transaction that does not modify the * fragment back stack, strongly consider using * {@link FragmentTransaction#commitNow()} instead. This can help avoid * unwanted side effects when other code in your app has pending committed * transactions that expect different timing. * * @return Returns true if there were any pending transactions to be * executed. */ public abstract boolean executePendingTransactions(); 

Entonces use commitNow para reemplazar:

 fragmentTransaction.commit(); FragmentManager.executePendingTransactions() 

Noté algo muy interesante. Tengo en mi aplicación la opción de abrir la galería del teléfono y el dispositivo pregunta qué aplicación usar, allí hago clic en el área gris fuera del diálogo y veo este problema. Observé cómo mi actividad pasa de onPause, onSaveInstanceState a onResume, no sucede que visite onCreateView. Estoy haciendo transacciones en onResume. Entonces, lo que terminé haciendo es establecer una bandera que se niega onPause, pero siendo verdadera en CreateView. si la bandera es verdadera en Reenume, entonces haz onCommit, de lo contrario commitAllowingStateLoss. Podría seguir y perder mucho tiempo, pero quería verificar el ciclo de vida. Tengo un dispositivo que es sdkversion 23, y no entiendo este problema, pero tengo otro que es 21, y allí lo veo.

puede usar FragmentActivity.onStart antes de popBackStackImmediate

Me gusta esto:

 public void backStackFragment() { this.start(); getFragmentManager().popBackStackImmediate(); } public void start(){ FragmentActivity a = getActivity(); if(a instanceof DepositPlanPadActivity){ ((DepositPlanPadActivity)a).onStart(); } if(a instanceof SmallChangePlanPad){ ((SmallChangePlanPad)a).onStart(); } if(a instanceof UserCenterActivity){ ((UserCenterActivity)a).onStart(); } } 

http://jorryliu.blogspot.com/2014/09/illegalstateexception-can-not-perform.html