If I understand correctly you mean : Is there any reason NOT to indiscriminately do this without re-evaluating each individual case where I use a fragment?
The answer is Yes – you should not do this without carefully re-evaluating each individual case where you use a fragment.
Of course, by preventing restarts due to config changes (screen rotations) you have eliminated one of the key problem areas : i.e. the user could rotate the screen AFTER a call to onSaveInstanceState but BEFORE the commitAllowingStateLoss. In this case a fragment or portion of UI might be lost. For an informal discussion of this, see this post.
But there are other situations you should consider before replacing commit by commitAllowingStateLoss.
-
Basically, any UI updates between onSaveInstanceState and the commitAllowingStateLoss:
Android: IllegalStateException – When is it thrown? -
If you have any headless fragments that update the UI of your activity then some of their updates might be lost (see this article).
-
Android might “kill” a fragment because the phone/tab is running low on resources (see this answer).
Of course, if screen rotations are prevented, then onSaveInstanceState may not be called, in which case the window of opportunity for an update to be lost is increased.
If you do decide to use commitAllowingStateLoss then are things you can do to minimize the risks involved: e.g. consider doing a commit / executePendingTransactions when the parent activity is next restarted (I know you don’t want to do this, but someone else might read this).
Finally (again in case someone else reads this – this is not relevant in your case) there are probably safer ways of handling an IllegalStateException than moving from commit to commitAllowStateLoss. e.g you could just stick with commit and handle the IllegalStateException. Alternatively, you may have hit a bug in Android and there might be a workaround.