IllegalStateException: невозможно выполнить это действие после onSaveInstanceState с ViewPager

Пожалуйста, проверьте мой ответ здесь. В основном мне просто нужно было:

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

Не обращайтесь к super() по методу saveInstanceState. Это напутало ...

Это известная ошибка в пакете поддержки.

Если вам нужно сохранить экземпляр и добавить что-то в свой outState Bundle, вы можете использовать следующее:

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

В конце концов, правильным решением было (как видно из комментариев) использовать:

transaction.commitAllowingStateLoss();

при добавлении или выполнении FragmentTransaction, вызвавшего Exception.

Подобное сообщение об ошибке связано с множеством проблем. Проверьте вторую строку этой конкретной трассировки стека. Это исключение конкретно связано с вызовом FragmentManagerImpl.popBackStackImmediate.

Этот вызов метода, как и popBackStack, всегда завершается ошибкой с IllegalStateException, если состояние сеанса уже было сохранено. Проверить источник. Вы ничего не можете сделать, чтобы остановить возникновение этого исключения.

• Удаление вызова super.onSaveInstanceState не поможет.
• Создание фрагмента с commitAllowingStateLoss не поможет.

Вот как я заметил проблему:

• Есть форма с кнопкой отправки.
• При нажатии кнопки создается диалоговое окно и запускается асинхронный процесс.
• Пользователь нажимает кнопку «Домой» до завершения процесса - вызывается onSaveInstanceState.
• Процесс завершается, выполняется обратный вызов и предпринимается попытка popBackStackImmediate.
• IllegalStateException брошено.

Вот что я сделал, чтобы решить эту проблему:

Поскольку невозможно избежать IllegalStateException в обратном вызове, поймайте и игнорируйте его.

try {
    activity.getSupportFragmentManager().popBackStackImmediate(name);
} catch (IllegalStateException ignored) {
    // There's no way to avoid getting this if saveInstanceState has already been called.
}

Этого достаточно, чтобы приложение не вылетало. Но теперь пользователь восстановит приложение и увидит, что кнопка, которую, как он думал, нажала, вообще не была нажата (они думают). Фрагмент формы все еще отображается!

Чтобы исправить это, при создании диалогового окна установите какое-либо состояние, чтобы указать, что процесс запущен.

progressDialog.show(fragmentManager, TAG);
submitPressed = true;

И сохраните это состояние в связке.

@Override
public void onSaveInstanceState(Bundle outState) {
    ...
    outState.putBoolean(SUBMIT_PRESSED, submitPressed);
}

Не забудьте снова загрузить его в onViewCreated

Затем, при возобновлении, откатите фрагменты, если ранее была предпринята попытка отправки. Это не позволяет пользователю вернуться к тому, что кажется неотправленной формой.

@Override
public void onResume() {
    super.onResume();
    if (submitPressed) {
        // no need to try-catch this, because we are not in a callback
        activity.getSupportFragmentManager().popBackStackImmediate(name);
        submitPressed = false;
    }
}

Убедитесь, что активность isFinishing() перед показом фрагмента, и обратите внимание на commitAllowingStateLoss().

Пример:

if(!isFinishing()) {
FragmentManager fm = getSupportFragmentManager();
            FragmentTransaction ft = fm.beginTransaction();
            DummyFragment dummyFragment = DummyFragment.newInstance();
            ft.add(R.id.dummy_fragment_layout, dummyFragment);
            ft.commitAllowingStateLoss();
}

На дворе октябрь 2017 года, и Google создает библиотеку поддержки Android с новым компонентом Lifecycle. Он предлагает новую идею для проблемы «Невозможно выполнить это действие после onSaveInstanceState».

Короче:

• Используйте компонент жизненного цикла, чтобы определить, подходящее ли время для всплывающего окна вашего фрагмента.

Расширенная версия с объяснением:

