TV devices provide a limited set of navigation controls for apps. Creating an effective navigation scheme for your TV app depends on understanding these limited controls and the limits of users' perception while operating your app. As you build your Android app for TVs, pay special attention to how the user actually navigates around your app when using remote control buttons instead of a touch screen.
Navigation should feel natural and familiar without dominating the user interface or diverting attention from content. The following principles will set a baseline for a consistent and intuitive user experience across TV apps.
Make it fast and easy to get to content. Users want to access content quickly, using a minimal number of clicks. Organize your information in a way that requires the fewest screens.
Utilize existing best practices and recommendations to make navigation predictable to the users. Don't reinvent the navigation patterns unnecessarily as they lead to confusion and unpredictability.
Make navigation simple enough to seamlessly support widely adopted user behaviors. Don’t over complicate by adding multiple layers of navigation unnecessarily.
Controllers come in a variety of styles from minimalist remote control to complex game controllers. All controllers include a directional pad (D-pad) plus select, home, and back buttons. Other buttons vary between different models.
Directional pad (D-pad)
The primary navigation method on TV is through the directional pad (called a D-pad). This pad limits movement to up, down, left, and right directional hardware buttons. The D-pad transfers focus from one object to the nearest object in the direction of the button pressed.
Selects an item focused on-screen.
Takes the user to the system Home screen.
Gives viewers a way to return to the previous view.
Used to invoke either Google Assistant or voice input.
Enable D-pad navigation
On a TV device, users navigate using either a directional pad (D-pad) or arrow keys. This type of control limits movement to up, down, left, and right. To build a great TV-optimized app, you must provide a navigation scheme where the user can quickly learn how to navigate your app using these limited controls.
The Android framework handles directional navigation between layout elements automatically, so you typically do not need to do anything extra for your app. However, you should thoroughly test navigation with a D-pad controller to discover any navigation problems. Follow these guidelines to test that your app's navigation system works well with a D-pad on a TV device:
- Ensure that a user with a D-pad controller can navigate to all visible controls on the screen.
- For scrolling lists with focus, make sure that the D-pad up and down keys scroll the list, and the Enter key selects an item in the list. Verify that users can select an element in the list and that the list still scrolls when an element is selected.
- Ensure that switching between controls is straightforward and predictable.
Modifying directional navigation
The Android framework automatically applies a directional navigation scheme based on the relative position of focusable elements in your layouts. You should test the generated navigation scheme in your app using a D-pad controller. After testing, if you decide you want users to move through your layouts in a specific way, you can set up explicit directional navigation for your controls.
The following code sample shows how to define the next control to receive focus
TextView layout object:
<TextView android:id="@+id/Category1" android:nextFocusDown="@+id/Category2" />
The following table lists all of the available navigation attributes for Android user interface widgets:
||Defines the next view to receive focus when the user navigates down.|
||Defines the next view to receive focus when the user navigates left.|
||Defines the next view to receive focus when the user navigates right.|
||Defines the next view to receive focus when the user navigates up.|
To use one of these explicit navigation attributes, set the value to the ID
android:id value) of another widget in the layout. You should set up the
navigation order as a loop, so that the last control directs focus back to the
Provide clear focus and selection
The success of an app's navigation scheme on TV devices depends on how easy it is for a user to determine what user interface element is in focus on screen. If you do not provide clear indications of focused items (and therefore what item a user can take action on), they can quickly become frustrated and exit your app. For the same reason, it is important to always have an item in focus that a user can take action on immediately after your app starts, or any time it is idle.
Your app layout and implementation should use color, size, animation, or a combination of these attributes to help users easily determine what actions they can take next. Use a uniform scheme for indicating focus across your application.
Android provides Drawable state list resources to implement highlights for focused and selected controls. The following code example demonstrates how to enable visual behavior for a button to indicate that a user has navigated to the control and then selected it:
<!-- res/drawable/button.xml --> <?xml version="1.0" encoding="utf-8"?> <selector xmlns:android="http://schemas.android.com/apk/res/android"> <item android:state_pressed="true" android:drawable="@drawable/button_pressed" /> <!-- pressed --> <item android:state_focused="true" android:drawable="@drawable/button_focused" /> <!-- focused --> <item android:state_hovered="true" android:drawable="@drawable/button_focused" /> <!-- hovered --> <item android:drawable="@drawable/button_normal" /> <!-- default --> </selector>
The following layout XML sample code applies the previous state list drawable to
<Button android:layout_height="wrap_content" android:layout_width="wrap_content" android:background="@drawable/button" />
Make sure to provide sufficient padding within the focusable and selectable controls so that the highlights around them are clearly visible.
In order to bring consistency across apps on the platform, the back button behavior should follow the following guidelines.
Predictable back button behavior
To create an easy and predictable navigation experience, let users navigate backward with the remote's back button. Pressing the back button should always take the user to the previous destination.
If the user navigates from a menu item to a certain card on the middle of the page and then the user presses the back button one of the following could happen.
- App uses the top navigation: User is taken back to the top of the page by scrolling quickly and activates the focus to the menu.
- App uses left navigation: The left side menu is activated and the user's focus is taken to the currently active menu item.
The Back button shouldn't be gated by confirmation screens or enter into an infinite loop.
Avoid exit gating. Users should be able to exit out of the app without any confirmation.
Apps should never enter into the infinite loop of closing and opening the menu. Ideally, pressing the back button should exit out of the app. Apps shouldn't show an exit button on the menu unless it's a special case such as a kids profile.
Don't display an up or back button
Unlike handheld devices, the back button on the remote is used to navigate backward. For efficient use of space, it is not required to show a virtual back button on the screen.
A back button displayed on the screen as users utilize the back button on the remote to go backward.
Show cancel button if necessary
If the only visible actions are confirming, destructive, or purchase actions, it's good practice to have a Cancel button that returns to the previous destination.
When required, display a cancel button that lets users navigate back to the previous page.
Implementing Back Navigation
Similar to the D-pad, the Android framework will generally handle back
navigation well. If you make use of the Navigation component,
you can easily support a variety of navigation graphs. Occasionally, you do need
to implement some custom behavior such as having the back button reset the focus
to the beginning of a long list.
the base class for
allows you to control the behavior of the Back button by using its
which you can retrieve by calling
getOnBackPressedDispatcher(). See the guide
on how to provide custom back navigation
Playback controls on TV
Video playback is one of the most important features on TV. It's important that video players in apps across Android TV behave the same. Refer to the Playback controls guidelines for TV.
Live Tab navigation
In addition to complying with TV app quality requirements, apps with a live TV feed integrated on the Live tab must also meet frictionless playback and direct-back requirements.
Frictionless Playback applies to in-app behavior following any Live/Linear channel deep link from Google TV and Android TV.
- Users who click a Live/Linear channel deep link from Google TV and Android TV must be led directly to channel playback without any blocking or delaying screens from the target app.
- Sign-in flows, sign-up flows, branding videos, and other delays are not
- However, if the deep link initiates the target app loading from a cold boot, then this boot-up delay to playback IS permitted.
- Additionally, any app boot-up branding video or animation is also permitted in this case. Such a cold boot experience is unlikely to occur more than once per session.
Additionally, tuning into the deep-linked channel may take a few seconds, during which channel and/or service branding is often displayed.
- This channel loading latency and branding moment IS permitted. However, its duration should only be as long as it takes to load the channel (and similar to average channel load times within the app).
If the user is signed out or isn't subscribed, you can block playback for a paid channel to complete a sign-in or sign-up flow.
After launching the app from a deep link on the Live tab, users who press the
back button directly after the app launch must be returned to the Live tab in a
single back press, regardless of how much time has elapsed. This direct-back
behavior is required for all Live tab deep links on Google TV and Android TV.
Live tab deep links are distinguished by an appended deep link parameter
?exit_on_back=[true|false]. Apps must parse this parameter to determine
whether the app was launched from the Live tab. If
apps must implement the direct-back behavior.
Note that if the user presses any other button besides the back button as the first click after the deep link, then the direct-back requirement no longer applies, and only the standard back button behavior applies.
- For example, suppose after following a deep link the user presses D-pad
Select, which brings up a controls overlay, waits for it to disappear, and
then presses the back button. Since the first click was D-pad Select, the
direct-back requirement does not apply.
- Instead, the normal app backstack and logic should apply.
- Repeated presses of the back button should lead the user to the app root and then back to Google TV or Android TV, without any infinite loops. (Learn more)
Fixed start destination
The first screen the user sees when they launch the app from the launcher. This destination is also the last screen the user sees when they return to the launcher after pressing the Back button.
Deep linking simulates manual navigation
Whether deep linking or manually navigating to a specific destination, you can use the back button to navigate through destinations back to the start destination.
Deep linking into an app from another app will simulate manual navigation. For example, if a user went directly to a Details page on Moviestar app from Google TV and then pressed the back button, it would take the user to the Homepage of Moviestar app.
Clear path to all focusable elements
Users should be able to navigate your UI with clear direction. If there isn't a straight path to get to a control, consider relocating it.
Place controls, like the search action, in locations that don't overlap with other clickable elements.
Avoid layouts that contain controls in hard-to-reach places. Reaching the search action is not easy to manage with the D-pad.
Design your layout so it takes advantage of both horizontal and vertical axes. Give each direction a specific function, making it fast to navigate large hierarchies.
Categories can be traversed on the vertical axes, and items within each category can be browsed on the horizontal axis.
Avoid complex and nested layout hierarchy.