We some times get the question of whether resin.io will ever support Android devices. There’s a lot to unpack with a question like that, and we’ve recently been doing some research to be able to give an informed answer. This post is intended to act as a thought experiment, independent of what’s currently on our roadmap or planning. Along the way, we’ll share some of the insights we had while deep-diving into the Android world.
What is Android?
We can’t make much progress on our thought experiment without better defining the question. Since Android can mean different things to different people, one must distinguish the Android Kernel and Hardware Abstraction Layer (HAL), let’s call them Android Core, the Android Open Source Project (AOSP) which includes a lot of the higher-level Managers and Google’s Java implementation, and the full-blown Android shipped with phones, which includes the user experience and Google Play Services (let’s call that Full Android). Each of these builds on the previous, adding its own components on top.
Which Android should resin.io support?
With this distinction in mind, to determine what Android resin.io should support, the key factor is to know what advantage is being sought over our current Linux support. To start, would we want to support the Android UI and Google Play Services in some way? Here, we must observe that the canonical use case of Full Android is phones and tablets, which are not in the target set for resin.io, at least not when they are used as intended. Also, even on Linux, we do not target our support on the userspace. If users want to build up a UX, it’s up to them to create it in their container, by installing the relevant packages such as an X server and a browser. This line of reasoning tells us that we most likely don’t want to target Full Android as our support goal, even if a resin managed device can be made by the user to display Full Android experience.
The Android Open Source Project (AOSP) has made it to more and more embedded devices like Set Top Boxes and In-vehicle Infotainment systems for cars. The AOSP however, is still dependent on the Java language, and any notion of containerisation entails Java containers. With a stretch of the imagination, one could imagine a resin.io build producing APKs instead of containers, and deploying those to Android devices. That however would entail a lot of overhead, deep changes in the resin.io process and architecture, and additional restrictions to what the users can do.
Brillo is Google’s foray into the Internet of Things. The fact that Brillo is little more than Android Core tells us that Google agrees that the additional items, such as the Java VM (ART) and APIs as well as the UX are not optimized for an IoT context. We therefore get to thinking whether Android Core is the right level to be targeting. A benefit of having resin.io run on top of Android Core would be to gain the additional hardware support that Android has for a number of devices where Linux support is non-existent or substandard. A resin.io managed Android Core device would appear like all other resin.io managed devices, and, if we got a container engine and our agent running on it, would run containers pushed from resin.io. This is a level of Android support that is attractive, and would make sense from a developer experience point of view, with clear value added.
How would that support work?
The next question to answer is the technical approach to take. Any Return on Investment calculation has to account both for the Return and the Investment, so how hard would it be to accomplish this? Investigating how Resin.io would work with Android Core, we have discovered the Mer project, on which Sailfish OS has been built. Mer uses the Android Kernel and HAL, but builds on them with a standard Linux userspace, using technologies like libhybris to bridge the gap. Mer then uses systemd, connman, and btrfs as building blocks, even turning the Android HAL into a systemd service. Resin OS is based on those exact building blocks, so by building on top of Mer, or at least the core part of it, support for Android hardware becomes very simple. The hard part would be integrating with Mer, and in particular bridging the Mer and Yocto worlds, but that is a much easier problem than that of bridging resin and Android.
The legal angle
Besides the technical challenge however, there is the licensing challenge. The core reasoning for most differences between mainstream Linux and Android architecture, is the desire to enable more proprietary ownership. In Linux, drivers have to be compiled into the kernel as modules. That in turn, means that due to the GPL license of the kernel, the drivers need to be GPL-licensed too. In the Android model, the kernel modules still have this limitation, but the interface they expose can be very low-level and not truly usable by an application. The gap is bridged by the HAL, on which device manufacturers can add code to translate from the interface they expose on the kernel level, to the standard HAL abstractions. The HAL, being in userspace, is not linked with the kernel, and therefore does not have to be GPL licensed. As such, device manufacturers can get away with much more restrictive licenses on their HAL components, including ones that impact redistribution.
All the above goes to say, that even if we did build Android support for resin.io, it would either have to be on a device where everything from the HAL and below was something we could redistribute. That would entail either an open license that allows redistribution, or us working closely with the manufacturer and being explicitly allowed to redistribute. An alternative is to have some elaborate installation process, like the Mer project does, that involves installing our OS on top of an existing stock Android image, so as to overwrite everything but the needed proprietary drivers. In that case, we would not be “redistributing” anything, just depending on what we find on the device. Besides being very error prone, a process like this would compromise the core resin experience so we’d have to have some additional insights into making it easy while remaining legal.
So what’s it gonna be?
With the above analysis in mind, will resin.io support Android devices any time soon? We’re not opposed to it in principle, but we need a good enough reason to do it, and a path towards avoiding the legal hurdles described. We do believe we will eventually have some level of support, standing on the shoulders of the awesome Mer project, but depending on what our users and customers prioritize, this could be in the nearer or further future.
Thoughts? Chat to us on community chat
