“Unboxing” the Android Things Developer Preview
Android Things is Google’s answer to creating an environment for IoT devices. Take a slimmed down Android build, add some sensor-specific APIs, and provide it on a number of powerful pre-integrated micro-boards and you have a ready-made platform for building a host of upcoming IoT devices. Android Things can take advantage of many existing Android libraries, toolkits, and APIs, making it easier and quicker for developers to turn ideas into product. What’s not to like?
We decided to test this theory by checking out the Android Things Developer Preview on a Raspberry Pi 3. We were looking to assess the overall experience, to understand what types of products it is targeting and to try to determine how well it can support Qt.
One of my very first observations is that Google does not provide the source, just a pre-built image. This makes it difficult to customize the image and puts us at the mercy of Google for updates to any of the contained components or packages like the kernel or SSL library. Let’s hope that this will change once we’re beyond the Developer Preview stage.
Once you have the image loaded onto a board, it’s time to boot it and take it for a spin. This is an appropriate time to get a coffee — and you’ve got the time to drive to Starbucks — because booting Android Things takes a very long time. Linux builds for Yocto or Debian on the same hardware boot significantly faster than Android Things, so we can probably assume the boot process hasn’t yet been fine-tuned. Without knowing the final boot speed of an Android Things product, you may want to plan use cases around a system that’s always on and rarely needs a reboot, or that isn’t real-time and can afford a boot process that takes minutes.
The Android Things Preview on the Raspberry Pi 3 doesn’t provide OpenGL ES support or a virtual keyboard, which severely limits what type of Android Java apps will run. (Unfortunately, that also means it cannot support Qt QML either.) It’s pretty safe to say that if your device plans to have a full smartphone-like display, you might not want to use Android Things anyway. Although it does support frame buffer graphics, without hardware acceleration the graphics are quite pokey. Our guess is that even if Android Things will eventually support OpenGL ES, its best application will be for a headless configuration or one where your display needs aren’t too sophisticated.
Unfortunately, boot speed and graphics aren’t the only things that are sluggish. Running and installing apps are quite slow: first time loads for a Java app are around 20 seconds, and for a Qt app around 25 seconds. This delay is likely due to the AOT compiler, because things speed up dramatically to a boot in just 2-3 seconds on subsequent loads. While this is a pain for developers who will suffer these load times for each new build, the AOT compiling means that customers would only notice a slow experience first time out-of-the-box.
Now for the good news. Qt developers will be happy to know that Qt Creator works very well with Android Things — running and debugging apps just works. And not only will QWidget-based applications run on Android Things, they’re even faster than the platform’s native Android Java widgets. This may not be saying much without GPU-accelerated graphics but any speed improvement is a bonus.
Also good news is the device’s security. Android Things uses the Android security/permissions model across the board, letting you have complete security control of your IoT device access, and placing all apps in isolated containers by default. With IoT security being a primary concern, built-in security from the ground up is most welcome.
Finally, Android Things is Apache 2 licensed. People who are building an IoT device to be sold as a product will appreciate that they don’t have to open up their source code to the world. It is a disadvantage to those who are tinkering but this choice (and the Google source ownership) pretty clearly point to a commercial product bias.
If you’re an Android fan, you’ll like where Android Things is going. It’s a bit on the slow side, as it’s clearly designed with certain use cases in mind — like little (or no) display and infrequent reboots — but the benefits of Android development may outweigh the disadvantage of carrying around a massive Android runtime. It will definitely suffer on low-end devices but we can hope that optimizations will be made as more programmers get their hands on it. We’ll certainly be keeping our eyes on it and, as running C++ can do nothing but help the overall speed, we’ll be trying to make sure that it supports Qt as best as possible.