java.lang.IllegalStateException Can not perform this action after onSaveInstanceState
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
The IllegalStateException: Can not perform this action after onSaveInstanceState is one of the most common crashes in Android development. It occurs when you try to commit a FragmentTransaction after the activity has saved its state (after onSaveInstanceState() has been called). At that point, the system has already captured a snapshot of the UI state, and committing a fragment transaction would create a state that the system cannot restore if the process is killed. The fix depends on the situation: use commitAllowingStateLoss(), check isStateSaved(), or restructure the code to avoid late commits.
When the Error Occurs
The activity lifecycle leading to this crash:
Common triggers include:
- Async callbacks (network responses, timer callbacks) that arrive after the user navigated away
onActivityResult()in older Android versions (pre-API 26) being called beforeonResume()- Background service or broadcast receiver triggering a fragment transaction
Fix 1: commitAllowingStateLoss()
commitAllowingStateLoss() suppresses the exception by accepting that the transaction might be lost if the process is killed and restored. Use this when the transaction is not critical to the user's saved state.
Fix 2: Check isStateSaved() Before Committing
isStateSaved() returns true after onSaveInstanceState() and false after onResume(). This lets you defer the transaction to when it is safe.
Fix 3: Move Logic to onPostResume() or onResumeFragments()
onPostResume() is called after onResume() and after fragment state has been restored, making it safe for fragment transactions.
Fix 4: Use Lifecycle-Aware Components
LiveData only delivers values when the observer (Activity/Fragment) is in an active lifecycle state (STARTED or RESUMED), avoiding the state-loss problem entirely.
Fix 5: DialogFragment.showAllowingStateLoss()
For DialogFragment, there is no built-in showAllowingStateLoss(), but you can create one:
Or as an extension function in Kotlin:
Understanding the Activity Lifecycle
Common Pitfalls
- Using
commit()in async callbacks without lifecycle checks: Network responses, timers, and broadcast receivers can fire at any time. If the callback arrives afteronSaveInstanceState(),commit()crashes. Always checkisStateSaved()or usecommitAllowingStateLoss()in async contexts. - Assuming
onActivityResult()is safe for fragment transactions: On API levels before 26,onActivityResult()is called beforeonResume(), meaning the fragment state has not been restored yet. Defer fragment transactions toonPostResume()oronResumeFragments(). - Overusing
commitAllowingStateLoss(): While it prevents the crash, it means the fragment transaction may be silently lost if the system kills and restores the process. Only use it for non-critical UI updates (toasts, temporary dialogs) that the user does not need to see after returning. - Not handling configuration changes: Rotating the device calls
onSaveInstanceState()followed byonDestroy()andonCreate(). Async callbacks that reference the old activity instance will crash. UseViewModelandLiveDatato survive configuration changes. - Calling
dismiss()on aDialogFragmentafter state loss:dismiss()internally commits a fragment transaction and can also throwIllegalStateException. UsedismissAllowingStateLoss()in async contexts.
Summary
- The crash occurs when committing fragment transactions after
onSaveInstanceState()— the system cannot restore UI state that was modified after the snapshot - Use
commitAllowingStateLoss()for non-critical transactions that can be safely lost - Check
isStateSaved()to conditionally defer transactions to a safe lifecycle callback - Use
onPostResume()oronResumeFragments()for transactions triggered byonActivityResult() - Prefer
LiveDataandViewModelfor modern apps —LiveDataonly delivers events in active lifecycle states - Never commit fragment transactions in async callbacks without lifecycle awareness

