Android Q is rolling out with a lot of changes this year. If you are responsible for an Android app, there’s a good chance it will be impacted when the new version of Android starts rolling out to smartphones in August.
We advise app owners to be proactive about maintenance and ensure your developer tests your Android app against the updates before your users are impacted. Being proactive buys you time to fix issues in advance of the Android Q (10) release.
The consequences of not doing so can be severe and long-lasting, as the changes may cause your app to cease to function as intended.
This article will explain what changes you or your developers might have to make to keep your app working with the new operating system.
1. Scoped Storage
Google wants to improve privacy and has made it so apps that access external storage (i.e. files that are stored on the /sdcard path where they are visible to the user, rather than in the app’s data directory) will get what Google is calling a filtered view.
Now apps will only see the files that the app has written, and not files written by other apps. These files have sandboxed to protect Android users from rogue apps that may read or write to files that users were unaware of them having access to.
This behavior may be changed over the course of the beta of Android Q, and how it will be finally implemented is fluid, but expect to lose access to files that are not in your sandbox — if not in Android 10 in the next version.
This mainly affects apps that view images, audio and video not created within the app. If you access users’ images, audio or video files you will want to switch to using the MediaStore rather than direct access to the photos, video and audio directories.
2. Background Location Access
Background location access has changed again. If your app uses background processes this will be a familiar refrain for you, in that Android has over the past few versions become more restrictive in allowing the launching of background applications.
Once again, this is a privacy and battery usage improvement feature.
If your app does things in the background, mainly when the app is not the foreground app, you should have your developer audit the background service and make sure it is conformant with the rules required.
Furthermore, if you get location information from a background process, that process has to be started by a foreground application at some point. New permissions (ACCESS_BACKGROUND_LOCATION) must also be added to the app.
3. Photo Metadata
The data embedded within a photo (known as Exif Metadata) can be as banal as whether the image is portrait or landscape, what camera it was taken on or whether a flash was used, but also contains private information such as GPS markers pinpointing where the photo was taken.
If you are using that GPS information, and your app did not take the photo (i.e. you’re using photos from the users’ photo library) that GPS data will be stripped when you get the photo.
4. Dark Mode
While the above changes are mostly about privacy and battery usage, the dark mode theme is about keeping Android up with the Joneses (though with some OLED devices it might save a little battery). iOS, MacOS and Windows all have a dark theme mode now.
If you have already created a dark theme for your app, supporting the OS preference for dark mode will probably be relatively easy (depending on how you have themed your dark mode).
If you haven’t gone to the trouble of building a separate dark theme, Android allows you to mark your theme as being allowed to “ForceDark” where an algorithmic dark mode is applied to your current theme.
If you choose this quick and dirty method of creating a dark mode, you should test all of the screens in your app on several devices to ensure the algorithm hasn’t obscured some text or graphical element.
5. Other Minor Changes
Another minor change is that the Mac Addresses are now randomized. If you were using the Mac Address to provide any kind of unique identification it will no longer work.
Accessing the device’s serial number and IMEI requires a new permission. If your app needs to uniquely identify users it must use the APIs to get a unique application instance identifier. This is a unique identifier for the app running on that device, and cannot be used across applications on the device to identify the user.
The drawback of an application instance identifier, however, is that if your user uninstalls the application it will get a new application instance identifier when the app is reinstalled.
My assumption is that you will soon need to prove your need for the serial number or IMEI (the same way you have to prove your need for phone or SMS access), or usage of such APIs will cause your app to be blocked from the Play Store.
You are also now blocked from accessing the clipboard unless you are a keyboard app or your app has focus, for obvious privacy and security reasons.
6. Targeting a Recent Version of Android
Although unrelated to Android Q, as of last year Google forced apps to target the recent version of Android.
If you’re updating your app as of June 2019, you must target at least 8 (Oreo), and starting November 1st you must target Android 9 (Pie).
Google has not yet announced when Android 10 will be the required target for the Google play store, but it is safe to assume that it will be sometime in 2020.
If you have not updated your app in a long while here is a quick rundown of what you must support (and which version that support was required for):
- Runtime permissions rather than permissions when installing (From Android 6, Marshmallow)
- Handle Doze and Standby restrictions (From Android 7, Nougat)
- Background Execution Limits (From Android 8, Oreo)
- Privacy, Android ID will change when the user upgrades their device from any previous version to Android 8 (From Android 8, Oreo)
- Power Management – limit usage of deferred jobs, alarms and adds quotas on high-priority messages (From Android 9, Pie)
- Privacy Changes, Limited sensor access, limit access to Call and SMS Logs, limit access to SMS and Phone unless it is primary function of app (From Android 9, Pie)
7. Android X
Another fairly major change, announced at Google I/O in 2018 (last year), is that the Android support library was being reorganized, refactored and branded into Jetpack/AndroidX.
While Google has claimed that switching to AndroidX is supposed to be trivial, in my experience it has proved more time consuming than expected in the real world.
However, if you don’t move to AndroidX you will not get updates for these libraries (including security and bug fixes) when you update your application. So that is some technical debt you may wish to pay down sooner rather than later.
8. Kotlin
Kotlin is a newish language that has started to supplant Java as the language to write Android Apps in.
It features a much more terse, and at the same time more readable syntax, and some built in language features that provide a lot of compile time bug detection. Thus, your programmers find the bugs before your users do.
It has become the preferred language of Android at Google (with their new “Kotlin-First” initiative) and new apps should consider being written in Kotlin rather than Java as Java apps might start becoming legacy apps in the future.
