I/O 2019 Android Track Picks & Insights

Google I/O is a wrap. The conference celebrated product and platform innovations at Google. As part of the Google Developer Expert programme a group of us travelled to I/O and enjoyed learning together, here we want to share some of our top moments and sessions from the event.

This is just a snippet of what went on at Google I/O 2019, you can find a playlist of all the 177 sessions!

What’s New with Android for Cars

Paul Blundell (Android GDE @ Novoda)

Google I/O has three types of talks; hands on coding, developer deep dive and product sales pitches. This was the product sales pitch type. Most of the time that’s a bad thing (when you just want to know how to code the thing) but they’re really good talks for when you are exploring a new area and what to know the high level product concepts. This talk explained how the Google Assistant is coming to the car interface, hinting that it’ll likely consume Android Auto as it currently stands, and also explaining how original car manufacturers are starting to use Android for their infotainment systems.

This was interesting as it explained how car manufacturers are embracing a version of Android AOSP to run the infotainment in their cars. If you are familiar with Android Auto and how it is locked down to a specific subset of apps, Android Auto OS is no different – however each manufacturer can decide to share key information about the car. This is the cool thing! It’s the door opening to the unlocking of potential around showing climate controls, car speed and other information.

Watch this space, Google are on a mission for mass market share in the car space, they know the car manufacturers are screaming for a standardised platform to run infotainment, and if Google manage to pull it off, each car manufacturer could be running Android. If you are interested in this space (like me), it’s a good bet to start to learn more about AOSP, building your own Android fork and learning the subtleties of custom ROMS. (And an interesting side note, forking AOSP is exactly what the Android JetPack compose team are asking you to do if you want a sneak peak of what they are up to…)


I really enjoyed the ‘community lounge’ at Google IO, this was a space for all the different collaborations Google gets involved in, to meet up and talk (GDG’s, GDE’s, Meetups, Udacity, etc). I noticed they had feedback posts, and having a peek inside they were raspberry pi’s and speaking to some Googlers there, they run AndroidThings, maybe there is hope for the platform yet. 😉

Customisable Delivery with the App Bundle and Easy Sharing of Test Builds

Edward Woollard (Android Engineer @ Monzo Bank)

Google has continually been working on improving the Google Play Store in recent years and with that work, we’ve been brought some lovely new features to help us with delivering our app builds to users. We now have in-app updates, conditional delivery, on-demand delivery and asset delivery. I’ll explain more about what each of these are and how exactly they can benefit you, with a specific example per feature. Since asset delivery is for games, I’ll focus on the first three for now.

One thing to note is that all of these new features build upon using app bundles which you should definitely check out if you haven’t already. They are now the official standard for how to ship Android apps  through Google Play, but the essential difference is that Google now can handle APK generation and signing for you…you just provide the code.

First off we’ve now been blessed with in-app updates. Have you ever had a time where you’ve had to critically fix a bug and want to ensure all users have this latest app version, or maybe you’d like to retire an old version but are conscious of leaving those users in the lurch? Previously we’ve had to rely on users installing updates, whether that be manually or waiting for automatic updates to rollout, but the main issue still remains…we cannot guarantee that the user has that latest version before using the app in a particular session. Now we have a first party solution to easily tell if there’s a new app version available, and if we so wish, require that new version is installed before the user can continue using the app, all without even visiting the Google Play Store. What’s more is that the solution I’ve just described is known as ‘immediate in-app updates’ but they’ve also provided ‘flexible’ ones too if you want to allow the user to update to the latest version inside the app whilst still being able to carry out other actions. Obviously in a lot of cases this is a nicer solution but inevitably leads to more work to provide a lovely experience for your users.

Next in the line up is conditional delivery. Lots of apps grow to a point where they start aiming at users from either different markets or maybe they have two separate user use cases, like Deliveroo riders and Deliveroo orders. You might quickly find that there are some features you don’t want to be shipped to a certain market or a specific portion of your users need a feature from your app and others don’t. We can now ship this feature to particular users if they meet certain criteria that we can define.

