How will Flutter implement Android 13's predictive back gesture?

[victor-marino]

Use case

According to this page, we should get our apps ready for the new predictive back gesture that will be introduced in Android 13.

However, with just a few weeks to go before the final release, I haven't seen any info on how this will be handled in Flutter apps?

I have tried the simple trick of just adding android:enableOnBackInvokedCallback="true" to my Android Manifest, which does indeed activate the new animation on my Pixel 4 running the Android 13 beta. However, because all the back gestures are now captured by the system rather than Flutter, it completely breaks Flutter's navigation system, as ALL back gestures will now send you back to your phone's home screen, rather than taking you one level up Flutter's navigation tree when appropriate.

Proposal

I'm merely asking for information here, as I've searched extensively but couldn't find anything pertaining Flutter.

Will we have to do anything to adapt our apps? Or will the Flutter team implement this at some point at framework level? If it's the latter, when can we expect this to be added? Android 13 is right around the corner.

I'm assuming this should be handled at framework level, so that Flutter automatically implements this animation when navigating inside's Flutter's own tree, and hands it over to the system when the user is already at the root of the navigation stack (so they can correctly peek at their home screen before completing the gesture).

Eager to get some info on this!

[timsneath]

Thanks so much for filing this issue!

Just to clarify, this is a feature being introduced as part of a multi-year transition to how Android handles back gestures. While it's available to developers for the first time in Android 13 through a Developer Options setting, it's not currently accessible to users and won't be until a future Android release. So while the clock is indeed 'ticking' and we will work on enabling support for this, this is not something that Android 13 app authors need to worry about immediately.

[victor-marino]

Thanks a lot for your quick response! That clears things up for me.

I thought it would be available to regular users from the final release of Android 13 (without the need to flip the developer switch), but if that's not the case it's indeed not something to worry about for now.

[goderbauer]

My current understanding is that for this to work correctly, the framework will have to tell the engine (or android) up front whether it is going to handle the back gesture internally or whether Android should handle it.

@GaryQian I think you've been looking closer at the Android APIs. Does that match your understanding?

@chunhtai Does the Navigator already tell the engine that it can handle back internally? I seem to remember that we had to add this to support back on the web?

[chunhtai]

@goderbauer Currently flutter always tells Android it will handle the pop. If flutter then figure there is nothing else to pop, it then programmatically pop the android activity.

For web, the only thing I am aware is the fake browser entry to capture the backward button. I don't think it can be reuse here.

[goderbauer]

Thanks, so we will likely have to build something new here to tell the engine whether the framework can handle back or not upfront, if my understanding of the new Android API is correct.

[chunhtai]

cc @HansMuller @hangyujin

I am still not sure whether we need to implement the animation. From the screenshot, it looks like this may only apply when popping the entire app. Is there any animation change when popping the in-app page?

[HansMuller]

There is, although support for that is farther out.

[GaryQian]

From looking at the API, it seems that we should always be telling Android that we handle the back gesture. Regardless of whether we implement predictive back or just legacy back on the framework side, we will be doing custom handling of the back gesture via OnBackPressedCallback (which is called by the OnBackPressedDispatcher).

However, we should add logic to let Android know when we run out of pages to pop. At this point, we should unregister the callback, and Android will then handle the next back as exiting the app.

In any case, the opt-in is in build.gradle and needs to be preconfigured. It shouldn't be possible (or necessary) for the app to dynamically inform the build whether to enable or disable predictive backnav if it is not already set before build. We should be able to support this with a combo of Embedding API migration, framework predictive backnav implementation, and unregistering callbacks on final framework pop.

This is from an initial study of the API, I'll do some experimentation to see how it actually handles.

[victor-marino]

Hi all.

Just in case it's of any help, as I had already done some limited testing on my Pixel 4 running the Android 13 beta:

1. Even if I flip the developer switch for the predictive back gesture on my phone, my app won't show the gesture at all unless I have explicitly opted-in in the build.gradle, not even for the final gesture to go back to the homescreen. So unless something is done on Flutter/app side, the gesture will definitely not appear at all.
2. If I opt-in in the build.gradle for my app, I do get the gesture working to back out of my app and into the homescreen. Bad news is, now EVERY back gesture takes me out of my app, even if there are still pages left to pop inside my Flutter app. I assume now every back gesture is being handled by the OS, so it just breaks Flutter's internal navigation.

So I think everything GaryQian said matches with my experience.

[stuartmorgan]

2. now EVERY back gesture takes me out of my app, even if there are still pages left to pop inside my Flutter app. I assume now every back gesture is being handled by the OS

This will be fixed by #109558. Enabling the opt-in turns off the older back handling system.