Double whammy: how Android 8 and Play Store kill your apps, new and old

You know that feeling? When you’ve bought a brand new piece of equipment, finding your existing plugs no longer fit your shiny purchase’s sockets?

Well, beware: they’re changing the (software) sockets in the Android House.

From: “Migrating your established app to target O”, presentation on YouTube, by Dan Galpin (Google), July 2018.

If you own an Android 8, about 12% of Android users do, then you may on occasion already have experienced reduced functionality on some of your apps (example). In the coming months, the same is likely to happen to devices running older Android versions, as well.

App upgraded. Performance downgraded.
How come?

In breaching a common software custom, backward compatibility, Android 8 (aka Oreo) takes away something that previous Android apps had, and use a lot. [ It’s background services, especially background location services — more about this later, bear with us. ]

To stay up-to-date with the “latest and greatest”, developers of your favourite apps will routinely re-compile, rather than overhaul, their designs. This is common practice and where there’s backward compatibility, this is fine.

But with Android 8/Oreo, these updated apps may suffer loss of functionality, in particular reduced location functionality.

No, you won’t get a warning and your apps won’t crash.
But some apps may grind to a halt.

To complete the double whammy, Google Play Store has mandated compliance with Oreo, the API that takes something away from us, from August 2018.
This is for newly submitted apps. From November 2018 existing Play Store apps must also target (read: re-architect to) Oreo, even when the update is for something as small as a change of colour or text.

Background services have been a standard programming technique for as long as developers can remember.

But with the introduction of Android 8, “background” has been reduced to a four-letter word. Android has scapegoated background services as bad for memory and battery consumption.
The impressionable press ran with it.

Interestingly Apple don’t share the same angst.
Background services are fine on iPhones and iPads.
In fact, on an Apple device, the user gets to choose if they want the app to perform background operations.
Here’s an example:

Screenshot of an iPhone app offering a background location service. The equivalent no-background version of the Android app has no such dialog.

The premise that “background services are bad, always bad” — is flawed. There are valid reasons to execute certain services in the background.
Only unnecessary background services are bad.

Android & Google are forcing developers to replace a common solution, a developer’s staple, by mechanisms that are more complicated to program. Alternative solutions aren’t very well explained or documented, yet. The few examples we’ve seen in articles and on GitHub aren’t comprehensive.

All over the world, it will cost developers and businesses precious time and dollars to re-master and re-work their apps — just to fit the Oreo mould and to prevent reduced UX that may otherwise result for end customers.

And it’s unlikely to save your battery. A task does not stop consuming energy when you move it from the background to the foreground.

What do you think?

Was it premature for the Google Play Store to break backward compatibility and insist that developers and businesses redevelop existing code to comply with Oreo from August 2018, when only about 12% of Android devices are on Oreo?
Would a better approach have been to offer the new shiny stuff, but also allow existing apps to continue, as they are, for longer?

Do you think Apple will jump on the “background is bad” bandwagon too, and effectively dump background services, the way Android 8 does?

Software developer, entrepreneur, happy mapper.