Last week, Android released Beta 1 of Android Q. Key changes include new design language, improvements in privacy and security, and seamless in-app navigation.
It’s still early, but here’s what you need to know.
Inside the Beta 1 Preview
Pulling down the preview, we see that Android Q brings incremental changes to Pie, and will likely follow a release cadence similar to what Google exhibited last Spring and Summer with Pie. On the surface, many of the UI changes that Google has brought to its suite of apps (Messages, Gmail, etc.) have now made their way into the OS, where settings and notifications have taken on the simplified product sans font and muted “Material 2.0” colors. This new design language is intended for Google’s own branding, so it will be interesting to see how many of these updates make their way to third-party devices that launch with Android Q. What this means for app designers: Designs that don’t take Material design patterns into consideration will continue to look outdated. UI designers may also want to consider color palettes that take into account the subtle look of Android Q.
“Designs that don’t take material design patterns into consideration will continue to look outdated.”
Security and Privacy Improvements
As with Android Pie, many of the Android Q feature updates are not necessarily visible to the user, and certainly not after first boot. The beta release of Q extends Google’s focus on privacy and security with location at the forefront of this change. Users can now specify if an app has access only while visible (which also applies to a foreground service) or access anytime (such as an app that provides geofencing). Developers will have to further account for this update to location privacy by prompting and explaining the use of location services in-app.
Another privacy update stems from the misuse of window overlays and background services launching UI, and the Android team has answered. In the Beta 1 preview, the SYSTEM_ALERT_WINDOW permission that has allowed apps to layer windows on top of the display has been rendered virtually useless by requiring users to again enable permission each time the device boots. Apps that have previously used a background service to launch an activity are also blocked from doing so on Android Q. These exact behaviors will likely change as Q matures, but expect the intent to remain the same; apps should not be showing UI without an explicit user action.
There are plenty of other privacy and security improvements, including added support for TLS 1.3, restricted access to wifi configuration, and further support for device-based authentication methods. To learn more, check out the Android documentation.
“Q extends Google’s focus on privacy and security with location at the forefront of this change….”
Seamless In-App Navigation
Beyond protecting users, Q looks to make apps more seamless when it comes to common in-app actions.
The biggest update comes from the new Sharing Shortcuts API. With the new model, users will no longer have to wait for sharing options to load. Apps can declare a share-target in their manifest that will show when a user goes to share in-app.
Additionally, these share-targets will show as launcher shortcuts. Seamless app navigation continues with Q’s new settings panel.In the case where an app needs the user to connect to a certain network, enable bluetooth, or change alert volume, the app can surface a panel on top of the app that allows users to make that change without navigating deep within settings, only to then try and find their way back to the app that triggered the intent. There are several more nuanced improvements that come around autofill, added support for accessibility, and hung webviews. I also imagine we’ll see more here as subsequent previews come out.
Odds are good that apps targeting Android Pie will upgrade easily to target API level 29. If you’re not sure, contact us. We’ll make sure your app is ready for the next Pixel devices and Android Q.
What Else You Need to Know
Important Android ecosystem changes that will also affect app usability:
- In April 2019 Google Cloud Messaging (GCM) will be sunset in favor of Firebase Cloud Messaging (FCM). At this time, clients using the old GCM SDK and token will continue to work, but will not be able to target the latest from Play Services. Backend developers will need to implement FCM’s API.
- As of August 2018, all apps in the Google Play Store had to target SDK 26 (Marshmallow) or higher. On August 1st of this year, new apps will have to target SDK 28 (Pie) and existing apps in the Store must update by November 1st to stay listed.
- After Google’s purchase of Crashlytics, it was announced that crash reporting features would be migrated under the Firebase app suite. At this time, events can be viewed from both the Crashlytics platform and Firebase console. Following Fabric’s roadmap, we expect to see a new Crashlytics SDK to implement in a few months. Seemingly brisk, the roadmap also says that the existing target will be sunset by the end of the year.
- Coming this October, Google Analytics will sunset their mobile client SDKs, at which point new data will stop making its way up to Google’s service. Then in January 2020, the console and APIs used to access data will be turned off. Google has offered Firebase Analytics as a replacement.
By recent counts, Android makes up 42% of the US’s smartphone market, and a whopping 74% worldwide. In addition, Google has made notable improvements to OS adoption, with the majority of its users on Marshmallow or higher. With this type of growth, it’s critical to stay on top of these changes. Contact us. Defy ordinary, create extraordinary.
Matt Wood is a senior engineer specializing in Android development at Smashing Boxes. When he’s not building apps, his ambitions look in the direction of IoT and FinTech.