[Android] Save back handling state in Activity/Fragment bundle

[gmackall]

Fixes flutter/flutter#159158, and fixes b/355556397

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[justinmc]

LGTM from my side 👍 . This would have taken me quite a long time to figure out on my own so thank you!

So this is unrelated to predictive back being unsupported on FlutterFragmentActivity?

[gmackall]

LGTM from my side 👍 . This would have taken me quite a long time to figure out on my own so thank you!

So this is unrelated to predictive back being unsupported on FlutterFragmentActivity?

Yes, that is correct. Though from what I can tell, predictive back when leaving the app seems to work with a FlutterFragmentActivity? I plan to do more testing, but I encountered the same behavior you described here when I initially tried it
flutter/flutter#149753 (comment)

Separately, I noticed that #52302 seems to have unintentionally had the effect of not allowing people to "opt out" of predictive back. This is actually aligned with what the android docs say should happen:
https://developer.android.com/guide/navigation/custom-back/predictive-back-gesture

Note: OnBackPressedCallback is always called regardless of the value of android:enableOnBackInvokedCallback. In other words, disabling the system animation doesn't affect your app's back handling logic if it uses OnBackPressedCallback.

But this wasn't actually true for flutter apps before #52302, because we were not calling super, and FlutterFragmentActivity extends a FragmentActivity which in turn extends a ComponentActivity, which uses the old onBackPressed to invoke the new back handling:

   override fun onBackPressed() {
        onBackPressedDispatcher.onBackPressed()
    }

So while the docs imply that removing the onBackPressed in FlutterFragmentActivity shouldn't have had an effect, that wasn't true because in our case we were consuming the back event and ignoring the warning

  @Override
  @SuppressWarnings("MissingSuperCall")
  public void onBackPressed() {
    flutterFragment.onBackPressed();
  }

What all this means is that apps that aren't opting in to predictive back had their back handling migrated to the new code path automatically, which is part of what happened in b/355556397: the bug this pr fixes affects all of FFA/FA/FF, but they noticed a behavior difference between FlutterActivity and FlutterFragmentActivity because of

1. the bug this pr fixes
2. the fact that FFA uniquely is forced into the new back handling codepath (they would see the same behavior if using FlutterActivity and opting in with android:enableOnBackInvokedCallback=true)

[gmackall]

I also think we may want to restore the ability for people to opt out, so that FlutterActivity and FlutterFragmentActivity have the same behavior wrt the android:enableOnBackInvokedCallback (despite this sort of running counter to what the android docs suggest)
#56565 (still need to find out the best way to write a test that interacts with the xml attribute)
Does that make sense to you?