\n
![](\"https:\/\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEh0mQvASMlgKp0V9-V7d-D1uIC5j1aSzEBxwsAxr1nxEyaCBYM53s2qTJ9PiS1cJ6V1ZikicN_ptQQJjwDdoWVKNzdpLzCJxJ0NQoQ5UxVRYV924yj2sXDV_obr9ajYa8nHQTTRSK2N-iNBfYRj2c_T1507KUjsZLeJkJTxMLOHH3GJ77xX0mKOEq_QJ54\/s1600\/social-Remove-unnecessary-required-features%20%281%29.png\")
<\/p>\nPosted by Alex Vanyo \u2013 Developer Relations Engineer<\/em><\/p>\n <uses-feature><\/a><\/span> is an app manifest element that specifies whether your app depends on a hardware or software feature<\/a>. By default, <uses-feature><\/span> specifies that a feature is required. To indicate that the feature is optional, you must add the android:required=”false”<\/span> attribute.<\/p>\n Google Play filters<\/a> which apps are available to download based on required features. If the user\u2019s device doesn\u2019t support some hardware or software feature, then an app that requires that feature won\u2019t be available for the user to download.<\/p>\n <uses-permission><\/a><\/span>, another app manifest element, complicates things by implicitly requiring features for permissions such as CAMERA<\/span> or BLUETOOTH<\/span> (see Permissions that imply feature requirements<\/a>). The initial declared orientations for your activities can also implicitly require<\/a> hardware features.<\/p>\n The system determines implicitly required features after merging all modules and dependencies, so it may not be clear to you which features your app ultimately requires. You might not even be aware when the list of required features has changed. For example, integrating a new dependency into your app might introduce a new required feature. Or the integration might request additional permissions, and the permissions could introduce new, implicitly required features.<\/p>\n This behavior has been around for a while, but Android has changed a lot over the years. Android apps now run on phones, foldables, tablets, laptops, cars, TVs and watches, and these devices are more varied than ever. Some devices don\u2019t have telephony services, some don\u2019t have touchscreens, some don\u2019t have cameras.<\/p>\n Expectations based on permissions have also changed. With runtime permissions, a <uses-permission><\/a><\/span> declaration in the manifest no longer guarantees that your app will be granted that permission. Users can choose to deny access to hardware in favor of other ways to interact with the app. For example, instead of giving an app permission to access the device\u2019s location, a user may prefer to always search for a particular location instead.<\/p>\n Banking apps shouldn\u2019t require the device to have an autofocusing camera for check scanning. They shouldn\u2019t specify that the camera must be a front or rear camera or that the device has a camera at all! It should be enough to allow the user to upload a picture of a check from another source.<\/p>\n Apps should support keyboard navigation and mouse input for accessibility and usability reasons, so strictly requiring a hardware touchscreen should not be necessary.<\/p>\n Apps should support both landscape and portrait orientations, so they shouldn\u2019t require that the screen could be landscape-oriented or could be portrait-oriented. For example, screens built in to cars may be in a fixed landscape orientation. Even if the app supports both landscape and portrait, the app could be unnecessarily requiring that the device supports being used in portrait, which would exclude those cars.<\/p>\n You can use aapt2<\/a><\/span> to output information<\/a> about your APK, including the explicitly and implicitly required features. The logic matches how the Play Store filters app availability.<\/p>\n In the Play Console, you can also check which devices are being excluded from accessing your app.<\/p>\n Most apps should not strictly require hardware and software features. There are few guarantees that the user will allow using that feature in the first place, and users expect to be able to use all parts of your app in the way they see fit. To increase your app\u2019s availability across form factors:<\/p>\n To guard against regressions caused by inadvertently adding a new feature requirement that reduces device availability, automate the task of determining your app\u2019s features as part of your build system. By storing the badging output of the aapt2<\/span> tool in a text file and checking the file into version control, you can track all declared permissions and explicitly and implicitly required features from your final universal apk. This includes all features and permissions included by transitive dependencies, in addition to your own.<\/p>\n You can automate badging as part of your continuous integration setup by setting up three Gradle tasks for each variant of your app you want to validate. Using release as an example, create these three tasks:<\/p>\n CI should run checkReleaseBadging<\/span> to verify that the checked-in golden badging file still matches the generated badging file for the current code. If code changes or dependency updates have caused the badging file to change in any way, CI fails.<\/p>\n When changes are intentional, run updateReleaseBadging<\/span> to update the golden badging file and recheck it into source control. Then, this change will surface in code review to be validated by reviewers that the badging changes are expected.<\/p>\n CI-automated badging guards against changes inadvertently causing a new feature to be required, which would reduce availability of the app.<\/p>\n For a complete working example of a CI system verifying the badging file, check out the setup in the Now in Android<\/a> app.<\/p>\n Android devices are continually becoming more varied, with users expecting a great experience from your Android app regardless of the type of device they\u2019re using. While some software or hardware features might be essential to your app\u2019s function, in many cases they should not be strictly required, needlessly preventing some users from downloading your app.<\/p>\n Use the badging<\/a> output from aapt2<\/span> to check which features your app requires, and use the Play Console to verify which devices the requirements are preventing from downloading your app. You can automatically check your app\u2019s badging in CI and catch regressions.<\/p>\n Bottom line:<\/b> If you don\u2019t absolutely need a feature for your entire app to function, make the feature optional to ensure your app\u2019s availability to the greatest number of devices and users.<\/p>\n Learn more by checking out our developer guide<\/a>.<\/p>\n<\/div>\n![](\"https:\/\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEjuGXY_G5N4CDN2OcJC4IWqYwKpQgbWmgOPGgNe5oZdfRT-hZkaBGn2TKpCbcNiS2BkWRFFoO-opsO5_fdcsotKYLBsxJzBOBXrEpUWpAH4qNLDYVBGI2T_w2lH4dWyqeMKnXAYwJHyR4a2G1GTQ0Nc9Ft_Yr21KXCyKwC-5u-hxBYbaKcj-s_ic2sdq-4\/s1600\/header-Remove-unnecessary-required-features%20%281%29.png\")
<\/a><\/p>\nTL;DR:<\/b><\/span> Remove unnecessary feature requirements that prevent users from downloading your app on devices that don\u2019t support the features. Automate tracking feature requirements and maximize app availability with badging!<\/i><\/span><\/h2>\n
Required features reduce app availability<\/span><\/h2>\n
Determine your app\u2019s required features<\/span><\/h2>\n
aapt2 dump badging <path_to_.apk><\/span><\/pre>\n<\/div>\nIncrease app availability by making features optional<\/span><\/h2>\n
\n
\n
Prevent regressions with CI and badging<\/span><\/h2>\n
\n
\n
<\/div>\n<\/div>\nKeep features optional<\/span><\/h2>\n