Third we have on-demand delivery. Although similar to conditional delivery, on-demand delivery allows us to add and remove features of the app as and when we need to, rather than just provide or not provide them initially when the app is first installed. This allows us to not bulk the initial download of the app if we know that there is a large feature that most users don’t use regularly, if ever. Similarly, we could remove a feature on-demand.

It looks like Google is really doubling down on dynamic delivery of features and the use of app bundles. This is a big win for users as it encourages developers to ensure that every part of the app on a user’s phone is beneficial to them and them specifically, ultimately saving a lot of valuable disk space. We’ve really seen app bundles improve massively and it’s clear that they are heading in the right direction by promoting app modularisation to customise an app’s unique delivery status.

I’m looking forward to seeing what comes next!

Android Jetpack: Understand the CameraX Support Library

Joe Birch (Android GDE @ Buffer)

If you’ve ever used the Camera APIs on Android, you may have felt that they’ve never been the simplest thing to implement. There was originally the Camera API, which was deprecated in favour of the Camera2 API – this iteration aimed to provide developers with a better experience when dealing with camera APIs on Android. Luckily for us, the new CameraX API aims to alleviate these pain points for us by providing a simpler solution to camera feature development. Whilst, CameraX is built on top of the Camera2 API, it greatly simplifies the implementation process for minSDK 21 and above.

The CameraX library provides 3 implementations of what are known as use-cases. Each of these use cases aim to simplify the process of common camera feature implementations, these are:

  • Preview – Used to prepare a view finder for the camera preview.
  • Image Capture – Used for low latency image captures.
  • Image Analysis – Used to perform analysis on images.

Each use case class takes some configuration in the form of a Config instance. This interface is used to define a common set of functionality that is used across each of the subclasses for each use case. If you jump into the source of the Config file, you’ll notice there is a lot of library specific definitions. A Config class is used to hold a collection of options and values which are used to represent the configuration details for the corresponding use case, you’ll manipulate these values through the use case class so don’t worry too much about what is contained within this Config interface.

For each use case that you wish to implement you will need to instantiate one of these Config classes, provide the desired options / values and then assign it to your use case. This configuration helps to make the camera features flexible and customisable, allowing us to optimise their uses within our applications.

Overall the CameraX library aims to create a consistent experience for both developers and users when it comes to cameras within application. It’s been long await on the Android platform and I definitely feel that this will change how we build and use cameras for the better.

Demystifying Android Accessibility Development

Ataul Munim (GDE @ Monzo)

I’m always really interested to listen to talks about mobile accessibility—especially ones on Android. The content is usually pretty similar but I find it fascinating to experience the different approaches, emphases and take-aways.

This year, Phil Weaver, Qasid Sadiq and Isha Bobra presented what I think has been the most explicit guidance for Android app developers that I’ve ever seen. Phil began with the introduction, and shared three simple principles:

– Make information visible
– Prefer simple, big controls
– Label images precisely and concisely

These cover a lot of cases: appropriately sized text, colour contrast and colour-blind safe palettes. It’s not just about making your information visible in the literal sense, but exposing it where it makes sense, e.g. adding captions to video content. He followed with this diagram showing the interaction between a user and an app:

App presenting information to a user and a user can act on the app

Rather than making app developers handle specialised use cases for each user, Phil showed an image which explained how accessibility services on Android were designed to serve as the user’s agent.

Instead of the app presenting information to users directly, app developers should ensure that they expose information to the system, which in turn will surface it to the user in the most appropriate fashion (e.g. on screen, audibly, with an external hardware device, etc.).

App presenting information to an accessibility service which serves as the user’s agent

Google is working towards solving accessibility issues at scale. While we can definitely provide short-term workarounds for issues that we perceive in our apps, it would be more impactful if we raise an issue or bug so that they can work on improving the base case for all the developers who _won’t_ be providing workarounds in their apps, leading to a more consistent user experience (over time).


I/O was a really inspiring event and sharing that learning with others allowed for more diversity in opinions and let us see and learn things from a perspective we might not have considered before.

This post is a collaboration and as such has been cross posted.

Here on Joes blog

Here on Atauls blog

Here on Blundells blog

Here on Ed’s blog