Android Q: the bad and the ugly

Written by Mark Vletter on 31st May 2019

With every release of a new Android version, we see the tech blogs and YouTube videos about all the new sparkling features that this Android version will bring. But as developers for Vialer, a calling app for businesses, we look at the newest release with a different set of eyes. To us Android Q in its current state feels like one step forward, two steps back. With this article, we will show why we feel this way and hope to start a conversation about the effect of Android Q.

Android’s many challenges

It has always been challenging to develop for Android:

  • There is a huge Android version diversity with many different devices with different screen sizes.
  • Not every phone brand enables the same features within an OS so some API’s or complete feature sets might be available on a Pixel, but not on a Samsung device.
  • Every brand adds their own sauce and features to the Android experience. One Plus, for example, adds battery optimization which basically kills every background service running except the ones they choose to allow.

Improved security and privacy

Android Q takes a big step to improve security and make updates to the OS much simpler by pushing them via the Play Store. Q also adds a lot of privacy features, which we find very valuable. Unfortunately, in doing so, they make decisions that break apps, and give the end user less control over their device. Let us highlight this with two examples we as developers run into.

No more call screen

It’s currently possible for background services to push a user interface over the native launcher or screen. This is used by apps like WhatsApp, Signal, and our own Vialer to show a call answer screen on an incoming call.

However, this feature was also abused by other apps to push non-urgent information. Instead of improving the feature, Google decided to remove the option from Android Q completely.

With the new Android version, the only way for a call coming from an app to be answered is to push a notification. This gives the user some basic call answer or decline options. For more advanced things you would have to unlock the phone and open the app.

Going back in time

The method described above is similar to how this feature worked on iOS… back in 2015. That’s why three years ago iOS launched CallKit. It enables better non-essential services and enhanced the user experience.

Google did do something with the developer feedback they received. The Android Q page confirms it will become a permission giving the user control over this feature. However, this is not your regular permission. The app has to guide the user to the Android setting where the user has to enable it themselves. It’s weird that they break so many core apps and put Android years back, instead of improving the OS and moving forward by doing something they think is beneficial to the user.

No more WiFi toggle

Another feature Google is removing is the option to toggle the WiFi settings. WiFi has major security issues. WiFi hotspots can be faked, something hackers gladly abuse to gain access to the data that’s being sent over this fake internet connection. WiFi is also used to track people’s movement in cities and stores which is a big privacy issue, where Android has introduced a feature to bring some of it back. That’s why there are apps that enable or disable WiFi based on your location so it’s only active when you’re at home or at the office.

There are also apps that simply work better over 4G because it’s more reliable, has a lower latency, or for other reasons. These apps toggle the WiFi setting for better performance. They often make the fact that they do this very clear to the user in their onboarding process.

So in removing this option, Android breaks a lot of apps and makes your device less secure and less private. Where Android Q is marketed as a big push for security and privacy, Google removing the WiFi toggle feature actually makes both worse!

Don’t kill my app

And then there is one thing Android Q is not trying to fix. Android 6 introduced better battery optimization, but some vendors have gone overkill with this. They are killing apps and their background services without the user’s permission (I’m looking at you Nokia and OnePlus). This breaks every real-time app, messaging app, fitness app, or location tracker, to name just a few examples of the things that don’t work. Dear vendors and Google please… stop killing our apps!

Let’s start the conversation

Android Q means well. Google is doing things in the name of security and privacy. However the choices they make in Android Q are so black and white, that for a lot of use cases it does more harm than good. With Android Q, instead of improving the user experience, the user is in these use cases actually worse off.

While we support progress in the name of security and privacy, we see that these changes do hurt a lot of good apps that really depend on those notifications and permissions. Are you a developer that runs into the same problems as we do? How do these changes affect you? Let’s start a conversation about making the changes in Android Q less black and white and more situation based. Let us know your thoughts at hello@wearespindle.com or in the comments below!

Your thoughts

  • Written by Roderick Rose on 1st June 2019

    The end user is in the scheme of things the unpaid lab intern. Companies say trust us, user asks why.

  • Written by ParallelAxiom on 1st June 2019

    Same experience here.

    SAF send to also going to break a ton of existing apps.

    Google has done similar things in past releases and this is just the way you have to submit to a monopoly.

    Would it not be much better if Android, and the play store would be governed more like a open source Linux distribution ?
    I think Huawai would also agree.

  • Written by Cezer on 6th June 2019

    That background services restriction is such a huge bummer — plus the huge discrepancies between different manufacturers just keeps getting worse with every new Android release.

Devhouse Spindle