BinaryDevelop
  1. ホーム
  2. Android

AndroidManifestの使用機能の設定

2022-02-18 09:39:48
<パス

ユーズドフィーチャー宣言

AndroidManifest の uses-feature 設定は、アプリが実行時に依存する外部ハードウェアまたはソフトウェア機能を宣言するために使用されます。uses-feature は、ハードウェアまたはソフトウェア機能が必須であるかどうかを示す required 属性の設定も提供します。trueに設定すると、アプリの実行時にこの機能を使用する必要があることを意味し、使用しない場合は動作しません。falseに設定すると、アプリの実行時にこれらの機能を使用する必要があることを意味しますが、使用しない場合、アプリは一部の機能に影響を受ける可能性がありますが、ほとんどの機能は動作します。例えば、写真アプリの場合、使用時には端末のカメラをオンにする必要があり、カメラがない機種ではどの機能も使えないため、uses-featureでカメラが必要であることを宣言し、requiredをtrueに設定する必要がある。しかし、カメラがない端末の場合、それはコードが使えないというだけで、他の決済方法は使えるので、required属性をfalseにして、この機能の要件が不要であることを示すことができるのです。

シンタックス 

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

所属のノード

属性

android:名前
Androidでサポートされている機能の名称は、以下のように変更することができます。 https://developer.android.com/guide/topics/manifest/uses-feature-element.html#features-reference をクリックすると問い合わせができます。ハードウェア機能の名称にはandroid.hardware.が、ソフトウェア機能の名称にはandroid.software.が接頭辞として付いています。

android:必須
android:required プロパティは、その機能が必須であるかどうかを示し、true または false にのみ設定できます。true に設定すると、その機能は必須であり、その機能がないとアプリは動作しません。falseに設定された場合、アプリケーションはこの機能を必要としますが、そうでない場合、機能の一部に影響を与えるかもしれませんが、アプリケーションは正常に動作することを意味します。この属性が指定されていない場合、デフォルトはtrueであり、この機能が必須であることを意味します。

android:glEsVersion
このプロパティは、アプリが依存する OpenGL ES のバージョンを示す。値は整数で、上位16ビットがOpenGL ESのメジャーバージョン、下位16ビットがOpenGL ESのマイナーバージョンを表します。例えば、OpenGL ESバージョン3.2は、整数値0x00030002に相当し、完全な構成は以下のようになります。 

Currently Android supports OpenGL ES versions 1.0, 1.1, 2.0, 3.0, 3.1 and 3.2. GLES 1.0 is supported from Android 1.0, GLES 1.1 from Android 1.6, GLES 2.0 from Android 2.2 (API level 8), GLES 3.1 from Android 4.3 (API level 18) and GLES 3.1 from Android 5.0 (API level 18). GLES 3.0 is supported from Android 4.3 (API level 18), GLES 3.1 is supported from Android 5.0 (API level 21), and GLES 3.2 is supported from Android N. OpenGL ES versions are backward compatible, which means that an Android version supported to a certain OpenGL ES version can be backward compatible, which means an Android version supports to a certain OpenGL ES version, and can also support lower OpenGL ES version. For example, if Android 4.3 supports up to GLES 3.0, then it can also support versions between GLES 1.0 and GLES 3.0. So the range of supported GLES versions for each Android version can be derived as follows.