• почему эта проблема вышла?

  Это потому, что вы пытаетесь использовать FragmentManager из своей активности (которая, я полагаю, будет содержать ваш фрагмент?), Чтобы совершить транзакцию для вашего фрагмента. Обычно это выглядит так, как будто вы пытаетесь выполнить какую-то транзакцию для предстоящего фрагмента, в то время как активность хоста уже вызывает метод savedInstanceState (пользователь может случайно коснуться кнопки домой, поэтому действие вызывает onStop(), в моем случае это причина)

  Обычно такой проблемы не должно происходить - мы всегда пытаемся загрузить фрагмент в действие в самом начале, например, метод onCreate() - идеальное место для этого. Но иногда это действительно происходит, особенно когда вы не можете решить, какой фрагмент загрузить в это действие, или вы пытаетесь загрузить фрагмент из AsyncTask блока (или что-то еще займет немного времени). Время до того, как транзакция фрагмента действительно произойдет, но после метода onCreate() действия пользователь может делать что угодно. Если пользователь нажмет кнопку «Домой», которая запускает onSavedInstanceState() метод действия, произойдет can not perform this action сбой.

  Если кто-то хочет глубже разобраться в этой проблеме, я предлагаю им взглянуть на этот блог сообщение. Он заглядывает глубоко внутрь слоя исходного кода и многое объясняет. Кроме того, это объясняет, почему вы не должны использовать метод commitAllowingStateLoss() для обхода этого сбоя (поверьте мне, он не предлагает ничего хорошего для вашего кода)

• Как это исправить?

  • Следует ли использовать метод commitAllowingStateLoss() для загрузки фрагмента? Нет, не стоит;

  • Должен ли я переопределить onSaveInstanceState метод, игнорировать super метод внутри него? Нет, не стоит;

  • Должен ли я использовать волшебную isFinishing внутреннюю активность, чтобы проверить, является ли активность хоста подходящей для транзакции фрагмента? Да, это похоже верный способ.

• Посмотрите, что может делать компонент Lifecycle.

  По сути, Google выполняет некоторую реализацию внутри класса AppCompatActivity (и нескольких других базовых классов, которые вы должны использовать в своем проекте), что упрощает определение текущего состояния жизненного цикла. Вернемся к нашей проблеме: почему эта проблема возникла? Это потому, что мы делаем что-то не вовремя. Поэтому мы стараемся этого не делать, и эта проблема исчезнет.

  Я немного кодирую для своего собственного проекта, вот что я делаю с помощью LifeCycle. Я кодирую на Котлине.

val hostActivity: AppCompatActivity? = null // the activity to host fragments. It's value should be properly initialized.

fun dispatchFragment(frag: Fragment) {
    hostActivity?.let {
       if(it.lifecyclecurrentState.isAtLeast(Lifecycle.State.RESUMED)){
           showFragment(frag)
       }
    }
}

