Google fights fragmentation: New Android features to be forced on apps in 2018

While Apple’s app store is heavily regulated, the Google Play Store has mostly lived its life under Google’s laissez-faire attitude. As long as you didn’t get caught by Google’s malware scanning, your app was free to do just about anything.

But lately, Google’s hands-off approach seems to be changing. The company tried to restrict Android’s powerful accessibility APIs only to accessibility apps, but after a power user revolt, Google is currently rethinking that plan.

The Play Store’s biggest change is coming in 2018, though. Recently Google announced it will start setting a minimum API level that new and updated apps will be required to use. Basically, Google will stop accepting old app code from developers. The move won’t harm support for devices running old versions of Android, but it will require developers to adopt new Android features and restrictions as they come out.

Every new version of Android comes with a new API level, which changes how the app framework functions, adding new features, new restrictions, and new security measures. Currently, developers can opt out of these changes by just using an old API level, but soon they will be forced to target recent API levels. This will accelerate Google’s Android changes throughout the app ecosystem, rather than having to wait years and years for it to happen naturally through Android’s incredibly ineffective OS update program.

All Android apps must set two API levels internally: first is the “minimum” API level, which determines the oldest Android version the app will run on, and then there’s the “target” API level, which is the highest version of Android that the app is aware of. Every new version of Android bumps the API level up one version, and currently Android 8.1 is on API level 27. When Google changes the way the Android app framework works, it doesn’t want to break old apps, so it locks this functionality behind a new target API level.

For instance, in API level 26 (Android 8.0), Google changed the way background tasks worked by turning off many power-hogging background processing features for apps and requiring them to use a more restrictive API. In API level 23 (Android 6.0), Google added à la carte permissions, allowing users to block apps from accessing certain device functions. These changes are good for users but more restrictive for app developers, and they require work to implement. If a developer wanted to be a greedy device hog, they could just decide to not target the latest API level, and these restrictions would not apply to them. The ability to use an older API level is meant to be a backward-compatibility consideration, but developers can abuse the feature if they are greedy, lazy, or malicious.

Previously, Google used a “carrot” approach to getting developers to target the latest API levels. If you want access to that sweet new fingerprint API in Android 6.0 or the Vulkan Graphics APi, you’ll need to target the latest version! Newer versions also come with a host of requirements and restrictions to make your app a better smartphone citizen, though. New API levels haven’t had much in the way of enticing developer features, though—they’ve mostly been things that are good for users, like less background processing, stricter permissions, controllable notifications, and design conformancy features like adaptive icons. These are work for developers to implement, and while they benefit the user, they don’t help developers. The carrot approach looks like it’s going away and being replaced with a stick. Google says “Update to a newer API or never update your app again.”

Speeding up ecosystem adoption

Google has published a timeline for mandatory API level adoption. Generally, API levels that are a year old will become mandatory for new and updated apps. This will begin in August 2018, when targeting API level 26 (Android 8.0, released August 2017) will be mandatory for new apps. A month later, the requirement kicks in for all app updates.

Requiring all new and updated apps to use an API level that is a year old will speed up API adoption across the Android app ecosystem. We last took a survey of the top 200 non-game apps in late 2015, so we actually know what natural API adoption speeds look like. Shortly after the release of Android 6.0 (and a lengthy developer preview period), only five percent of the top 200 apps targeted the latest API version. 41.5  percent targeted the previous API level, which was seven months old at the time of our survey.

If we look at the top 200 apps that target an API level that was a year old or newer, which will be the new minimum requirement in 2018, it was only 78 percent. If we assume the top 200 apps are regularly updated (and they are), Google’s new requirements would bump this to about 100 percent.

Keep in mind, these are just the top 200 apps, which are all made by competent developers that (I guess) represent the best Android has to offer. The other 2.5 billion apps are probably less well-maintained. Today, there are some notable exceptions in the top 200. Facebook still targets Marshmallow, API level 23. This is two years old and allows the company to dodge Android’s new background processing requirements, meaning the Facebook app can run in the background all the time, if it wants. Snapchat uses API level 22, which is almost three years old and allows the company to skip Android’s à la carte permissions. This means, just to install the app, you have to approve a ghastly brick of permissions, giving Snapchat your identity, contacts, location, photos, microphone access, device ID, and more. Why would these companies want to upgrade and give up this access?

Security benefits and faster API deprecation

Setting a minimum floor on the API level should help with security, too. As we’ve written about time and again, Google’s malware scanning isn’t perfect, and sometimes malicious apps end up in the Play Store. Sometimes they even get millions of downloads! If you were going to write a malicious app that aimed to defeat Google’s built-in malware scanning, you certainly wouldn’t target the newest API level. You’d use an older version with fewer restrictions on the app, allowing you to wreak more havoc and steal more information. Now, malware writers will be limited to APIs that are a year old or will have to trick users into installing the app off the Play Store.