Devices MUST support a touchscreen or meet the requirements listed in 7.2.2 for non-touch navigation.
Android Watch and Android Automotive implementations MAY implement a soft keyboard. All other device implementations MUST implement a soft keyboard and:
Device implementations:
Android Television devices MUST support D-pad.
Device implementations:
The availability and visibility requirement of the Home, Recents, and Back functions differ between device types as described in this section.
The Home, Recents, and Back functions (mapped to the key events KEYCODE_HOME, KEYCODE_APP_SWITCH, KEYCODE_BACK, respectively) are essential to the Android navigation paradigm and therefore:
UI_MODE_TYPE_WATCH
.KEYCODE_BACK
and omit it from being sent to the foreground application.These functions MAY be implemented via dedicated physical buttons (such as mechanical or capacitive touch buttons), or MAY be implemented using dedicated software keys on a distinct portion of the screen, gestures, touch panel, etc. Android supports both implementations. All of these functions MUST be accessible with a single action (e.g. tap, double-click or gesture) when visible.
All of these functions (HOME, RECENTS, a long press on BACK, a normal BACK), MUST be accessible with a single action (e.g. tap, double-click or gesture) when the navigation bar is not hidden. These actions, when accessible, MUST be clearly indicated to the user. Having a visible icon imprinted on the button, showing a software icon key on the screen, or walking the user through a guided step-by-step demo flow during the out-of-box setup experience are examples of such an indication.
The Menu function is deprecated in favor of action bar since Android 4.0. Therefore the new device implementations shipping with Android ANDROID_VERSION and later MUST NOT implement a dedicated physical button for the Menu function. Older device implementations SHOULD NOT implement a dedicated physical button for the Menu function, but if the physical Menu button is implemented and the device is running applications with targetSdkVersion > 10, the device implementation:
For backwards compatibility, device implementations MUST make the Menu function available to applications when targetSdkVersion is less than 10, either by a physical button, a software key, or gestures. This Menu function should be presented unless hidden together with other navigation functions.
Android device implementations supporting the Assist action and/or VoiceInteractionService
MUST be able to launch an assist app with a single interaction (e.g. tap, double-click, or gesture) when other navigation keys are visible. It is STRONGLY RECOMMENDED to use long press on home as this interaction. The designated interaction MUST launch the user-selected assist app, in other words the app that implements a VoiceInteractionService, or an activity handling the ACTION_ASSIST intent.
Device implementations MAY use a distinct portion of the screen to display the navigation keys, but if so, MUST meet these requirements:
Android Handhelds and Watch Devices MUST support touchscreen input.
Device implementations SHOULD have a pointer input system of some kind (either mouse-like or touch). However, if a device implementation does not support a pointer input system, it MUST NOT report the android.hardware.touchscreen or android.hardware.faketouch feature constant. Device implementations that do include a pointer input system:
Android includes support for a variety of touchscreens, touch pads, and fake touch input devices. Touchscreen-based device implementations are associated with a display such that the user has the impression of directly manipulating items on screen. Since the user is directly touching the screen, the system does not require any additional affordances to indicate the objects being manipulated. In contrast, a fake touch interface provides a user input system that approximates a subset of touchscreen capabilities. For example, a mouse or remote control that drives an on-screen cursor approximates touch, but requires the user to first point or focus then click. Numerous input devices like the mouse, trackpad, gyro-based air mouse, gyro-pointer, joystick, and multi-touch trackpad can support fake touch interactions. Android includes the feature constant android.hardware.faketouch, which corresponds to a high-fidelity non-touch (pointer-based) input device such as a mouse or trackpad that can adequately emulate touch-based input (including basic gesture support), and indicates that the device supports an emulated subset of touchscreen functionality. Device implementations that declare the fake touch feature MUST meet the fake touch requirements in section 7.2.5.
Device implementations MUST report the correct feature corresponding to the type of input used. Device implementations that include a touchscreen (single-touch or better) MUST report the platform feature constant android.hardware.touchscreen. Device implementations that report the platform feature constant android.hardware.touchscreen MUST also report the platform feature constant android.hardware.faketouch. Device implementations that do not include a touchscreen (and rely on a pointer device only) MUST NOT report any touchscreen feature, and MUST report only android.hardware.faketouch if they meet the fake touch requirements in section 7.2.5.
Device implementations that declare support for android.hardware.faketouch:
Devices that declare support for android.hardware.faketouch.multitouch.distinct MUST meet the requirements for faketouch above, and MUST also support distinct tracking of two or more independent pointer inputs.
Android Television device implementations MUST support button mappings for game controllers as listed below. The upstream Android implementation includes implementation for game controllers that satisfies this requirement.
Android Television device implementations MUST support the following key mappings:
D-pad down1 0x01 0x00393 AXIS_HAT_Y4
D-pad right1 0x01 0x00393 AXIS_HAT_X4
0x01 0x0031 AXIS_X
AXIS_Y
0x01 0x0035 AXIS_Z
AXIS_RZ
Android Television device implementations SHOULD provide a remote control to allow users to access the TV interface. The remote control MAY be a physical remote or can be a software-based remote that is accessible from a mobile phone or tablet. The remote control MUST meet the requirements defined below.