Improve your app’s availability throughout gadget varieties

Posted by Alex Vanyo – Developer Relations Engineer

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

Required options cut back app availability

<uses-feature> is an app manifest aspect that specifies whether or not your app is dependent upon a {hardware} or software program function. By default, <uses-feature> specifies {that a} function is required. To point that the function is elective, it’s essential to add the android:required=”false” attribute.

Google Play filters which apps can be found to obtain based mostly on required options. If the person’s gadget doesn’t help some {hardware} or software program function, then an app that requires that function received’t be accessible for the person to obtain.

<uses-permission>, one other app manifest aspect, complicates issues by implicitly requiring options for permissions similar to CAMERA or BLUETOOTH (see Permissions that suggest function necessities). The preliminary declared orientations in your actions may also implicitly require {hardware} options.

The system determines implicitly required options after merging all modules and dependencies, so it is probably not clear to you which ones options your app in the end requires. You may not even remember when the record of required options has modified. For instance, integrating a brand new dependency into your app would possibly introduce a brand new required function. Or the mixing would possibly request extra permissions, and the permissions may introduce new, implicitly required options.

This conduct has been round for some time, however Android has modified rather a lot over time. Android apps now run on telephones, foldables, tablets, laptops, vehicles, TVs and watches, and these units are extra different than ever. Some units don’t have telephony providers, some don’t have touchscreens, some don’t have cameras.

Expectations based mostly on permissions have additionally modified. With runtime permissions, a <uses-permission> declaration within the manifest now not ensures that your app might 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 an alternative of giving an app permission to entry the gadget’s location, a person might desire to at all times seek for a selected location as an alternative.

Banking apps shouldn’t require the gadget to have an autofocusing digital camera for verify 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 must be sufficient to permit the person to add an image of a verify from one other supply.

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

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

Decide your app’s required options

You need to use 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 verify which units are being excluded from accessing your app.

Improve app availability by making options elective

Most apps mustn’t strictly require {hardware} and software program options. There are few ensures that the person will permit utilizing that function within the first place, and customers anticipate 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 kind elements:

• Present alternate options in case the function will not be accessible, making certain your app doesn’t want the function to operate.
• 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 resulting from declaring permissions that suggest function necessities.

Stop regressions with CI and badging

To protect towards regressions attributable to 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 instrument in a textual content file and checking the file into model management, you possibly can observe all declared permissions and explicitly and implicitly required options out of your ultimate common apk. This consists of all options and permissions included by transitive dependencies, along with your individual.

You may automate badging as a part of your steady integration setup by establishing three Gradle duties for every variant of your app you need 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 process (the badging data) is used for the next two duties.
• updateReleaseBadging – Copies the generated badging file into the primary 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 about the badging file to vary in any approach, CI fails.

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

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

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

Preserve options elective

Android units are regularly turning into extra different, with customers anticipating an excellent expertise out of your Android app no matter the kind of gadget they’re utilizing. Whereas some software program or {hardware} options is likely to 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 verify which options your app requires, and use the Play Console to confirm which units the necessities are stopping from downloading your app. You may robotically verify your app’s badging in CI and catch regressions.

Backside line: In the event you don’t completely want a function in your total app to operate, make the function elective to make sure your app’s availability to the best variety of units and customers.

Be taught extra by trying out our developer information.