Game Development Reference
In-Depth Information
the ability to send out costly SMS messages or to get a user's location, you may receive some
nasty feedback from users in the Comments section for your application when it's on Google
Play. If you must use one of those problematic permissions, your application description also
should tell the user why you're using it. The best thing to do is to avoid those permissions in the
first place or to provide functionality that legitimately uses them.
The <uses-feature> Element
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 in the Google Play
application on your device. One reason for this can be the use of the
<uses-feature>
element in
the manifest file of the application.
The Google Play 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't 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 when a specific OpenGL ES version is required.
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
independent tracking of multiple fingers, 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
for implementing things like onscreen virtual dual sticks for controls.
We'll look into multitouch in a later section of this chapter. For now, just 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 to do is to specify which OpenGL ES version is
needed. In this topic, we'll be concerned with OpenGL ES 1.0 and 1.1. For these, we usually
don't specify a
<uses-feature>
element because they aren't much 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 we
