Android Q – The breaking changes

Explore real examples of what happens to some of our Q42 apps from new media notifications and location permissions to navigation gestures.

Android Q – The breaking changes

From new media notifications and location permissions to navigation gestures

It’s party time for the Android community! 🎉 Google has released a lot of goodies for both Android users and developers during Google I/O 2019 and we can start playing with them right away.

But wait, before we all go wild adding new awesomeness into apps it’s good to take a look at the breaking changes in Android Q and make sure our beloved apps don’t break in unexpected and horrifying ways when Q is released. The last thing we want is users being impacted by unexpected bugs.

Actually, the list of changes in Q is so long and boring to go through, that instead of listing every single detail, we will do something more practical. In this blog post we will explore real examples of what happens to some of our Q42 apps — already in production — once Android Q is released.

New style for media notifications

There are quite a few changes in how notifications with MediaStyle behave in Android Q and this directly impacts media players.

The first nice but broken change in the Primephonic Classical Music app is the new media information shown, like the progress bar and track duration.

The solution was simple: update the Media Metadata by setting the MediaMetadataCompat.METADATA_KEY_DURATION to the duration of the track in milliseconds.

Album art looks gorgeous on the phone’s lock screen once we set it on the Media Metadata but now images are automatically blurred, depending on your tastes this can be good/bad. In addition, the track title and subtitle are now shown in the Always-on display screen, much nicer than just the app’s icon.

One last thing, once we target Q the playback foreground service will also require the new type mediaPlayback in the service’s section of the manifest.

New location permissions

Android Q introduces ACCESS_BACKGROUND_LOCATION permission to split the existing all or nothing location permissions. Now, the user also has the power to grant the permission to your app only while it is in the foreground.

We tested two of our apps that require location permissions. The Rijksmuseum app uses location to navigate users through a beautifully complex building. The 9292 app helps users find the most optimal commuting route using the Dutch public transportation system.

Both apps already declare ACCESS_FINE_LOCATION and request the location permission to the user so they both got automatically, in Android Q, the new ACCESS_BACKGROUND_LOCATION granted. Once we target Q, we’ll need to add the new permission to the manifest and show new requests. Happy ending for our apps, they both work perfectly without changes. 😊

Unhappy real story: We use a bike sharing app at Q42 and after updating my phone to Android Q beta3, the next morning I found myself unable to unlock my bike to commute from the train station to the office because the new location permissions break the app! 😱 Moral of the story, don’t make assumptions and test your apps on Android Q!

Start Activity from background is blocked

There are not a lot of use cases for starting an Activity from the background. The ones in our apps involve the user tapping on notifications, both in the Rijksmuseum app when listening to an audio tour or in Primephonic when the user plays classical music in the background.

Tapping on these notifications launches a PendingIntent that is part of the allowed use cases. Happy ending again, no changes in the app, but very important to test these scenarios because it can go wrong!

Unhappy real story: The Firefox app does not start even when the app is started from the launcher by the user. 😟

New navigation gestures from screen sides

The new gesture system to navigate through Android replaces the back button with swipes from the screen sides. This means that apps which previously used gestures on any of the sides of the screen will be affected.

Inside the Rijksmuseum app, there is a section to explore the museum’s collection in detail. You can navigate through a collection using a ViewPager to swipe between the art objects but you can also zoom a lot and pan each image to dig into the art details and discover its secrets.

While an image is in-zoomed, panning the image and swiping to the next art object in the ViewPager will both be recognized based on the area where the swipe takes place (screen border vs the rest of the screen). Using the new gestures navigation system, the problem is that swiping to the next art object will be overtaken by a back navigation gesture and close the screen. 😵

The solution is to use exclusion zones on the sides of this screen containing a ViewPager. An alternative solution is to redesign screens with conflicting gestures to work together with the new gesture navigation system.

Another typical example of this conflict is the navigation Drawer on the side of the screen, if you use the latest DrawerLayout in AndroidX it already supports automatic opt-out behavior.

Dark Theme

Dark times are coming to Android and that’s a good thing. The new Dark Theme mode is designed to save battery and the user’s eyes 🤓 by switching all apps to their dark theme with a quick setting. Our colleague Frank has written a very detailed blog post to get your dark side fixed.

🇳🇱 👋 Hey Dutchies!
Even tussendoor... we zoeken nieuwe Q'ers!

Scoped storage changes

I have left the most interesting for the end: Scoped storage is by far the most controversial change that gives your app only access to a sandboxed part of the file system. As a consequence, Google has decided to give developers the option to opt-out of this change until next year’s release of Android R. To keep this post short, I’ll leave you with a link and video to follow-up on this topic.

Wrap up

There is still a beta 4 planned for Android Q which will include the final APIs and there are many more changes not mentioned here, some well documented and some not. I encourage you to try Android Q and find out which parts of your app are affected. Feel free to share your learnings in the comments so we can all learn from each other. Happy hacking! 🤠

Check out our other Google I/O blog posts on