AndroidManifest.xml 詳解 (五) 之uses-feature—— 譯自《Beginning Android Games》

    The <uses-feature> Element

    如果你是一個Android使用者，而且你有一個老舊的安裝有android 1.5 的android裝置，你可能會注意到一些高版本的應用沒有在手機上的Android Market 中顯示。這必定是應用使用了<uses-feature>的結果。

 

    Android Market會根據uses-feature過濾所有你裝置不支援的應用。通過使用<uses-feature>元素，一個應用可以指定它所支援的硬體型號，舉個例子，有些裝置不支援多點觸控或者OpenGL ES 2.0，那麼過濾器就會過濾需要這些硬體支援（多點觸控或者OpenGL ES 2.0）的應用，使用者就不會在android market上看到這些應用。

 

    一個<uses-feature>元素包含以下屬性：

    <uses-feature android:name="string" android:required=["true" | "false"]  android:glEsVersion="integer" />

      

    name屬性指定了應用的特徵，required屬性告訴過濾器我們是否在任何情況下必須要需要這個裝置的支援，或者僅僅只是“nice to have”。

   

    最後一個屬性是可選擇的，只是用在需要指定一個OpenGL ES版本的時候。

   

    接下來的幾個硬體特徵對於遊戲開發是非常有用的。

   

    android.hardware.touchscreen.multitouch：它要求裝置有一個多點觸控的螢幕以支援基本的多點觸控互動，就如收縮（放大）映像比例。這些類型的螢幕跟蹤多個手指的能力都有所不同，所以你必須確保這個螢幕的效能是能夠支援的遊戲進行。

   

    android.hardware.touchscreen.multitouch.distinct: 這是一個多點觸控的兄弟屬性，它要求提裝置供完整的多點觸控功能。

 

    我們將會在接下來的章節片段中看到多點觸控。現在只要記住在當你的遊戲需要一個支援多點觸控的螢幕的時候，我們可以使用 <uses-feature>元素來剔除所有不支援多點觸控的裝置，就像下面這樣：

   

    <uses-feature android:name="android.hardware.touchscreen.multitouch"  android:required="true"/>

 

    另外一個在遊戲開發中非常有用的是去指定需要的OpenGL ES版本。在本書中，我們只關心OpenGL ES1.0和OpenGL ES1.1就可以了。由於這2者基本上沒有什麼不同，所以我們也不用去指定<uses-feature>了。然而，有些裝置支援更強大的OpenGL ES2.0

如果你的遊戲需要更強大的圖形處理能力，我們可以指定OpenGL ES 2.0，然後我們的遊戲只會被支援OpenGL ES 2.0的裝置所看見。注意，在本書中不會使用OPenGL ES 2.0, 我們只是過濾那些不能提供足夠圖形處理能力的裝置。下面顯示了我們怎麼去實現它。

   

    <uses-feature android:glEsVersion="0x00020000" required="true"/>

 

    它將使我們的遊戲只被支援OPenGL ES 2.0 和 假裝有相當的圖形處理能力的裝置所看到。

   

    NOTE: 有些裝置所反映的效能特徵是不正確的，所以開發你的應用的時候盡量去支援各種不同的裝置。要謹慎使用<uses-feature>。

   

    現在就以硬體而言，你的應用已經直接地減少了許多安裝量，這將直接影響到你應用的銷量。所以當你定義<uses-feature>之前請謹慎考慮。舉個例子，如果你的遊戲需要有多點觸控的支援，但是我們也可以思考另外一種方法，是遊戲能夠在支援單點觸控的裝置上運行良好，我們就可以寫2個路徑的代碼，分別在兩種裝置上運行。

 

下一個是<uses-sdk>

 

另附上原文

 

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
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.