private fun showFragment(frag: Fragment) {
    hostActivity?.let {
        Transaction.begin(it, R.id.frag_container)
                .show(frag)
                .commit()
    }

Как я показал выше. Я проверю состояние жизненного цикла активности хоста. С компонентом жизненного цикла в библиотеке поддержки это могло бы быть более конкретным. Код lifecyclecurrentState.isAtLeast(Lifecycle.State.RESUMED) означает, что если текущее состояние хотя бы onResume, не позже этого? Это гарантирует, что мой метод не будет выполняться в каком-то другом жизненном состоянии (например, onStop).

• Все ли сделано?

  Конечно, нет. Код, который я показал, говорит о новом способе предотвращения сбоев приложения. Но если он перейдет в состояние onStop, эта строка кода ничего не сделает и, следовательно, ничего не покажет на вашем экране. Когда пользователи вернутся в приложение, они увидят пустой экран, это пустая активность хоста, на которой вообще нет фрагментов. Это плохой опыт (да, немного лучше, чем авария).

  Итак, я хотел бы, чтобы было что-то более приятное: приложение не выйдет из строя, если оно перейдет в жизненное состояние позже onResume, метод транзакции учитывает жизненное состояние; кроме того, действие будет пытаться продолжить выполнение этого действия транзакции фрагмента после того, как пользователь вернется в наше приложение.

  Я добавляю к этому методу еще кое-что:

class FragmentDispatcher(_host: FragmentActivity) : LifecycleObserver {
    private val hostActivity: FragmentActivity? = _host
    private val lifeCycle: Lifecycle? = _host.lifecycle
    private val profilePendingList = mutableListOf<BaseFragment>()

    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun resume() {
        if (profilePendingList.isNotEmpty()) {
            showFragment(profilePendingList.last())
        }
    }

    fun dispatcherFragment(frag: BaseFragment) {
        if (lifeCycle?.currentState?.isAtLeast(Lifecycle.State.RESUMED) == true) {
            showFragment(frag)
        } else {
            profilePendingList.clear()
            profilePendingList.add(frag)
        }
    }

    private fun showFragment(frag: BaseFragment) {
        hostActivity?.let {
            Transaction.begin(it, R.id.frag_container)
                    .show(frag)
                    .commit()
        }
    }
}

Я веду список внутри этого класса dispatcher, чтобы сохранить этот фрагмент, у меня нет возможности завершить действие транзакции. И когда пользователь вернется с домашнего экрана и обнаружит, что фрагмент все еще ожидает запуска, он перейдет к методу resume() под аннотацией @OnLifecycleEvent(Lifecycle.Event.ON_RESUME). Теперь я думаю, что все должно работать так, как я ожидал.

Вот другое решение этой проблемы.

Используя частную переменную-член, вы можете установить возвращаемые данные как намерение, которое затем может быть обработано после super.onResume ();

Вот так:

private Intent mOnActivityResultIntent = null; 

@Override
protected void onResume() {
    super.onResume();
    if(mOnActivityResultIntent != null){
        ... do things ...
        mOnActivityResultIntent = null;
    }
 }

@Override
public void onActivityResult(int requestCode, int resultCode, Intent data){
    if(data != null){
        mOnActivityResultIntent = data;
    }
}

Краткое и рабочее решение:

Следуйте простым шагам

Шаги

Шаг 1: Заменить состояние onSaveInstanceState в соответствующем фрагменте. И убрать из него супер метод.

 @Override
public void onSaveInstanceState( Bundle outState ) {

}  

Шаг 2. Используйте fragmentTransaction.commitAllowingStateLoss( );

вместо fragmentTransaction.commit( ); при операциях с фрагментами.

ОСТОРОЖНО, использование transaction.commitAllowingStateLoss() может ухудшить восприятие пользователем. Для получения дополнительной информации о том, почему возникает это исключение, см. этот пост.

Я нашел грязное решение для такого рода проблем. Если вы по-прежнему хотите сохранить свой ActivityGroups по какой-либо причине (у меня были ограничения по времени), вы просто реализуете

public void onBackPressed() {}

в вашем Activity и напишите там back код. даже если такого метода нет на старых устройствах, этот метод вызывается новыми.

Не используйте commitAllowingStateLoss (), его следует использовать только в тех случаях, когда состояние пользовательского интерфейса может неожиданно измениться для пользователя.

https://developer.android.com/reference/android/app/FragmentTransaction.html#commitAllowingStateLoss()

Если транзакция происходит в ChildFragmentManager из parentFragment, используйте для проверки снаружи parentFragment.isResume ().

if (parentFragment.isResume()) {
    DummyFragment dummyFragment = DummyFragment.newInstance();
    transaction = childFragmentManager.BeginTransaction();
    trans.Replace(Resource.Id.fragmentContainer, startFragment);
}

У меня была аналогичная проблема, сценарий был такой:

• Моя деятельность - добавление / замена фрагментов списка.
• Каждый фрагмент списка имеет ссылку на действие, чтобы уведомить действие при щелчке по элементу списка (шаблон наблюдателя).
• Каждый фрагмент списка вызывает setRetainInstance (true); в своем методе onCreate.

Метод onCreate для действия был таким:

mMainFragment = (SelectionFragment) getSupportFragmentManager()
                .findFragmentByTag(MAIN_FRAGMENT_TAG);
        if (mMainFragment == null) {
            mMainFragment = new SelectionFragment();

            mMainFragment.setListAdapter(new ArrayAdapter<String>(this,
                    R.layout.item_main_menu, getResources().getStringArray(
                            R.array.main_menu)));
mMainFragment.setOnSelectionChangedListener(this);
            FragmentTransaction transaction = getSupportFragmentManager()
                    .beginTransaction();
            transaction.add(R.id.content, mMainFragment, MAIN_FRAGMENT_TAG);
            transaction.commit();
        }

Возникло исключение, потому что при изменении конфигурации (ротации устройства) создается действие, основной фрагмент извлекается из истории диспетчера фрагментов, и в то же время фрагмент уже имеет ссылку OLD. к уничтоженному действию

изменение реализации на это решило проблему:

mMainFragment = (SelectionFragment) getSupportFragmentManager()
                .findFragmentByTag(MAIN_FRAGMENT_TAG);
        if (mMainFragment == null) {
            mMainFragment = new SelectionFragment();

            mMainFragment.setListAdapter(new ArrayAdapter<String>(this,
                    R.layout.item_main_menu, getResources().getStringArray(
                            R.array.main_menu)));
            FragmentTransaction transaction = getSupportFragmentManager()
                    .beginTransaction();
            transaction.add(R.id.content, mMainFragment, MAIN_FRAGMENT_TAG);
            transaction.commit();
        }
        mMainFragment.setOnSelectionChangedListener(this);

вам необходимо настраивать слушателей каждый раз при создании действия, чтобы избежать ситуации, когда фрагменты содержат ссылки на старые уничтоженные экземпляры действия.

Если вы наследуете от FragmentActivity, вы должны вызвать суперкласс в onActivityResult():

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent intent) {
    super.onActivityResult(requestCode, resultCode, intent);
    ...
}

