Enhance your app’s availability throughout gadget varieties

Posted by Alex Vanyo – Developer Relations Engineer

TL;DR: Take away pointless characteristic necessities that stop customers from downloading your app on units that don’t assist the options. Automate monitoring characteristic necessities and maximize app availability with badging!

Required options scale back app availability

<uses-feature> is an app manifest factor that specifies whether or not your app depends upon a {hardware} or software program characteristic. By default, <uses-feature> specifies {that a} characteristic is required. To point that the characteristic is elective, you could 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 characteristic, then an app that requires that characteristic 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 akin to CAMERA or BLUETOOTH (see Permissions that indicate characteristic necessities). The preliminary declared orientations to your actions can even implicitly require {hardware} options.

The system determines implicitly required options after merging all modules and dependencies, so it will not be clear to you which of them options your app in the end requires. You may not even bear in mind when the record of required options has modified. For instance, integrating a brand new dependency into your app may introduce a brand new required characteristic. Or the mixing may request further permissions, and the permissions might introduce new, implicitly required options.

This habits has been round for some time, however Android has modified lots over time. Android apps now run on telephones, foldables, tablets, laptops, automobiles, TVs and watches, and these units are extra diverse than ever. Some units don’t have telephony providers, 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 not ensures that your app will likely 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 could want to at all times seek for a selected location as a substitute.

Banking apps shouldn’t require the gadget to have an autofocusing digital camera for test scanning. They shouldn’t specify that the digital camera have to be a entrance or rear digital camera or that the gadget has a digital camera in any respect! It needs to be sufficient to permit the person to add an image of a test from one other supply.

Apps ought to assist keyboard navigation and mouse enter for accessibility and usefulness causes, so strictly requiring a {hardware} touchscreen shouldn’t be mandatory.

Apps ought to assist each panorama and portrait orientations, so that they shouldn’t require that the display screen might be landscape-oriented or might be portrait-oriented. For instance, screens in-built to automobiles could also be in a set panorama orientation. Even when the app helps each panorama and portrait, the app might be unnecessarily requiring that the gadget helps being utilized in portrait, which might exclude these automobiles.

Decide your app’s required options

You should use aapt2 to output info 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, it’s also possible to test which units are being excluded from accessing your app.

Enhance app availability by making options elective

Most apps shouldn’t strictly require {hardware} and software program options. There are few ensures that the person will enable utilizing that characteristic within the first place, and customers count on to have the ability to use all elements of your app in the way in which they see match. To extend your app’s availability throughout type elements:

• Present options in case the characteristic shouldn’t be out there, making certain your app doesn’t want the characteristic to operate.
• Add android:required=”false” to present <uses-feature> tags to mark the characteristic as not required (or take away the tag solely if the app not makes use of a characteristic).
• Add the <uses-feature> tag with android:required=”false” for implicitly required characteristic resulting from declaring permissions that indicate characteristic necessities.

Stop regressions with CI and badging

To protect towards regressions attributable to inadvertently including a brand new characteristic 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 may monitor all declared permissions and explicitly and implicitly required options out of your closing common apk. This consists of 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 wish to validate. Utilizing launch for instance, create these three duties:

• generateReleaseBadging – Generates the badging file from the common APK utilizing the aapt2 executable. The output of this activity (the badging info) is used for the next two duties.
• updateReleaseBadging – Copies the generated badging file into the principle venture 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 adjustments or dependency updates have brought on the badging file to vary in any manner, CI fails.

When adjustments are intentional, run updateReleaseBadging to replace the golden badging file and recheck it into supply management. Then, this transformation will floor in code assessment to be validated by reviewers that the badging adjustments are anticipated.

CI-automated badging guards towards adjustments inadvertently inflicting a brand new characteristic to be required, which would cut back availability of the app.

For a whole working instance of a CI system verifying the badging file, try the setup within the Now in Android app.

Preserve options elective

Android units are regularly turning into extra diverse, with customers anticipating an incredible 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 operate, in lots of instances they shouldn’t be strictly required, needlessly stopping some customers from downloading your app.

Use the badging output from aapt2 to test 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 test your app’s badging in CI and catch regressions.

Backside line: If you happen to don’t completely want a characteristic to your complete app to operate, make the characteristic elective to make sure your app’s availability to the best variety of units and customers.

Study extra by testing our developer information.