Android for Embedded Devices - 5 Reasons why Android is used in Embedded Devices
The embedded purists are going to hate me for this. How can you even think of using Android on an embedded system ? It’s after all a mobile phone operating system/software.
Sigh !! Yes I did not like Android to begin with, as well - for use on an Embedded System. But sometimes I think the market and needs decide what has to be used and what should not be. This is one such thing. Over the past few years, I have learned to love Android as an embedded operating system. Android is going to be seen on a lot of embedded systems around you and there are solid reasons why that's the case
For the uninitiated, Android is available in open source as Android Open Source Project (AOSP - https://source.android.com/). The source can be downloaded and used on many ARM controllers. Most ARM SOC providers like Freescale/NXP, Qualcomm, NVIDIA etc. provide an AOSP Board Support Package for their SOCs. You can build an embedded device with this AOSP.
When someone/company decides to make a product there are many aspects that are considered. Some of them that favour Android are listed below
#1 - Intuitive and rich GUI for the device
With touch screens dominating our day to day life, there is an expectation (mostly among the younger generation) for every screen that you see to be touch enabled. Right from ATMs to In-flight entertainment every screen which was once operated by buttons is becoming touch enabled.
So touch screen has become a requirement for many embedded devices with a display. If you need to design a User Interface for a touch based system then the screen graphics, the flow and reaction to touch gestures, etc. are expected to be at par with the latest smart phones.
Now the choice of software + OS on the device should support 'TOUCH' natively for you to leverage the maximum performance. Android fits the bill perfectly. It has a GUI framework, Touch framework, gestures, etc. built just for this purpose. So Android becomes a good choice here. It becomes much easier to develop a high quality touch based GUI system with Android.
#2 - Camera, WiFi, Bluetooth & more
"Accessing hardware and making use of it" - This is the major purpose of any embedded software. However, it is easy said than done. In devices without an operating system there is no marked distinction (in most cases) between device drivers, HAL, application, etc. More often than not part of your final application will be talking directly to the registers of a peripheral or reading a FIFO for data. This situation improves when we have an operating system. Once you have an OS (like Linux) then there are boundaries defined for kernel,device drivers and application. It has a clear "programming Interface" or System API to talk to the hardware devices. However, programming with this is tough as well. Most of these can only be done C or C++ programming and you need to understand how a Linux System works and how these APIs and specific standards are implemented. For e.g. to make a camera application in Linux you should understand how V4L2 - VideoForLinux (https://en.wikipedia.org/wiki/Video4Linux) works.
Now in Android all this has been simplified. An application programmer without much knowledge about the system can still use the standard Android SDK and work with the Camera API to create camera based applications. The same is true with Wifi, BT and more. Accessing hardware and the system has been simplified with Android and it is attractive for people who want to develop applications faster.
#3 - Developer Community
If you are looking to make an embedded product with good GUI, it is not easy to find good developers who will develop good graphical user interface while keeping all embedded constraints in mind. More often than not, the tools and libraries on an embedded system are not the same that you can get on a PC platform. So finding that right developer is always a challenge.
Android (needless to say) has a developer base all around the globe and is not a niche area like embedded application development. So finding an Android developer for your embedded product becomes much easier. I have personally seen companies which use Android just for the reason that their developer base is predominantly Android.
Apart from getting good developers, Android is backed by Google and is extremely popular as a Mobile phone OS. So Android Open Source Project is on the right track and is not going to be end-of-life soon. Development happens continuously and so does integration of latest technologies and hardware.
#4 - Support from vendors
Speaking of hardware and peripherals brings me to the next valid point. Most hardware peripheral vendors supply an Android driver without fail (as they want to sell their peripheral for a smartphone :) ). This makes life easy when you develop a hardware device. Whatever WiFi/BT chipset you may choose or LCD that you may pick, you can rest assured that there will be Android support for that part from the vendor. Right from SOCs, WiFi, BT to LCD - vendors support their hardware in Android by giving drivers, BSP, etc.
#5 - Quick Prototyping
There is nothing like showing a working device to your board for approval or your investors for that much needed funding. Embedded prototyping had always involved buying development kits, rigging them together with a melee of wires and somehow stuffing them into a box for the demo.
Now, Android devices are everywhere. You want to develop an prototype? Pick a phone or Android tablet that is closer to your screen size and resolution and you can start developing your application. We have enabled Android phones/tablets' USB port to support serial port, camera etc. so that a prototype can be quickly built. We have used Android phones/tablets as the system that does the major processing in some cases and as the HMI (Human Machine Interface) in many other cases.
In both scenarios, Android has helped making a prototype much faster and cost effective.
Okay! So is everything rosy with Android ? Should you use that as the operating system of choice for your next embedded product? Hmmm... not before you consider my next blog in this series "Android for Embedded Devices - 5 Pain Points to consider".
Let me know your thoughts in the comments section and also if you would like me write anything similar to this topic.
- Comments
- Write a Comment Select to add a comment
Hi Maharajan
Nicely written! We took the hard route about 2 years ago and built our own hardware with a customized Android which serves as a User Interface for an industrial device: https://www.linkedin.com/pulse/android-industrial-...
It runs the so called "Kiosk-mode", where the user doens't actually notice that it's an Android device.
Of course the "hardcore" embedded stuff (real-time sensor sampling every 0.005s, UART/CAN communication) is still handled on a dedicated microcontroller.
My talk at DroidCon Berlin shows how a traditional desktop application for data visualization (usually connected through USB running on Windows) could be replaced with an integrated, battery operated, low power ARM based Android platform.
Looking forward for your 5 Pain Points to consider!
Cheers Michael
Hi Michael,
Thanks for the comments. It would have been an amazing experience building something from scratch. I will watch your Droidcon talk. Most Android devices we have built are "Kiosk mode" devices.
Cheers,
Maharajan
FYI, I have also hacked something with Android Things at home:
Control my wireless Sonos speaker with Android Things (https://www.hackster.io/projects/e94011/)
To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.
Please login (on the right) if you already have an account on this platform.
Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: