Hello Android Things Developer Console

This week Google released the developer console for Android Things. With this release, another piece of the puzzle is in place. The terms and conditions of the developer console it make clear that this is a developer preview, the number of devices you can push updates to is limited to 500, and you can use the console “for the sole purpose of internal development and testing of devices.” Don’t go out and try to sell anything yet. It looks as though actually distributing a product will require an additional, commercial agreement with Google.

I used the developer console to create an image for my (now deprecated) iMX6UL Wandaboard (bought especially for Android Things development, not that I’m bitter about it being deprecated so soon). The process is simple enough. The hardest part is figuring out how much of the device’s memory to reserve for an OEM partition. I went for a wildly pessimistic 128MB partition size, which is over kill for a 2MB app, but once set the partition size cannot be changed so I erred on the cautious side.

I created a product based on my bus stop project.

The OEM Partition

The OEM partition is where your app lives. You need to determine, ahead of product deployment, how much room you are ever going to need. I can see this being a trap for the inexperienced. You don’t really know how big your app is going to get. There may be, in the future, a massive (in size and functionality) dependency that you just have to have. But should you just reserve the maximum? Maybe not.

Create a product

Creating a product is a simple process. There was talk of possible future features of the console that may make this more involved, but the MVP we have today is limited in configuration options. You just need to give your product a name, description, target board, OEM partition size, and select whether you want to include Google Play Services. Once the setup is complete you can create a starter build.

My test device product settings

Build with no bundle

The first build I made had no bundle, so it wouldn’t do anything. My plan was to start with an ’empty’ build, flash my device manually, see that it was not a bus stop, then create a build with my app bundled to test the OTA update. If my device suddenly became a bus stop again I’d know it worked.

Flash device with starter build

I downloaded the starter build and flashed my device. This is the same process as flashing with a developer preview. It’s still a little clunky. I imagine that if you buy enough SoMs, you could convince your supplier to burn a starter image for you. Of course I still needed to connect the device to my Wifi so that it would receive an OTA update described below.

Create a bundle

An Android Things developer console bundle (as opposed to and Android Bundle), is a zip file containing your app’s apk, and some other optional items. Your app will be launched automatically on device startup. You can add a boot animation to your bundle, along with any user space drivers you want to create as services, and any other apks that you want your app to launch.

I created a bundle containing my bus stop apk, then uploaded it to the developer console. Once I had my bundle uploaded to the developer console I created another build configuration using the bundle.

My device’s factory images

Push an OTA update

With my new build configuration ready I could roll out an OTA update to my device. I pushed the update then waited (actually I went to work, but you get the idea). I expected the update would have been applied by the time I got home after work.

Pushing an OTA update

Well, I went to the GDG Wellington meetup after work and learnt lots from the local Android developer community about the latest hotness from this year’s Google I/O. I didn’t get back home until much later that evening. The display of my device still showed that it had not magically become a bus stop, which was expected. I’d need to reboot to see if the OTA update had been successful. I think this will be configurable in the future, but for the moment you need to manually reboot your device to apply an OTA update. This is the safest default behaviour, no one wants their toaster to randomly reboot itself to apply an update.

I rebooted the device, and, and, and….

It’s alive

… it worked. The bundle had been installed with the update and my device magically became a bus stop sign again.

The experience so far

The experience so far, with the Android Things developer console, has been good. I’m sure it will get more complicated as features are added, but as far as MVPs go, it had everything I needed to get through the process of creating a device, configuring it with my bundled application, manually flashing an in-factory version of firmware, then rolling out an OTA update.

The part of the process that is most difficult is connecting a newly minted device to the network to receive an OTA update, but this is really more of an out-of-box experience issue than a factory deployment issue. I think I’ll look into that next. I’m thinking that for a device without much of a UI I’ll need an companion app that runs on a phone and somehow gets a user’s network credentials onto a device.