Если вы этого не сделаете и попытаетесь показать диалоговое окно фрагмента в этом методе, вы можете получить OP IllegalStateException. (Честно говоря, я не совсем понимаю, почему супервызов устраняет проблему. onActivityResult() вызывается перед onResume(), поэтому ему все равно не должно быть разрешено показывать диалоговое окно фрагмента.)

Я получал это исключение, когда нажимал кнопку «Назад», чтобы отменить средство выбора намерений на моей активности фрагмента карты. Я решил эту проблему, заменив код onResume (где я инициализировал фрагмент) на onstart (), и приложение работает нормально. Надеюсь, это поможет.

Возможно, самое плавное и простое решение, которое я нашел в моем случае, заключалось в том, чтобы избежать выталкивания проблемного фрагмента из стека в ответ на результат активности. Итак, изменив этот вызов в моем onActivityResult():

popMyFragmentAndMoveOn();

к этому:

new Handler(Looper.getMainLooper()).post(new Runnable() {
    public void run() {
        popMyFragmentAndMoveOn();
    }
}

помог в моем случае.

Я думаю, что использование transaction.commitAllowingStateLoss(); - не лучшее решение. Это исключение будет выдано, когда конфигурация действия изменится и будет вызван фрагмент onSavedInstanceState(), и после этого ваш асинхронный метод обратного вызова попытается зафиксировать фрагмент.

Простым решением может быть проверка, изменяет ли активность конфигурацию или нет.

например проверить isChangingConfigurations()

i.e.

if(!isChangingConfigurations()) { //commit transaction. }

Оформить заказ также по этой ссылке.

Всякий раз, когда вы пытаетесь загрузить фрагмент в своей деятельности, убедитесь, что активность возобновлена ​​и не собирается приостанавливаться. В состоянии паузы вы можете потерять выполненную операцию фиксации.

Вы можете использовать transaction.commitAllowingStateLoss () вместо transaction.commit () для загрузки фрагмента.

or

Создайте логическое значение и проверьте, не будет ли активность приостанавливаться

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

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

затем при загрузке проверки фрагмента

if(mIsResumed){
//load the your fragment
}

Если вы выполняете FragmentTransaction в onActivityResult, что вы можете сделать, вы можете установить какое-то логическое значение внутри onActivityResult, тогда в onResume вы можете выполнить свою FragmentTransaction на основе логического значения. Пожалуйста, обратитесь к приведенному ниже коду.

@Override
protected void onResume() {
    super.onResume;
    if(isSwitchFragment){
        isSwitchFragment=false;
        bottomNavigationView.getTabAt(POS_FEED).select();
    }
}

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
    if (requestCode == FilterActivity.FILTER_REQUEST_EVENT && data != null) {
        isSwitchFragment=true;
    }
}

Предоставлено: Решение для исключения IllegalStateException

Эта проблема раздражала меня долгое время, но, к счастью, я нашел для нее конкретное решение. Подробное объяснение этого здесь..

Использование commitAllowStateloss () может предотвратить это исключение, но приведет к сбоям в пользовательском интерфейсе. До сих пор мы понимали, что IllegalStateException встречается, когда мы пытаемся зафиксировать фрагмент после потери состояния Activity, поэтому мы должны просто отложить транзакцию до восстановления состояния . Это можно просто сделать так

Объявить две приватные логические переменные

 public class MainActivity extends AppCompatActivity {

    //Boolean variable to mark if the transaction is safe
    private boolean isTransactionSafe;

    //Boolean variable to mark if there is any transaction pending
    private boolean isTransactionPending;

Теперь в onPostResume () и onPause мы устанавливаем и отключаем нашу логическую переменную isTransactionSafe. Идея состоит в том, чтобы пометить транзакцию как безопасную только тогда, когда действие находится на переднем плане, чтобы не было возможности потери состояния.

/*
onPostResume is called only when the activity's state is completely restored. In this we will
set our boolean variable to true. Indicating that transaction is safe now
 */
public void onPostResume(){
    super.onPostResume();
    isTransactionSafe=true;
}
/*
onPause is called just before the activity moves to background and also before onSaveInstanceState. In this
we will mark the transaction as unsafe
 */

public void onPause(){
    super.onPause();
    isTransactionSafe=false;

}

private void commitFragment(){
    if(isTransactionSafe) {
        MyFragment myFragment = new MyFragment();
        FragmentManager fragmentManager = getFragmentManager();
        FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();
        fragmentTransaction.add(R.id.frame, myFragment);
        fragmentTransaction.commit();
    }
}

-То, что мы сделали до сих пор, спасет от IllegalStateException, но наши транзакции будут потеряны, если они будут выполнены после того, как действие перейдет в фоновый режим, вроде commitAllowStateloss (). Чтобы помочь с этим, у нас есть логическая переменная isTransactionPending

public void onPostResume(){
   super.onPostResume();
   isTransactionSafe=true;
/* Here after the activity is restored we check if there is any transaction pending from
the last restoration
*/
   if (isTransactionPending) {
      commitFragment();
   }
}


private void commitFragment(){

 if(isTransactionSafe) {
     MyFragment myFragment = new MyFragment();
     FragmentManager fragmentManager = getFragmentManager();
     FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();
     fragmentTransaction.add(R.id.frame, myFragment);
     fragmentTransaction.commit();
     isTransactionPending=false;
 }else {
     /*
     If any transaction is not done because the activity is in background. We set the
     isTransactionPending variable to true so that we can pick this up when we come back to
foreground
     */
     isTransactionPending=true;
 }
}

Что касается отличного ответа @Anthonyeef, вот пример кода на Java:

private boolean shouldShowFragmentInOnResume;

private void someMethodThatShowsTheFragment() {

    if (this.getLifecycle().getCurrentState().isAtLeast(Lifecycle.State.RESUMED)) {
        showFragment();
    } else {
        shouldShowFragmentInOnResume = true;
    }
}

private void showFragment() {
    //Your code here
}

@Override
protected void onResume() {
    super.onResume();

    if (shouldShowFragmentInOnResume) {
        shouldShowFragmentInOnResume = false;
        showFragment();
    }
}

Исключение выбрасывается здесь (в FragmentActivity):

@Override
public void onBackPressed() {
    if (!mFragments.getSupportFragmentManager().popBackStackImmediate()) {
        super.onBackPressed();
    }
}

В _2 _ ， _ 3_ вызывается в первую очередь. Это причина IllegalStateException. См. Реализацию ниже:

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

Я решаю эту проблему, просто используя флаг, чтобы отметить текущий статус Activity. Вот мое решение:

public class MainActivity extends AppCompatActivity {
    /**
     * A flag that marks whether current Activity has saved its instance state
     */
    private boolean mHasSaveInstanceState;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }

    @Override
    protected void onSaveInstanceState(Bundle outState) {
        mHasSaveInstanceState = true;
        super.onSaveInstanceState(outState);
    }

    @Override
    protected void onResume() {
        super.onResume();
        mHasSaveInstanceState = false;
    }

    @Override
    public void onBackPressed() {
        if (!mHasSaveInstanceState) {
            // avoid FragmentManager.checkStateLoss()'s throwing IllegalStateException
            super.onBackPressed();
        }
    }
}

Если у вас произошел сбой при использовании метода popBackStack () или popBackStackImmediate (), попробуйте исправить это с помощью:

        if (!fragmentManager.isStateSaved()) {
            fragmentManager.popBackStackImmediate();
        }

Это сработало и для меня.

В моем случае я получил эту ошибку в методе переопределения onActivityResult. Покопавшись, я понял, что, может быть, мне нужно было раньше называть "super".
Я добавил это, и это сработало

override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {
    super.onActivityResult(requestCode, resultCode, data); //<--- THIS IS THE SUPPER CALL
    if (resultCode == Activity.RESULT_OK && requestCode == 0) {
        mostrarFragment(FiltroFragment.newInstance())
    }

}

Возможно, вам просто нужно добавить «супер» к любому переопределению, которое вы делаете перед своим кодом.

Фрагментные транзакции не должны выполняться после Activity.onStop()! Убедитесь, что у вас нет обратных вызовов, которые могли бы выполнить транзакцию после onStop(). Лучше устранить причину, чем пытаться обходить проблему подходами типа .commitAllowingStateLoss()

Начиная с версии библиотеки поддержки 24.0.0, вы можете вызывать метод FragmentTransaction.commitNow(), который синхронно фиксирует эту транзакцию, вместо вызова commit(), за которым следует executePendingTransactions(). Как говорится в документации, этот подход даже лучше :

Вызов commitNow предпочтительнее, чем вызов commit (), за которым следует executePendingTransactions (), поскольку у последнего будет побочный эффект попытки зафиксировать все текущие ожидающие транзакции, независимо от того, является ли это желаемым поведением или нет.

Я знаю, что есть принятый ответ от @Ovidiu Latcu, но через некоторое время ошибка все еще сохраняется.

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

Crashlytics все еще присылает мне это странное сообщение об ошибке.

Однако ошибка теперь возникает только в версии 7+ (Nougat). Мое исправление заключалось в использовании commitAllowingStateLoss () вместо commit () в fragmentTransaction.

Этот пост полезен для commitAllowingStateLoss () и никогда больше не сталкивался с проблемой фрагмента .

Подводя итог, принятый здесь ответ может работать на версиях Android до Nougat.

Это может сэкономить кому-то несколько часов поиска. счастливые кодировки. ‹3 ура

Чтобы обойти эту проблему, мы можем использовать компонент архитектуры навигации, который был представлен в Google I / O 2018. Компонент архитектуры навигации упрощает реализацию навигации в приложении Android.

Расширение Kotlin

fun FragmentManager?.replaceAndAddToBackStack(
    @IdRes containerViewId: Int,
    fragment: () -> Fragment,
    tag: String
) {
    // Find and synchronously remove a fragment with the same tag.
    // The second transaction must start after the first has finished.
    this?.findFragmentByTag(tag)?.let {
        beginTransaction().remove(it).commitNow()
    }
    // Add a fragment.
    this?.beginTransaction()?.run {
        replace(containerViewId, fragment, tag)
        // The next line will add the fragment to a back stack.
        // Remove if not needed.
        // You can use null instead of tag, but tag is needed for popBackStack(), 
        // see https://stackoverflow.com/a/59158254/2914140
        addToBackStack(tag)
    }?.commitAllowingStateLoss()
}

Использование:

val fragment = { SomeFragment.newInstance(data) }
fragmentManager?.replaceAndAddToBackStack(R.id.container, fragment, SomeFragment.TAG)

Добавьте это в свою деятельность

@Override
public void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
    if (outState.isEmpty()) {
        // Work-around for a pre-Android 4.2 bug
        outState.putBoolean("bug:fix", true);
    }
}

