Answering the core question: how can you recreate an ActionMode after a back press:
You can postDelayed a Runnable to a Handler to recreate an ActionMode. The delay needed can vary a little between devices, I've found 200ms to work with everything I've tried. In an Activity or FragmentActivity try these snippets:
RepeatActionModeRunnable mRepeatActionModeRunnable;
Handler mHandler = new Handler();
@Override
protected void onPause() {
mHandler.removeCallbacks(mRepeatActionModeRunnable);
super.onPause();
}
private class RepeatActionModeRunnable implements Runnable {
ActionMode.Callback mRepeatActionMode;
public RepeatActionModeRunnable(ActionMode.Callback actionMode) {
mRepeatActionMode = actionMode;
}
@Override
public void run() {
mActionMode = startActionMode(mRepeatActionMode);
}
}
Then in onDestroyActionMode you can use this when you need to (i.e. you'll no doubt want some logic wrapping this to detect if it should or shouldn't be recreated):
mHandler.removeCallbacks(mRepeatActionModeRunnable);
mRepeatActionModeRunnable = new RepeatActionModeRunnable(new SomeActionMode());
mHandler.postDelayed(mRepeatActionModeRunnable, 200);
As for whether CAB is or isn't to be used for forms/data input, such situations are well suited to a "call for action" and that is also the reason d'etre for the ActionMode pattern. The existence of hurdles/nuances/bugs such as recreating after back button press and if a user selects text to edit should not constitute rationale for it to not be OK to use, rather for it to be seen as perhaps not the path of least resistance in terms of a solution (it's a challenge!). The existence of the 'Done & Discard' pattern alone also shouldn't constitute rationale for not using ActionMode for situations involving data input. These are all possibilities that may suit your situation better or worse rather than a right or wrong way.
PS: regarding how to deal with TextSelectionCAB, here's a solution: Detect ActionMode nesting