Struct UsesConfiguration

pub struct UsesConfiguration {
    pub req_five_way_nav: Option<VarOrBool>,
    pub req_hard_keyboard: Option<VarOrBool>,
    pub req_keyboard_type: Option<ReqKeyboardType>,
    pub req_navigation: Option<ReqNavigation>,
    pub req_touch_screen: Option<ReqTouchScreen>,
}

Indicates what hardware and software features the application requires.

For example, an application might specify that it requires a physical keyboard or a particular navigation device, like a trackball. The specification is used to avoid installing the application on devices where it will not work.

Note

Most apps should not use this manifest tag . You should always support input with a directional pad (d-pad) in order to assist sight-impaired users and support devices that provide d-pad input in addition to or instead of touch. information about how to support d-pad input in your app, read Enabling Focus Navigation. If your app absolutely cannot function without a touchscreen, then instead use the <uses-feature> tag to declare the required touchscreen type, ranging from "android.hardware.faketouch" for basic touch-style events to more advanced touch types such as "android.hardware.touchscreen.multitouch.jazzhand" for distinct input from multiple fingers.

XML Syntax

<uses-configuration android:reqFiveWayNav=["true" | "false"]
                    android:reqHardKeyboard=["true" | "false"]
                    android:reqKeyboardType=["undefined" | "nokeys" | "qwerty" | "twelvekey"]
                    android:reqNavigation=["undefined" | "nonav" | "dpad" | "trackball" | "wheel"]
                    android:reqTouchScreen=["undefined" | "notouch" | "stylus" | "finger"] />

Contained in

• <manifest>

Introduced in

API Level 3

Fields

req_five_way_nav: Option<VarOrBool>

Whether or not the application requires a five-way navigation control — "true" if it does, and "false" if not. A five-way control is one that can move the selection up, down, right, or left, and also provides a way of invoking the current selection. It could be a D-pad (directional pad), trackball, or other device.

If an application requires a directional control, but not a control of a particular type, it can set this attribute to “true” and ignore the reqNavigation attribute. However, if it requires a particular type of directional control, it can ignore this attribute and set reqNavigation instead.

req_hard_keyboard: Option<VarOrBool>

Whether or not the application requires a hardware keyboard — "true" if it does, and "false" if not.

req_keyboard_type: Option<ReqKeyboardType>

The type of keyboard the application requires, if any at all. This attribute does not distinguish between hardware and software keyboards. If a hardware keyboard of a certain type is required, specify the type here and also set the reqHardKeyboard attribute to "true".

req_navigation: Option<ReqNavigation>

The navigation device required by the application, if any.

If an application requires a navigational control, but the exact type of control doesn’t matter, it can set the reqFiveWayNav attribute to “true” rather than set this one.

req_touch_screen: Option<ReqTouchScreen>

The type of touch screen the application requires, if any at all.

Trait Implementations

impl Clone for UsesConfiguration

fn clone(&self) -> UsesConfiguration

Returns a duplicate of the value.

const fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for UsesConfiguration

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for UsesConfiguration

fn default() -> UsesConfiguration

Returns the “default value” for a type.

impl<'de> Deserialize<'de> for UsesConfiguration

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for UsesConfiguration

fn eq(&self, other: &UsesConfiguration) -> bool

Tests for self and other values to be equal, and is used by ==.

const fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Serialize for UsesConfiguration

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl YaDeserialize for UsesConfiguration

fn deserialize<R: Read>(reader: &mut Deserializer<R>) -> Result<Self, String>

impl YaSerialize for UsesConfiguration

fn serialize<W: Write>(&self, writer: &mut Serializer<W>) -> Result<(), String>

fn serialize_attributes( &self, source_attributes: Vec<OwnedAttribute>, source_namespace: Namespace, ) -> Result<(Vec<OwnedAttribute>, Namespace), String>

impl Eq for UsesConfiguration

impl StructuralPartialEq for UsesConfiguration