How Android 13 could make back navigation more seamless

Google I/O 2022 is almost upon us. In a little under two weeks, Google will kick off its biggest developer conference of the year, and a big topic at the conference will be Android 13. If you haven’t been following along, Google has already released two developer previews and one beta, but as usual, the company has been tight-lipped about many of the more substantial changes. I/O is where Google typically takes the wraps off of big new Android features, and this year will be no exception.

Esper Device Management

One of those big new features will be the “predictive back navigation” system that will be fully detailed in a technical session on day 2 of I/O. The session, called “Back to the basics of System Back”, will cover “how the future of Android will help [developers] create predictive back navigation along with satisfying animations.”

When you see the term “predictive”, the first thing that probably comes to mind is AI. Google is well-known for developing many intelligent features, so it probably wouldn’t surprise you if Google said they were going to employ machine learning to improve navigation. (While they haven’t said anything about it, they have actually experimented with using machine learning to improve back gesture recognition.) I, unfortunately, can’t definitively tell you what will make Android 13’s “predictive back navigation”, well, predictive, but I do have an idea of what those “satisfying animations” will look like as well as some thoughts on where Google is going with this all.

For a bit of background, Google first introduced fullscreen gesture navigations with Android 10. In place of Android’s traditional 3-button navigation bar at the bottom, Android 10’s gestures involve a thin pill at the bottom that users can swipe to switch between apps, enter the recent apps overview, or go to the home screen.

To go back, users can swipe inwards from the left or right side of the screen. There’s an invisible trigger area on both sides of the screen that extends a certain length from each side. The exact width of the trigger area depends on the user-defined back sensitivity setting multiplied by the system default inset size. The user can initiate a back gesture by placing a finger within the back gesture inset, but the command to go back won’t be sent unless the user drags their finger past a minimum distance.

The transition from button-based navigation to gestural navigation initially caused some friction due to the way many applications were designed at the time, so Google provided APIs to deal with conflicts and guidance to update UI components to ensure compatibility with gestures. Over time, most apps have been adapted to work with Android’s gestural navigation, so Google’s turned its attention to what happens when a user tries to back out of an app. In Android 12, Google changed what happens when the user tries to go back on “launcher activities that are at the root of their tasks.” Instead of finishing the activity, the system moves it to the background. This not only makes it so users can quickly resume the app at a later time but also fits in with how I think many users actually use the back gesture — as a way to eventually go back to the home screen. Of course it’s faster to just swipe up to go home, but there are over 3 billion Android devices out there, so there are going to be plenty of users who have conditioned themselves to use their phones differently.

While Android 12’s changes to the activity lifecycle reduce how often users have to completely restart apps, it doesn’t address what I think is another source of friction: how the user is supposed to know when going back navigates up or exits the app. Though the system handles the back stack between activities, individual activities can and often do have their own back stack that the system isn't aware of. Plus, because apps themselves can control the behavior of back navigation (those “are you sure you want to exit? ” prompts are a result of that), the system can’t predict what’ll happen until it happens. This is what I think Android 13’s new “predictive back navigation” is trying to address.

With help from Kevin Barry, the developer of Nova Launcher, I learned that the Pixel Launcher’s Quickstep module has code hinting at a new back-to-home transition animation. What I think will happen is that when swiping back, the app window will scale and follow the user’s finger as they swipe inward. If the user lets go past a minimum distance for the back gesture to be invoked, then another animation will play out — the one from Android 12L that gracefully animates the icon towards its location on the home screen or app drawer.

Unfortunately, a lot of code is missing in the Pixel Launcher, so I can’t actually demonstrate the new animation. However, it should look similar to the current swipe home gesture, with the difference being in what “peeks” out behind the user’s finger. In the case of the swipe home gesture, it’s the wallpaper, while in the case of the new back gesture, it should be a snapshot of the home screen (or app drawer). By seeing the home screen or app drawer as they swipe back, the user has a better idea of what’s going to happen when they complete that gesture.

In order to make this animation actually possible, Google has to make a few changes to the way back navigation works in Android 13. First of all, the system can’t wait for the user to swipe all the way until their finger passes the trigger area before it starts scaling and moving the app window alongside their finger. It needs to start tracking this movement pretty much immediately, which is where I think the system’s “back predictability progress threshold” comes in. I’m thinking this threshold is what the system uses to decide when to treat an inward swipe as a back swipe even if it hasn’t been fully committed yet. This way, the system can start animating before the user’s finger swipes to exit the normal trigger area, which actually completes the back gesture.

Another change that needs to be made is how apps handle back events. If apps continue to override the back behavior in the way they currently can, then the system can’t take action until the app decides what it wants to do. However, Android 13 now lets apps register back invocation callbacks using a new API. If the system detects there aren’t any registered handlers, then it can “predict” that going back should take the user back home and thus play out the new back-to-home animation. If there are layers that have registered a handler, then those will be invoked in the reverse order in which they are registered. This way, Android can both provide a new, more seamless back navigation experience while continuing to let apps handle custom navigation. At least, that’s what I think will happen.

Sadly, since the predictive back navigation system is not enabled by default in current Android 13 builds, I can’t say for certain that this is how it will work or if this is the principle behind its design. What I do know is that the new enableOnBackInvokedCallback Manifest attribute is going to be very important, as it seems to be the way for apps to opt in or out of the new predictive back navigation system. The framework references this flag, as well as the new compatibility flag DISPATCH_BACK_INVOCATION_AHEAD_OF_TIME, in code related to requesting the “legacy” back behavior. Whether or not apps have to opt in or opt out of the new predictive back navigation system and whether or not this will apply to all apps running on Android 13 or only those targeting API level 33 is something we’ll have to wait to find out. I’m also curious to see how this will impact third-party launchers such as Nova. Making new gestures work seamlessly with third-party launchers hasn't seemed to be a top priority for Google in the past, though they do show interest in fixing things.

Esper Device Management