Users navigate backward through screens using*back navigation* . Most Android devices have a back button---physical, software, or gesture-based. Usually, you shouldn't add a back button to your app. However, Android Automotive OS (AAOS) devices in compatibility mode use a system back button. This handles navigation, so you don't need to add your own. For details, see[AAOS Compatibility Mode](https://developer.android.com/training/cars/platforms/automotive-os/compatibility-mode).

Android maintains a*back stack* of destinations as the user navigates throughout your application. This usually allows Android to properly navigate to previous destinations when the Back button is pressed. However, there are a few cases where your app might need to implement its own Back behavior in order to provide the best possible user experience. For example, when using a`WebView`, you might want to override the default Back button behavior to allow the user to navigate back through their web browsing history instead of the previous screens in your app.
| **Note:** Android 13 introduces predictive back navigation, which works with custom back navigation, for Android devices. We strongly recommend that you implement predictive back navigation as soon as possible. Otherwise, users might experience unexpected behavior in a future Android release. To learn more, see[Add support for the predictive back gesture](https://developer.android.com/guide/navigation/predictive-back-gesture).

## Implement custom back navigation

[`ComponentActivity`](https://developer.android.com/reference/androidx/activity/ComponentActivity), the base class for[`FragmentActivity`](https://developer.android.com/reference/androidx/fragment/app/FragmentActivity)and[`AppCompatActivity`](https://developer.android.com/reference/androidx/appcompat/app/AppCompatActivity), allows you to control the behavior of the Back button by using its[`OnBackPressedDispatcher`](https://developer.android.com/reference/androidx/activity/OnBackPressedDispatcher), which you can retrieve by calling[`getOnBackPressedDispatcher()`](https://developer.android.com/reference/androidx/activity/ComponentActivity#getOnBackPressedDispatcher()).
| **Note:** If your app uses Activity 1.5.0 or higher, you can also implement custom back navigation for a dialog by using[`ComponentDialog`](https://developer.android.com/reference/androidx/activity/ComponentDialog)and its`OnBackPressedDispatcher`.

The`OnBackPressedDispatcher`controls how Back button events are dispatched to one or more[`OnBackPressedCallback`](https://developer.android.com/reference/androidx/activity/OnBackPressedCallback)objects. The constructor for`OnBackPressedCallback`takes a boolean for the initial enabled state. Only when a callback is enabled (i.e.,[`isEnabled()`](https://developer.android.com/reference/androidx/activity/OnBackPressedCallback#isEnabled())returns`true`) will the dispatcher call the callback's[`handleOnBackPressed()`](https://developer.android.com/reference/androidx/activity/OnBackPressedCallback#handleOnBackPressed())to handle the Back button event. You can change the enabled state by calling[`setEnabled()`](https://developer.android.com/reference/androidx/activity/OnBackPressedCallback#setEnabled(boolean)).

Callbacks are added via the`addCallback`methods. It is strongly recommended to use the[`addCallback()`](https://developer.android.com/reference/androidx/activity/OnBackPressedDispatcher#addCallback(androidx.lifecycle.LifecycleOwner,%20androidx.activity.OnBackPressedCallback))method which takes a[`LifecycleOwner`](https://developer.android.com/reference/androidx/lifecycle/LifecycleOwner). This ensures that the`OnBackPressedCallback`is only added when the`LifecycleOwner`is[`Lifecycle.State.STARTED`](https://developer.android.com/reference/androidx/lifecycle/Lifecycle.State#STARTED). The activity also removes registered callbacks when their associated`LifecycleOwner`is destroyed, which prevents memory leaks and makes it suitable for use in fragments or other lifecycle owners that have a shorter lifetime than the activity.

Here's an example callback implementation:  

### Kotlin

```kotlin
class MyFragment : Fragment() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // This callback will only be called when MyFragment is at least Started.
        val callback = requireActivity().onBackPressedDispatcher.addCallback(this) {
            // Handle the back button event
        }

        // The callback can be enabled or disabled here or in the lambda
    }
    ...
}
```

### Java

```java
public class MyFragment extends Fragment {

    @Override
    public void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        // This callback will only be called when MyFragment is at least Started.
        OnBackPressedCallback callback = new OnBackPressedCallback(true /* enabled by default */) {
            @Override
            public void handleOnBackPressed() {
                // Handle the back button event
            }
        };
        requireActivity().getOnBackPressedDispatcher().addCallback(this, callback);

        // The callback can be enabled or disabled here or in handleOnBackPressed()
    }
    ...
}
```

You can provide multiple callbacks via[`addCallback()`](https://developer.android.com/reference/androidx/activity/OnBackPressedDispatcher#addCallback(%20androidx.activity.OnBackPressedCallback)). When doing so, the callbacks are invoked in the reverse order in which they are added - the callback added last is the first given a chance to handle the Back button event. For example, if you added three callbacks named`one`,`two`and`three`in order, they would be invoked in the order of`three`,`two`, and`one`, respectively.

Callbacks follow the[Chain of Responsibility](https://en.wikipedia.org/wiki/Chain-of-responsibility_pattern)pattern. Each callback in the chain is invoked only if the preceding callback was not enabled. This means that in the preceding example, callback`two`would be invoked only if callback`three`was not enabled. Callback`one`would only be invoked if callback`two`was not enabled, and so on.

Note that when added via[`addCallback()`](https://developer.android.com/reference/androidx/activity/OnBackPressedDispatcher#addCallback(androidx.lifecycle.LifecycleOwner,%20androidx.activity.OnBackPressedCallback)), the callback is not added to the chain of responsibility until the`LifecycleOwner`enters the[`Lifecycle.State.STARTED`](https://developer.android.com/reference/androidx/lifecycle/Lifecycle.State#STARTED)state.

Changing the enabled state on the`OnBackPressedCallback`is strongly recommended for temporary changes as it maintains the ordering described above, which is particularly important if you have callbacks registered on multiple different nested lifecycle owners.

However, in cases where you want to remove the`OnBackPressedCallback`entirely, you should call[`remove()`](https://developer.android.com/reference/androidx/activity/OnBackPressedCallback#remove()). This is usually not necessary, however, because callbacks are automatically removed when their associated[`LifecycleOwner`](https://developer.android.com/reference/androidx/lifecycle/LifecycleOwner)is[destroyed](https://developer.android.com/reference/androidx/lifecycle/Lifecycle.State#DESTROYED).

## Activity onBackPressed()

If you are using[`onBackPressed()`](https://developer.android.com/reference/androidx/activity/ComponentActivity#onBackPressed())to handle Back button events, we recommend using a[`OnBackPressedCallback`](https://developer.android.com/reference/androidx/activity/OnBackPressedCallback)instead. However, if you are unable to make this change, the following rules apply:

- All callbacks registered via`addCallback`are evaluated when you call`super.onBackPressed()`.
- In Android 12 (API level 32) and lower,`onBackPressed`is always called, regardless of any registered instances of`OnBackPressedCallback`.