https://blog.hedgehoglab.com/android-p-google-play-changes


As we get into the swing of 2018, attention is starting to turn towards what the next version of Android will bring, and what we can expect to see from Google. If the past few years is anything to go by, we can expect the first developer SDK preview to drop between the middle and end of March, giving us an insight into the new features and capabilities of the upcoming Android P release.

 

Yet despite remaining over a month away from a first release, Google has already started detailing some of the bigger changes this year to ensure that developers have enough time to prepare. One of the most unexpected of these, is an upcoming change to the rules of uploading new and updated applications to the Google Play Store.

 

 

Android Oreo Developer Preview Release Schedule, Google 2017

 Android Oreo Developer Preview Release Schedule, Google 2017

 

Compared to iOS, the Google Play Store has always been more of a free-for-all with minimal barrier to entry. Back when it was known as the Android Marketplace, all that was required to was a developer account and an APK to distribute. In the past few years, Google has been clamping down on malicious apps, and preventing those which either pose security risks, or breach the terms of service, from ever reaching the store in the first place.

 

Now, for the first time, Google is implementing a minimum requirement for the SDK version that apps are targeted at. It is worth pointing out quickly that this does not affect the versions an Android app can support, but instead refers to the version of Android that an app is targeting. When building an Android application, there are up to three values which determine what versions of the Android OS it will run on. These are the minimum, maximum, and target SDK versions.

 

The minimum SDK version is the lowest version of Android that your application supports. If you have a device on lower than this, you will be unable to install the app. Most apps developed today tend to set a minimum SDK version between Android 4.1 (API 16) and Android 5.0 (API 21) which covers between 95% and 83% of active devices respectively. Google does not, and has never had rules defining what this value needs to be. As such, a developer could set the value to API 1 and support every device, or to API 27, only supporting devices on the very latest version. The maximum SDK version is the counter opposite to this, as it sets the highest API level an app will run on. It is rarely used, however the most common use case is to drop support for an app that relied on a deprecated OS feature.

 

 

A pie chart illustrating usage of different Android versions.

 Minimum SDK versions are often defined by the current version distribution, Android Dashboard 2018

 

The target SDK version is the most interesting value for developers, and this is what the new Play Store rules are fixed on. This value informs the system that the developer has updated and tested their application against the specified version. If the device is running a higher version of the Android OS, then the system will provide backwards compatibility behaviours. This allows Android to implement breaking changes (alterations which could cause other components to fail) to their platform, but ensure there is no mad scramble to update applications to handle such failures, as by default apps will simply work as they did before.

 

The simplest example of this was when Google added runtime permissions to Android 6.0 (API 23). This allowed users to granularly accept permissions whilst using an app and as a permission was required, as opposed to granting them all at installation time. In order to handle this transition, Android used the target SDK version to determine whether or not your app supported runtime permissions. If your app had a target version of 21 (Android 5.0), then it indicated to the system that runtime permissions were not supported, and that the user therefore had to accept all permissions when installing the app. Once an app updated the target version to 23 (Android 6.0), the developer would be required to implement runtime permission requests, else the application would crash when an attempt to use a system permission was made.

 

This freedom is great for developers. If, for example, an old application requires a small bug fix, this can still be updated without having to catch up with all other platform changes since its original release. That said, it’s not great for either Google or end users. API updates always have a strong focus on improving security and performance, and without a push to keep updating the target SDK version, apps often take a long time to get updated with the latest power-saving and security features.

 

An Android logo featuring a target on its chest.

It’s an Android target, what more do you want, Techtudo 2011

 

So what is changing? In relation to what will be accepted onto the Google Play Store, Google has made their intentions quite clear to developers. In essence, by the end of 2018 apps must be targeted to the previous major Android release. By August 2018 all new applications submitted to the Google Play Store must be targeting Android 8.0 (API 26), and by November 2018 updates to existing apps must also target the same API level. Following this, upon the release of a new Android dessert version, the requirement will advance to the previous major version.

 

With this, by the end of 2018 all recently updated apps on the Play Store will need to be targeting Android 8.0 (API 26), whilst by the end of 2019 they will need to target Android 9.0 (API 28), and so on. For now, this restriction will only exist within the Google Play Store. For alternate app stores, or when privately releasing applications this will not apply. However, after this change, Google has reserved the right to restrict apps that do not target a recent API level within the Android SDK itself. We do not know what form this will take, but eventually, regardless of their distribution mechanism, all apps will require recent target API versions.

 

For a lot of newer applications, the impact of this change will not be felt for a while. New apps are typically developed targeting the latest Android version. If the app is developed targeting the latest developer preview, then this gives around 18 months of notice between the SDK version becoming available, and that version being enforced by the Play Store. Older applications however, will start struggling sooner.

 

Although apps currently on the Play Store will continue to work by using compatibility for the SDK version they are targeting, and Google will not be removing older apps from the store, the new SDK requirement may discourage developers from updating their old apps if it becomes too much work to support API changes each year. Additionally, this change may be felt heavily in either long-term support contracts, or by larger companies that previously have had control over what they update and when.

 

A pie chart showing the results of arsTechnica's API 2015 Survey, showing 24% of apps wouldn't meet Google's new update requirements.

 

arsTechnica's 2015 API survey suggests 24% of apps wouldn't meet Google's new update requirements. 

 

It is not yet clear how much of an impact this change will have on the Play Store over the next few years. Android OS updates tend to have very few breaking changes, partially because a lot of the system has been extracted to support and service frameworks, but also because of the current maturity of the platform itself. The amount of changes required to bump up the target SDK version of an app is also heavily dependant on what the app does. Upgrading to Android 8.0 (API 26) for example, could require as little as defining notification channels, but could equally require completely rewriting how your app behaves in the background as per new background execution limits.

 

Despite the additional burden this change will bring in, the goal behind it is to reduce fragmentation within the app ecosystem, and to ensure that users are downloading apps which are secure and performant for their device. Google believes that between 12 to 18 months is a long enough window for app developers and organisations to plan ahead for upcoming releases. Now users just have to hope that the developers for their favourite apps agree.