Android, Linux & Real-time Development for Embedded Systems

by Colin Walls , TechOnline India - May 03, 2011

Android appears to be (yet) another operating system for smart phones, joining all of the others that are vying for supremacy " such as Symbian, Windows Mobile, WebOS and various flavors of Linux. But it would be better to think of Android as being a software platform for building connected devices.

At first sight, Android appears to be (yet) another operating system for smart phones, joining all of the others that are vying for supremacy " such as Symbian, Windows Mobile, WebOS and various flavors of Linux.

However, it would be better to think of Android as being a software platform for the construction of smart phones, as it is freely available and highly configurable. To be more precise, it is a software platform for building connected devices.

Android is an application framework on top of Linux. We will look at the details of the layers of the framework, shortly. It is supplied as open source code, but does not bind the user with the constraints of the GPL " there is no requirement for developers to make public any code developed using Android.

Another way to look at Android is to take a historical perspective. In the early days of the PC, the operating system was DOS. A programmer writing applications for the PC had some significant challenges, as the services provided by the operating system were quite limited.

For example, the developer of a spreadsheet application would need to provide drivers for every possible printer that users might wish to deploy. This was a significant development and support overhead.

In due course, the release and wide acceptance of Windows (version 3 onwards) addressed this problem very effectively. In many ways, Android does for Linux what Windows did for DOS: it provides an intermediary layer between the application program and the operating system.

Android History

As Android seems to be a hot topic of discussion at this time, it is hard to remember that it is quite new. It really started when Google acquired Android Inc. in 2005. They established the Open Handset Alliance and announced Android in 2007, with the first handset appearing the following year. The source code was released at that time.

Android has now reached version 2.1 and enjoys widespread support, as more devices " mainly handsets " have been announced. The latest, and certainly the most talked about, being Google's own Nexus One device.

Android Architecture

An Android system consists essentially of five software layers: 1) Linux; 2) Libraries; 3) Runtime; 4) Application Framework; 5) Applications

Linux. The bottom layer is the Linux OS itself " version 2.6.3x with 115 patches, to be precise. This provides process and memory management, security, networking and an array of relevant device drivers.

Libraries. A set of libraries reside on top of the OS. This includes Google's version of libc, called bionic, along with media and graphics libraries and a lightweight database " SQLite.

Runtime. Alongside the libraries, on top of the OS, is the Android runtime " the Dalvik VM. This is not strictly a Java virtual machine, though it serves that purpose. It was designed specifically for Android and is register based to conserve memory and maximize performance. A separate instance of the Dalvik VM is used to execute each Android application. The underlying OS is used for memory management and multi-threading.

Application Framework. This layer provides a number of services to applications: views, content providers and resource, notification and activity managers. These are all implemented as Java classes. Any application can "publish" its capabilities for use by other applications.

Applications. A number of applications are routinely distributed with Android, which may include email, SMS, calendar, contacts, and Web browser. All applications have the same status " the supplied ones are not "special".

Applications are generally written in Java and processed with the standard Java tools with a converter being used to translate to the Dalvik VM bytecodes.

Application Development

An Eclipse-based development environment is available from Google. This may be used in conjunction with the Android emulator or a real device (connected via USB). Only a limited range of ARM-based devices are supported.

Programming Model. An Android application consists of a number of resources that are bundled into an archive " an Android package.

Programs are generally written in Java and run using the Dalvik VM. This uses non-standard, memory-efficient bytecodes. Each program runs in its own Linux process, so it is protected from other programs.

There is no single entry point to a program (like main()). There are simply a number of components that are instantiated and run as required. There are four types of components:

* Activities
* Services
* Broadcast receivers
* Content providers

An activity is an executable unit that performs a specific function and has a user interface. An application may include numerous activities, but one is nominated as the default (the entry point) where execution begins when a user starts the program.

A service is similar to an activity, but it has no user interface and runs in the background.

Broadcast receivers respond to system-wide messages issued by other applications or the OS.

Content providers make data available to other applications. This data may be held in the file system, in the SQLite database or elsewhere " there is complete flexibility with respect to data storage.

An Android application is described in structured XML in an Android manifest file. This is stored in the root of the applications file system with the name AndroidManifest.xml. Here is an example:

 

                             

 

Intents

An intent is an asynchronous message requesting that a particular action is performed. An intent may activate an activity, a service or a broadcast receiver. For activities and services, an intent specifies both the required action and the location of necessary data.

Applications have intent filters, which define what kind of intents the components of an application can handle. These are included in the manifest file. Here is an example:

 

                             

Android Deployment

The current distributions of Android are biased towards the needs of the mobile handset designer. This was the market that Google elected to pursue and they configured their product accordingly.

It is, therefore, a considerable challenge to retarget Android to another type of device. However, the design of the OS is flexible enough to make the addressing of these challenges worthwhile.

At Mentor Graphics, our goal is to support our customers who wish to develop Android-based devices in industry segments beyond mobile telephony. We anticipate the availability of a number of Android "editions", each one targeted at a specific vertical market, with market-specific components and optimizations. Such markets are likely to include white goods, medical, automotive and telecoms.

At the highest level, there is a need to port Android to devices which are not ARM-based, as other processors are prevalent in certain markets. Although porting to a new CPU is not too difficult, ensuring optimal operation of the entire Android software stack requires extensive work. Each part of an Android system needs specific attention:

The Linux kernel must be ported, along with necessary board-support components like drivers. Also, industry-specific drivers are required.

The libraries need to be optimized and, in particular, must be configured to take full advantage of any available hardware acceleration (graphics, for example). Various product- and industry-specific middleware is also needed.

After porting, the Dalvik VM must be very carefully optimized for specific CPUs, as this determines the efficiency of application code execution.

The application framework requires similar industry-oriented optimization to the libraries.

For application development, an environment is needed that supports code development and debugging across a wide range of hardware targets, both real and simulated.

Android and Real-time Systems

Android, like Linux, is not real time. Steps can be taken to make such an OS deterministic, but this approach has severe limitations. It is likely to have lower than required performance, and drivers, etc. may be incompatible with the needs of a real-time application.

A better solution is to use a true, real-time operating system, to perform the real time activity for the system, while Android (or Linux) provides other functionality. Each type of OS may thus be used optimally:

RTOS
* Hard real time
* Optimal on the data plane
* Certified software stack

Non-real time OS (Android/Linux)
* User application framework
* Massive middleware offering (ecosystem)
* User interface

Running multiple operating systems can be facilitated in a number of ways. Virtualization may be achieved using a hypervisor, which divides CPU time between the operating systems in a controlled way, giving each one apparent total control of the processor. This approach is complex and can have performance limitations, but may be attractive if legacy hardware is deployed.

The use of multiple CPUs (cores on a chip or chips on a board) is increasingly attractive to system designers, as this permits optimization of power consumption.

This provides the opportunity to simply run a different OS, as appropriate for the required functionality, on each CPU. So, one or more CPUs may be running Android/Linux and one or more others might run an RTOS.

Conclusion

Android is a disruptive technology, which was introduced for mobile handsets, but has much wider potential.

There are many challenges with the wider deployment of Android, but companies like Mentor Graphics are committed to supporting developers who choose Android/Linux to implement embedded systems.

The use of multiple cores along with multiple operating systems will become increasingly common, as demands for high functionality and lower power consumption are reconciled.

 

About the author:

Colin Walls has over twenty-five years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is a member of the marketing team of theMentor Graphics Embedded Systems Division, and is based in the UK.

About Author

Comments

blog comments powered by Disqus