Things to Worry About

For the past several years, each new version of Android represents an incremental change over the previous version. Simply put, there are too many Android users for Android to risk huge changes.

However, even incremental changes may require some amount of response from you as an app developer.

Breaking Changes

The type of change that worries developers the most are “breaking” changes, ones that cause your app to no longer function correctly. Occasionally, this results in crashes. More often, it results in your app just not receiving the data that it expects or otherwise getting what you planned on from the OS.

Examples of breaking changes include:

• Android 6.0’s introduction of runtime permissions
• Android 7.0’s ban on Uri values with a file scheme, necessitating the use of FileProvider for sharing files with other apps
• Android 9’s ban on cleartext (e.g., http) communications, in favor of encrypted (e.g., https) communications
• Android 10’s restrictions on external storage

Immediate Breakage

Sometimes, these changes will affect your app immediately. This is relatively uncommon and usually is not in the APIs that we have covered in this book.

If you find out about such a breaking change, you need to address this before Google ships the new version of Android to its Pixel devices and other manufacturers start updating their devices to match. Even sooner than that you will start running into problems, as some “power users” will be playing with the developer preview builds, even if they are not actually developers.

Eventual Breakage

The more common type of breakage is tied to your targetSdkVersion. When your targetSdkVersion reaches the API level for the new release, then you are subject to the changes. Apps with an older targetSdkVersion would not be subject to the changes.

While this approach has been used for many years, the results have changed recently. That is because Google now enforces a minimum targetSdkVersion for apps on the Play Store, and other app distributors are starting to do the same. Approximately one year after an Android version ships to devices, you will need to have a targetSdkVersion matching (or exceeding) that Android version’s API level. Basically, Google prevents you from shipping an update to your app, or shipping a new app, unless you meet the targetSdkVersion requirement.

The good news is that gives you nearly 1.5 years from the time of the first developer preview before you have to address changes that are tied to targetSdkVersion. The bad news is that developers might well forget what changes are needed by then. Where possible, try to address even these delayed changes as soon as is practical, rather than wait until the last minute.

Stuff Users Will Expect

Sometimes, Google does not force you to change your app, but your users might. That is because sometimes your app may need to be adjusted to allow certain new Android capabilities to work, and users might complain if your app fails to do so.

A good example is Android 10’s dark mode. As we saw back in the chapter on styles and themes, Android 10 offers a “system wide” dark mode that users can enable. In reality, Android 10 only makes system UI dark, plus it tells visible activities about the change. It is up to app developers to actually make a change to support dark mode. Apps that do not do so simply do not change when dark mode is toggled on or off. Some users will complain about that missing capability, and if they complain in highly-visible places (e.g., Play Store reviews), that may have an impact on your app’s success.

Usually, these sorts of user-facing visible features get touted a lot in blog posts and other coverage of the new Android version. If you are paying attention to the new release, you will have a fairly good sense of what users will expect. How easy it will be for your app to adopt that new feature may vary, but you should budget time for it as soon as is practical.