Я также столкнулся с этой проблемой, и проблема возникает каждый раз, когда изменяется контекст вашего FragmentActivity (например, изменяется ориентация экрана и т. Д.). Поэтому лучшее решение - обновить контекст из вашего FragmentActivity.

В итоге я создал базовый фрагмент и заставил все фрагменты в моем приложении расширить его.

public class BaseFragment extends Fragment {

    private boolean mStateSaved;

    @CallSuper
    @Override
    public void onSaveInstanceState(Bundle outState) {
        mStateSaved = true;
        super.onSaveInstanceState(outState);
    }

    /**
     * Version of {@link #show(FragmentManager, String)} that no-ops when an IllegalStateException
     * would otherwise occur.
     */
    public void showAllowingStateLoss(FragmentManager manager, String tag) {
        // API 26 added this convenient method
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            if (manager.isStateSaved()) {
                return;
            }
        }

        if (mStateSaved) {
            return;
        }

        show(manager, tag);
    }
}

Затем, когда я пытаюсь показать фрагмент, я использую showAllowingStateLoss вместо show

нравится:

MyFragment.newInstance()
.showAllowingStateLoss(getFragmentManager(), MY_FRAGMENT.TAG);

Я пришел к этому решению из этого PR: https://github.com/googlesamples/easypermissions/pull/170/files

Другой возможный обходной путь, который я не уверен, помогает ли он во всех случаях (источник здесь < / strong>):

@Override
protected void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
        final View rootView = findViewById(android.R.id.content);
        if (rootView != null) {
            rootView.cancelPendingInputEvents();
        }
    }
}