Usually there should be only one android:glEsVersion configuration in AndroidManifest, if more than one is configured, only the one with the largest version number will take effect, and the other configurations will be ignored. If there is no android:glEsVersion configured in AndroidManifest, it means it can support up to OpenGL ES 1.0, which means all Android systems support it. The role of uses-feature        uses-feature simply provides this set of information to the public, indicating the hardware and software features it relies on. This information is typically used by the app market, which reads the uses-feature settings of the app and then only distributes the app to devices that meet this set of hardware and software features.        Android does not use the information here during app installation. For example, if an app declares that it requires a camera in its use-feature, and required is true, then the app market will not distribute the app to devices that do not have a camera, and a device that does not have a camera will not be able to search for and download the app through the app market. However, if a user downloads the app's apk file to a device through other channels (such as the official website), and installs the apk on that device, the system does not check whether the hardware and software features declared in uses-feature are met, and if the device does not have a camera, the app can be installed as well.        Not only that, but Android doesn't use the information here when the app is running, so the uses-feature declaration has no impact on the app's operation (unless the app itself determines in code whether a feature is satisfied). This is different from uses-permission, which is read by the Android system and has an impact on the operation of the application. Also take the camera as an example, if the application needs to use the camera for a certain function, no matter how uses-feature is declared, it will not affect whether the camera can be used or not. If the device doesn't have a camera, the feature won't work, but that has nothing to do with the uses-feature declaration. But if the camera is not declared via uses-permission, then the camera will not be available even if the camera hardware is present.        The cause-and-effect relationship here is this: because the app won't work without this feature, it needs to be configured with uses-feature in AndroidManifest to allow the app market to automatically filter out devices that are not supported when distributing the app, not because the app won't work on devices without this feature does not work on devices that do not have it. Google Play app filtering mechanism        When a user opens Google Play to browse or find apps, Google Play filters the apps visible to the user so that only those apps that are compatible with the user's device are seen and downloaded on Google Play. filtering apps based on the hardware and software features declared by use-feature is one way to do this.        When a developer uploads an apk file to Google Play, Google Play reads the AndroidManifest in the apk file, evaluates the features required by the app based on use-feature, use-sdk, use-permission, use-library, and other configuration information, and then generates a list of features, and then generate a metadata associated with the apk version based on this information and save it to the database.        When the user opens the Google Play app on their device, the Google Play app gets the hardware and software features supported by the current device via getSystemAvailableFeatures() and then sends this list to Google Play, and later when the user browses through Google Play on this device or When the user browses or finds an application on this device through Google Play, Google Play will compare the features required by each application with the features supported by the user's device. Only apps that have all the required features supported on the current device are shown, and if an app requires a feature that cannot be met by the current device, then the app will not be shown on that device. Impact on Google Play review Google Play requires the app to explicitly declare all required features, especially those that can be inferred from uses-permission. If the camera-related uses-features are not declared, then Google Play will assume that the app does not declare all required features and may fail the review. Code representation of feature information The FeatureInfo class is used in the Android SDK to represent feature information, and it contains mainly the following member variables and methods. The description is included in the comments. public class FeatureInfo implements Parcelable { /** * The name of this feature, e.g. "android.hardware.camera". * All features have a corresponding name in addition to the OpenGL ES version * These names can be found in the PackageManager class as corresponding constants, all starting with FEATURE_. * For example "android.hardware.camera" the corresponding constant is PackageManager.FEATURE_CAMERA. * For OpenGL ES version FEATURER, the value of name here is null */ public String name; /** * The default value of reqGlEsVersion */ public static final int GL_ES_VERSION_UNDEFINED = 0; /** * GLES version, the high 16 bits indicate a major version of GLES, the low 16 bits indicate a minor version of GLES. * Valid only if the name is null */ public int reqGlEsVersion; /** * Indicates that the current application requires this FEATURE */ public static final int FLAG_REQUIRED = 0x0001; /** * indicates whether the current application needs this feature, can be 0 or FLAG_REQUIRED */ public int flags; ...... Here the constructor method and serialization method are omitted ...... /** * Convert reqGlEsVersion to a string format version number, such as 0x00010002 will return 1.2 */ public String getGlEsVersion() { int major = ((reqGlEsVersion & 0xffff0000) >> 16); int minor = reqGlEsVersion & 0x0000ffff; return String.valueOf(major)+". "+String.valueOf(minor); } } Get the FEATURE information by code As mentioned earlier, the use-feature information configured for an app is for the app marketplace and is not usually needed for the app itself. However, if you do need it, it is possible to get it through code. Get all the FEATURES supported by the current device FeatureInfo[] f = getPackageManager().getSystemAvailableFeatures(); Determine if the current device supports a feature boolean b = getPackageManager().hasSystemFeature(featureName); Get the use-feature configuration of the current app try { String packageName = getPackageName(); PackageInfo p = getPackageManager().getPackageInfo(packageName, PackageManager.GET_CONFIGURATIONS); FeatureInfo[] f = p.reqFeatures; } catch (NameNotFoundException e) { e.printStackTrace(); } This can also be used to get the use-feature configuration of other apps already installed on the current device, by replacing the packageName with the package name of the app you want to get. You don't need special permissions to get the use-feature configuration of other apps, you can get it from any app already installed on the device. Reference links https://developer.android.com/guide/topics/manifest/uses-feature-element.html

関連

最新

おすすめ

について
/
プライバシー・ポリシー
/
お問い合わせ
© 2022 BinaryDevelop. すべての権利は、それぞれの所有者に帰属します