Posted by Alex Vanyo – Developer Relations Engineer
TL;DR: Take away pointless function necessities that forestall customers from downloading your app on units that don’t assist the options. Automate monitoring function necessities and maximize app availability with badging!
Required options cut back app availability
<uses-feature> is an app manifest factor that specifies whether or not your app will depend on a {hardware} or software program function. By default, <uses-feature> specifies {that a} function is required. To point that the function is non-obligatory, you should add the android:required=”false” attribute.
Google Play filters which apps can be found to obtain primarily based on required options. If the person’s gadget doesn’t assist some {hardware} or software program function, then an app that requires that function gained’t be out there for the person to obtain.
<uses-permission>, one other app manifest factor, complicates issues by implicitly requiring options for permissions equivalent to CAMERA or BLUETOOTH (see Permissions that indicate function necessities). The preliminary declared orientations on your actions may also implicitly require {hardware} options.
The system determines implicitly required options after merging all modules and dependencies, so it might not be clear to you which of them options your app in the end requires. You may not even bear in mind when the listing of required options has modified. For instance, integrating a brand new dependency into your app may introduce a brand new required function. Or the mixing may request extra permissions, and the permissions might introduce new, implicitly required options.
This conduct has been round for some time, however Android has modified lots through the years. Android apps now run on telephones, foldables, tablets, laptops, automobiles, TVs and watches, and these units are extra assorted than ever. Some units don’t have telephony companies, some don’t have touchscreens, some don’t have cameras.
Expectations primarily based on permissions have additionally modified. With runtime permissions, a <uses-permission> declaration within the manifest now not ensures that your app will probably be granted that permission. Customers can select to disclaim entry to {hardware} in favor of different methods to work together with the app. For instance, as a substitute of giving an app permission to entry the gadget’s location, a person might favor to at all times seek for a specific location as a substitute.
Banking apps shouldn’t require the gadget to have an autofocusing digital camera for examine scanning. They shouldn’t specify that the digital camera should be a entrance or rear digital camera or that the gadget has a digital camera in any respect! It ought to be sufficient to permit the person to add an image of a examine from one other supply.
Apps ought to assist keyboard navigation and mouse enter for accessibility and value causes, so strictly requiring a {hardware} touchscreen shouldn’t be vital.
Apps ought to assist each panorama and portrait orientations, so that they shouldn’t require that the display may very well be landscape-oriented or may very well be portrait-oriented. For instance, screens inbuilt to automobiles could also be in a hard and fast panorama orientation. Even when the app helps each panorama and portrait, the app may very well be unnecessarily requiring that the gadget helps being utilized in portrait, which might exclude these automobiles.
Decide your app’s required options
You should utilize aapt2 to output data about your APK, together with the explicitly and implicitly required options. The logic matches how the Play Retailer filters app availability.
aapt2 dump badging <path_to_.apk>
Within the Play Console, you can too examine which units are being excluded from accessing your app.
Enhance app availability by making options non-obligatory
Most apps mustn’t strictly require {hardware} and software program options. There are few ensures that the person will enable utilizing that function within the first place, and customers count on to have the ability to use all components of your app in the best way they see match. To extend your app’s availability throughout kind components:
- Present options in case the function shouldn’t be out there, guaranteeing your app doesn’t want the function to perform.
- Add android:required=”false” to current <uses-feature> tags to mark the function as not required (or take away the tag solely if the app now not makes use of a function).
- Add the <uses-feature> tag with android:required=”false” for implicitly required function on account of declaring permissions that indicate function necessities.
Forestall regressions with CI and badging
To protect towards regressions brought on by inadvertently including a brand new function requirement that reduces gadget availability, automate the duty of figuring out your app’s options as a part of your construct system. By storing the badging output of the aapt2 software in a textual content file and checking the file into model management, you’ll be able to monitor all declared permissions and explicitly and implicitly required options out of your ultimate common apk. This contains all options and permissions included by transitive dependencies, along with your personal.
You may automate badging as a part of your steady integration setup by organising three Gradle duties for every variant of your app you need to validate. Utilizing launch for example, create these three duties:
- generateReleaseBadging – Generates the badging file from the common APK utilizing the aapt2 executable. The output of this activity (the badging data) is used for the next two duties.
- updateReleaseBadging – Copies the generated badging file into the primary challenge listing. The file is checked into supply management as a golden badging file.
- checkReleaseBadging – Validates the generated badging file towards the golden badging file.
CI ought to run checkReleaseBadging to confirm that the checked-in golden badging file nonetheless matches the generated badging file for the present code. If code modifications or dependency updates have brought about the badging file to vary in any approach, CI fails.
When modifications are intentional, run updateReleaseBadging to replace the golden badging file and recheck it into supply management. Then, this variation will floor in code assessment to be validated by reviewers that the badging modifications are anticipated.
CI-automated badging guards towards modifications inadvertently inflicting a brand new function to be required, which would scale back availability of the app.
For an entire working instance of a CI system verifying the badging file, take a look at the setup within the Now in Android app.
Maintain options non-obligatory
Android units are regularly changing into extra assorted, with customers anticipating an important expertise out of your Android app no matter the kind of gadget they’re utilizing. Whereas some software program or {hardware} options may be important to your app’s perform, in lots of circumstances they shouldn’t be strictly required, needlessly stopping some customers from downloading your app.
Use the badging output from aapt2 to examine which options your app requires, and use the Play Console to confirm which units the necessities are stopping from downloading your app. You may mechanically examine your app’s badging in CI and catch regressions.
Backside line: When you don’t completely want a function on your complete app to perform, make the function non-obligatory to make sure your app’s availability to the best variety of units and customers.
Study extra by testing our developer information.