The Android operating system is made up of open-source software and a modified version of the Linux kernel. It adds a full user interface framework to SELinux and, because of its user-friendly interface and adaptability, is gaining appeal across a wide range of applications.
As an embedded operating system, Android is becoming increasingly popular. Embedded Android features all the benefits of embedded Linux, plus a wonderful user experience and a familiar programming interface. It may be found in a variety of use cases, including digital signs, testing and measurement, point of sale, and automobiles.
We'd want to highlight the main reasons why people choose Android, as well as offer some advice on how to get started with an embedded Android project.
Google releases the source code for Android's core as the Android Open Source Project, or AOSP. This includes everything up to and including the launcher screen, as well as some basic browser, clock, and phone applications. This code is all released under permissive open source licenses, with the majority of it under Apache 2.0 and certain pieces under BSD and MIT licenses. Permissive open source licenses allow you to freely alter and ship items without having to make any of it public.
You may get a copy of AOSP right now via Google's git servers, but keep in mind that a full download will take roughly 50 GB. At source.android.com, you can find detailed instructions on how to build mainline AOSP, and we'll include links to embedded Android versions later in this post. While building Android from the ground up isn't easy, it's well within the scope of most embedded platform developers.
The second major software component you'll require is a Linux kernel, which is also available for free under the copyleft GPL license, which essentially allows you to alter the code as long as you make it public.
In the realm of free software, there is, unfortunately, a thorn in the side. In the vast majority of circumstances, you'll also need to use non-free software. These non-free "binary blobs" are typically used to supply firmware for the CPU and peripherals, as well as device driver kernel modules and user-space libraries, which make up the Android Hardware Abstraction Layer (HAL). The chip vendor normally only sells these components as part of an Android board support package. Later, we'll expand on this.
Android is an obvious choice if your product has a touchscreen. Everyone has used an Android phone at some time, so your end consumers will be familiar with the UI — how to browse through menus and on-screen options, how to use touch gestures – it'll all be second nature to them. Thus, having the same user experience in your product makes sense.
The Android programming interface is well-known and well-documented — visit developer.android.com to get a sense of Google's support for its mobile operating system. Not only does this make developing apps for your product easier, but it also makes finding developers to work on it easier.
Many more people are familiar with Android than with C++, which is more commonly used in simple embedded Linux settings. On the other hand, don't throw away your hard-won C++ skills; you can write Android in both C++ and Java.
Google provides a comprehensive set of free tools for developing Android applications. Android Studio is the main workhorse for writing Java and C++ applications.
If Java and C++ aren't your cups of tea, there are a slew of third-party services that support a variety of different languages and environments. For example, Xamarin provides tools that allow you to construct Android apps in C# and.NET, providing a good development path from Windows CE or Windows Embedded programs.
To embed Android, you'll need hardware that can run the system, as well as a board support package that properly configures Android and the Linux kernel. Remember that embedded devices are often constructed to higher standards than consumer-grade items. These devices are frequently required to function in severe conditions for long periods of time, possibly unattended. They're frequently made in small batches and have a long design lifespan. In comparison, consumer items are mass-produced in the hundreds of thousands (or millions) and have a design life of 12 to 18 months. Finally, an off-the-shelf Android tablet is seldom what you need.
As a result, embedded designs rely on chips and other components that meet industry specifications and will be supported throughout the product's design life cycle. This eliminates some of the more well-known SoC manufacturers, but there are still enough companies that are committed to supporting Android on their embedded chips. NXP, Qualcomm, and HiSilicon are just a few of them.
NXP's i.MX 6 SoCs, which include single, dual, and quad-core ARM v7a architecture (32-bit) CPUs, support Android on the vast majority of them. NXP offers board support packages for AOSP versions 7 and up, Nougat, at the time of writing.
Under the "Snapdragon Embedded" name, Qualcomm offers a number of industrial-grade components, including the 410E, 600E, and several 8xx variants. There are four or eight cores in this blend of ARM v7a and ARM v8a (64-bit) architectures. The embedded chips are comparable to the mobile chips, however, they don't have the mobile data modem. AOSP 7, Nougat, is currently supported by all.
Hisilicon (part of Huawei) is a bit of an oddity here. They don't have a big presence in embedded processors, but provide the SoC for the only embedded development boards with direct support in the AOSP source code base: the HiKey and HiKey 960 boards. These are based on the Kirin 6220 and 960 processors, which are both based on the ARM v8a architecture. They run the most recent AOSP version, which is now 8, Oreo because the support is right there in the AOSP codebase.
Other SoC makers, including Allwinner, Amlogic, Intel, MediaTek, and Rockchip, provide some level of Android board compatibility. If your chip isn't included in the list, you could possibly transfer your own version of AOSP to it. Emteria has done this for the Raspberry Pi, for example.
The Android operating system runs on top of a Linux kernel, which is generally provided by one of the above-mentioned SoC suppliers. This implies that the Linux knowledge you've accumulated over the years is still useful. You may still tweak the kernel and install drivers for your specific device. All of the Linux development tools, such as perf for performance monitoring and trace for tracing, are available.
With a little modification, you can even run regular GNU/Linux apps on Android. This implies that code written for previous Linux systems may be reused. Customized signal processing techniques or communication protocols with the rest of the system are good examples. The problem is that Android lacks the POSIX APIs and other libraries that GNU/Linux-compliant apps require. The issue can be approached in two ways.
This is a feature of all FLOSS (Free/Libre and Open Source Software). However, in the case of embedded systems, the ability to customize the low-level platform code to meet your needs is critical to getting the most out of your product.
We are not suggesting major modifications to the fundamental operating system – that would be a headache to maintain – but rather minor tweaks and adjustments that result in a truly fantastic product. Locking down the UI so that consumers can only utilize the programs you provide is a good example. However, this is exactly what emteria.OS can provide to you, so that you don’t need to maintain this yourself.
Although Android is becoming more popular as an embedded system, the lack of a specialized OS provider for smaller fleets has kept the sector fragmented and exposed the possibility of faulty software, which can trigger warranty provisions under the new EU framework. In the grand scheme of things, the lack of a highly flexible, developer-friendly, and user-friendly operating system suited for medium-sized fleets of embedded devices has been a key hindrance to innovation in the IoT environment.
Newer versions of embedded Android, such as emteria.OS, is taking steps toward standardizing the industry and offering Android's features to OEMs at a lower cost. More effective versions of embedded Android enable solution creators to focus on creating customer value rather than fixing OS difficulties, removing the present hindrance to innovation.