This year I was lucky enough to attend Google I/O in person. Needless to say, a lot of information was released in three days, and it’s sometimes hard to filter what’s actually relevant to your day to day work. So, in this post I’ll try to highlight the big upcoming changes discussed or announced at Google I/O this year that will impact Android developers.
But first let’s cover some of the main recurring themes I noticed through the conference:
- Google Assistant: Google is really pushing developers to include Actions for the Assistant in their apps. They’re also investing in making the assistant available through multiple channels and smarter than the competitors (Alexa / Siri).
- Feedback: The Android team is keen to get as much feedback as possible and is actively listening to the developer community. They’ve been releasing a number of new products and libraries in early alpha just because they want to get as much feedback from the community as possible before finalising them.
- Opinion on architecture: The Android team now has an opinion on how to structure and architect Android apps, and they’ll keep working on it. This is not necessarily the “right way” to build an app (also because there’s no “right way” to build an app), but it will offer guidance and new tools to developers. The rationale is explained here: Guide to App Architecture.
- Multi-platform: Google wants their tools, frameworks and products to be used across platforms and they’ve been putting a lot of effort into it. Some examples are Material Theming and the Firebase Test Lab, both available to iOS developers.
While the official name hasn’t been announced yet, we got to know a bit more about Android P. For example: why is the time now displayed on the top left corner instead of the top right corner? (Answer: because of “balance” and the top notch some vendors are adding to their devices)
There are going to be more details about the changes coming in Android P later in the post. For the moment just know that if you have a supported device you can download the beta version of the OS from this link: Android P Beta. I’ve used it for the past few days and it seems to be stable enough for everyday use.
Some of the new gestures might take some time to get used to. The biggest change is probably the swipe interaction on the home button, but this is disabled by default. To enable it you can go to “System > Gestures > Swipe up on home button”.
Android P also officially adds support for screen cutouts. Cutouts seems to be popular in this year’s high end devices so you might want to review your app to verify how it handles them. (Remember when Android devs were making fun of the iPhone X top notch?)
From what I could see, most of the code samples used during the conference were in Kotlin. Googlers keep praising the newly supported language (rightly so) and encourage developers to pick it up if they haven’t already. It’s safe to say that Google is definitely committing to Kotlin for the long run.
During I/O a new set of KoTlin eXtensions (KTX) was announced. These extensions improve the framework APIs when working on Kotlin. More details in the session hosted by Jake Wharton: Android Jetpack: sweetening Kotlin development with Android KTX.
More than 50% of the sessions I attended mentioned Android Jetpack. Jetpack is a new set of tools, frameworks and guidelines from the Android team to support Android developers. This initiative contains all the libraries we’ve used in the past, like the Support Library and Architecture Components, and more. Details about the project and the full list of libraries can be found here: Android Jetpack.
The Support Library is going to be refactored and renamed. And by renamed I mean: new name, new dependency name, new package name, new versioning, etc. A complete rebranding.
This will require some changes in existing codebases, eg. updating all the import statements and the gradle build files. The old package names including the supported version number are now gone and are replaced by androidx.. The version number will be reset to 1.0.0.
Some artifacts will also be repackaged to be smaller and make sure that you can import only what you’re actually using.
The Android team is providing a semi-automatic migration tool that should simplify transitioning an existing app from the old support libraries.
More details can be found here: Android X.
WorkManager replaces JobScheduler and a few other APIs available before it. It should be the go-to API for executing long-running tasks with guaranteed execution.
A very good session on when and how to use it is Android Jetpack: easy background processing with WorkManager. Otherwise more information can be found here: Schedule tasks with WorkManager.
The new Navigation APIs simplifies Fragment management within an Activity. It handles transactions, flows and back stack.
As you can imagine, this requires your app to use Fragments where appropriate. After asking the question to a few Googlers my understanding is that we should be using one Activity per potential entry point to our app (or main flow). The flow within that Activity should then be managed with Fragments. Some very simple apps might rely on a single Activity, like in the example provided by Google, but most will probably have at least a couple.
There have been a few sessions on the new Navigation library and the related tools coming in Android Studio, the following one gives a good overview: Android Jetpack: manage UI navigation with Navigation Controller.
The new Paging library helps to support pagination by loading data in batches on a RecyclerView. More details here: Paging library overview.
Slices are new UI elements that allow you to display content within the Google Search app and the Google Assistant results. Slices must respect some predefined templates, but are still customisable in some measure. More details here: Android Developers Slices.
A new version of the ConstraintLayout was announced and the Android team seems to strongly recommend it over other layouts in most scenarios. I really recommend to watch a couple of minutes of Modern Android development: Android Jetpack, Kotlin, and more (20:10), but here’s why ConstraintLayout is preferable over other options:
- AbsoluteLayout: Not really useful… Deprecated.
- LinearLayout: Nesting can cause a performance and readability problem. But can still be useful for simple use cases.
- FrameLayout: Not very flexible. OK for very simple use cases.
- GridLayout: Overcomplicated, and no tooling support!
- RelativeLayout: Quote “ConstraintLayout is a relative layout that works”
- ConstraintLayout: Very flexible and well supported by the tools. Recommended for most use cases.
For more information on the new version of ConstraintLayout refer to this talk: What’s new with ConstraintLayout and Android Studio design tools.
Material Theming expands on Material Design to make it more flexible, addressing probably one of the biggest complaints about the guidelines: rigidity. It allows for more customisation of the UI elements, specifically around shapes, typography and color use. All the details can be found at material.io.
From a development perspective there are new components being provided within the Material Design Components library that can be found here: Material Components Android GitHub. This library is basically a rebranding of the “old” Design Support library and will become the reference point for sourcing Material compatible widgets. The library is currently in alpha.
Google has also released two new tools that have been used within the company for a while: Gallery.io and Theme Editor for Sketch. Gallery.io is a web app very similar to Zeplin.io that allows designers to export finalised designs from Sketch in a format that is easy to consume for developers. The Theme Editor is a desperately needed plugin (so desperately needed that we were building one internally) to simplify theming and easily work within the boundaries of Material Design on Sketch. The Theme Editor can be downloaded from here.
Google keeps pushing Material as a multi-platform design language. A lot of emphasis was placed around the fact that these guidelines are not platform specific and all the provided tools and libraries work for Android, iOS, Flutter and Web.
Resources are still limited on mobile devices, and they probably always will be. Data, storage space and battery are precious, therefore it makes sense to do our best to limit the use of these resources as much as possible.
Dynamic Delivery tackles this problem by packaging the APK at download time. The Play Store will detect the type of device, then package, sign and download a version of the APK than includes just the required resources (eg. Assets).
This means that the app is not uploaded as an APK to the Play Store, but as an App Bundle. App Bundles also have a new file extension: .aab.
In order to enable App Bundles your app has to be properly configured and divided in packages. The requirements are described here: Configure your project for dynamic delivery. You might also need to review your CI pipeline to build App Bundles instead of APKs.
More details on Dynamic Delivery and App Bundles are available here: About Android App Bundles.
Android Studio 3.2
The new release of Android Studio is currently available as a preview and can be downloaded from here: Android Studio Preview. This release includes a number of tools to support Jetpack libraries, but also other nice additions. The full changelog for this version is available at the same page.
The Layout Editor has been updated with new capabilities. The most interesting one is probably Sample Data. As the name might suggest, Sample Data allows you to manage lists, key/value pairs and all sorts of sample data in resource files to be used within the layout editor. There’s also a collection of predefined datasets in the IDE!
This allows developers to define a sample dataset once and then reuse it across multiple layouts. Making the layout editor way more powerful. For more information refer to this talk: What’s new with ConstraintLayout and Android Studio design tools.
The Navigation Editor works in tandem with the new Jetpack Navigation API. It allows you to organize your Fragment based screen flow with a powerful UI tool that resembles the XCode storyboard. Note that each Activity will have a separate navigation diagram. More info can be found here: Implement navigation with the Navigation Architecture Component.
This is an important one. Starting August 2018 all new apps submitted to the Play Store will need to target API 26 or above. Starting November 2018 app updates will be accepted only if they target API 26 or above. So, if you haven’t already, start updating your app to target API 26.
More details in this session: Migrate your existing app to target Android Oreo and above.
With Android P a lot is changing in regards to security. I highly recommend watching the “What’s new in Android security” session, but here’s a quick recap.
Some Android P devices will provide a new keystore named StrongBox. StrongBox is hardware backed and guarantees key security even on rooted devices. Any high security apps would want to leverage this new functionality.
For Android P devices that don’t include the required hardware or devices running an older version of Android we’ll still need to rely on the TEE (Trusted Execution Environment), or as a last resort the framework provided keystore. For more information: Hardware security module.
BiometricPrompt is a new API that should simplify requests for additional authentication from within an app, for example to authorize an high value transaction. It replaces the FingerprintManager and is available in the support library, so it can be used pre-P. For more information: Unified biometric authentication dialog.
Sensor access will be restricted on Android P for apps running in the background. Apps that require sensor access while in the background are now forced to use a foreground service. More details here: Input and data privacy in background apps.
TLS By Default
On Android P TLS is required for every network request. The framework will throw an exception for any request to an unprotected domain. Developers can opt-out from this security measure for explicit domains by adding a line to the security config XML, but it’s clearly not recommended.
If you have an app making plain http requests you might want to start looking into adding TLS protection to those endpoints. For more information: Protecting users with TLS by default in Android P.
Android Protected Confirmation
Android Protected Confirmation is a new security feature that allows apps on supported Android P devices to authorize high value transactions (eg. fund transfers) by running a system component in a protected execution environment composed of dedicated RAM and CPU. This grants increased security. For more information: Android Protected Confirmation.
If you are looking for a less Android centric view of what was discussed at Google I/O the main event site has a recap section.
So, keeping in mind that most of what’s been released is in alpha or beta, what should you worry about right now?
- Update target SDK to API 26
- Verify if your app works with restricted sensor access in the background on Android P
- Add support for displays with cutout
- Convert Http requests to Https
- Migrate from GCM to FCM for push notifications (not announced at I/O, but still relevant)
- Start thinking of structuring your app for App Bundles
- Start using the new tools provided with Material Theming
- Use Kotlin if you get the chance!
Finally, If I had to choose just three sessions to watch (other than the keynotes) I would probably choose the following:
- What’s new in Android
- What’s new in Android security
- Modern Android development: Android Jetpack, Kotlin, and more
I hope you’ve found this post useful. if you have any feedback please get in touch!