From :《Beginning Android Games》
If you are an Android user yourself and possess an older device with an old Android
version like 1.5, you will have noticed that some awesome applications won’t show up
the Android Market application on the device. One reason for this can be the use of th
<uses-feature> element in the manifest file of the application.
The Android Market application will filter all available applications by your hardware
profile. With the <uses-feature> element, an application can specify which hardware
features it needs—for example, multitouch or support for OpenGL ES 2.0. Any device
that does not have the specified features will trigger that filter so that the end user isn’
shown the application in the first place.
A <uses-feature> element has the following attributes:
<uses-feature android:name="string" android:required=["true" | "false"] android:glEsVersion="integer" />
The name attribute specifies the feature itself. The required attribute tells the filter
whether we really need the feature under all circumstances or if it’s just nice to have.
The last attribute is optional and only used in conjunction with requiring a specific
OpenGL ES version.
For game developers, the following features are most relevant:
android.hardware.touchscreen.multitouch: This requests that the device have a
multitouch screen capable of basic multitouch interactions, such as pinch zooming
and the like. These types of screens have problems with tracking multiple fingers
independently, so you have to evaluate if those capabilities are sufficient for your
game.
android.hardware.touchscreen.multitouch.distinct: This is the big brother of the
last feature. This requests full multitouch capabilities suitable to implement things
like onscreen virtual dual sticks for controls.
We’ll look into multitouch in a later section of this chapter. For now it suffices to
remember that when our game requires a multitouch screen, we can weed out all
devices that don’t support that feature by specifying a <uses-feature> element with one
of the preceding feature names, like so:
<uses-feature android:name="android.hardware.touchscreen.multitouch" android:required="true"/>
Another useful thing for game developers is to specify which OpenGL ES version is
needed. Now, in this book we’ll be concerned with OpenGL ES 1.0 and 1.1. For these,
we usually don’t specify a <uses-feature> element, as they aren’t all that different from
each other. However, any device that implements OpenGL ES 2.0 can be assumed to be
a graphics powerhouse. If our game is visually complex and needs a lot of processing
power, we can require OpenGL ES 2.0 so that the game only shows up for devices that
are able to render our awesome visuals at an acceptable frame rate. Note that we don’t
use OpenGL ES 2.0, but just filter by hardware type so that our OpenGL ES 1.x code
gets enough processing power. Here’s how we can do this:
<uses-feature android:glEsVersion="0x00020000" required="true"/>
This will make our game only show up on devices that support OpenGL ES 2.0 and are
thus assumed to have a fairly powerful graphics processor.
NOTE: This feature is reported incorrectly by some devices out there, making your application
invisible to otherwise perfectly fine devices. Use it with caution.
Now, every specific requirement you have in terms of hardware potentially decreases
the amount of devices your game can be installed on, directly affecting your sales. Think
twice before you specify any of the above. For example, if the standard mode of our
game requires multitouch but we can also think of a way to make it work on single-touch
devices, we should strive for having two code paths, one for each hardware profile, to
be able to deploy to a bigger market.
