porting the android platform

beyond mobile phone applications

Vlad Buzov, senior software architect, Mentor Graphics

W h i t e P a p e r

e m b e d d e d s o f t w a r e

w w w.m e n t o r.c o m
Porting the Android Platform Beyond Mobile Phone Applications

Introduction
Android™ is an open source operating system (OS) and platform developed by Google for the Open Handset
Alliance (OHA), a consortium of companies dedicated to producing an open standard for mobile devices. Android
gained serious momentum from the Linux® OS. Over the past twenty years, Linux progressed from a home-grown
educational project to an enterprise-class, server solution and finally, to a true embedded platform widely deployed
on a variety of embedded products. Android is an application framework based on the Linux kernel. Just like Linux
OS, it’s an open source platform. However, it is not distributed under GNU Public License (GPL). Most of the Android
framework source is licensed under BSD or Apache 2.0 licenses, which are less strict about releasing the source
code as opposed to GPL.

The fact that Google has chosen permissive open source licenses to distribute Android source code made it
possible to create two versions of Android: commercial and open source. The former is mostly available to OHA
members under special commercial terms, while the latter is available to everyone called the Android Open Source
Project (AOSP). Embedded product vendors can also take advantage of using Android because it reduces the risk of
releasing Intellectual Property (IP) integrated to Android OS.

Since the first commercial release of Android (a little less than two years ago), Google has released a number of
major Android updates; “Cupcake” (1.5), “Donut” (1.6), “Éclair” (2.0/2.1), and “FroYo” (2.2). At this moment, Google is
actively working on the next major release called “Gingerbread” (3.0).

These releases are quickly adopted by device manufacturers, silicon vendors, and OEMs. In fact, recent Android
releases “Éclair” and “FroYo” now occupy 77 percent of the Android device market. The latest market data for the
third quarter of 2010 shows that in the United States Android phones account for 44 percent of all consumer
Smartphone sales.

It’s projected that nine percent of application developers will spend more than one million U.S. dollars on new
Android applications in 2011 and Android’s estimated market share will grow to around 28 percent.

Originally created for mobile phones, Android OS is now actively used to create a variety of embedded products.
While Android presence is mostly dominated in the mobile space, it is quickly gaining momentum in kitchen
appliances, embedded readers, gaming devices, tablets, digital photo frames and more. The list continues to
expand.

This white paper opens with a quick introduction of the Android OS. It continues with a description of the Android
architecture highlighting major design features. Finally, we’ll discuss challenges and key considerations to keep in
mind when porting the Android OS.

android Architecture
Proper software design is a key factor in the success of any software product. Android is no exception. Android is
designed in a way that allows easy reuse of its building blocks with little to no modifications. The straightforward
software reuse is a fundamental principle of Android design that will be discussed further in this section.

The Android OS has a multi-layered architecture:

■■ Linux Kernel
■■ Libraries
■■ Android Runtime

w w w. m e nto r. co m
2
Porting the Android Platform Beyond Mobile Phone Applications

■■ Application Framework
■■ Applications

the linux kernel

Figure 1 shows how the Linux kernel is a fundamental part of Android architecture. It provides low-level operating
system functions to facilitate user applications needs. It includes process management, memory management,
basic inter-process communication (IPC) methods, security mechanisms, network connectivity, and vast array of
device drivers.

For each of the Android releases, Google tends to pick up the most recent Linux kernel version, which is extended
with additional features required to run the Android framework. In general, the modifications are implemented by
a series of over one hundred patches which implement:

■■ Android Power Management

■■ Android Debug Bridge USB device
■■ Android out-of-memory killer
■■ New IPC methods:
▪▪ Binder

▪▪ Android Shared Memory (Ashmem)

The security mechanisms provided by the Linux kernel, such as user and group permissions to system resources
(file system), are extensively used by the Android Framework to protect core system data and functions from
applications running in the system. Android out-of-memory killer is intended to prevent out of memory situations
caused by an application, which could impact the overall system. New IPC methods are underlying mechanisms for
high-level IPC implemented within the Android Framework for Android applications interaction. (IPC will be
discussed later in this paper. )

Figure 1: The Linux kernel.

w w w. m e nto r. co m
3
Porting the Android Platform Beyond Mobile Phone Applications

libraries
The next layer on top of the Linux kernel is the Android C library and other system libraries (Figure 2), which
implement core functions used by Android Framework and applications. Unlike Linux OS, which is based on GNU C
library, Google developed its own version of C library called Bionic. It is derived from various flavors of BSD OS. The
Bionic libc provides only those functions, which are used by other Android libraries and applications. This makes it
inflexible for integrating software built for GNU environment.

Android does not use any GNU tools in runtime. Rather, it provides its own version of dynamic linker loader to
support dynamically linked shard libraries as part of Bionic libc.

Other examples of key libraries include:

▪▪ Multimedia libraries for audio and video

▪▪ Graphics libraries

▪▪ SQLite embedded database for applications data storage and sharing

▪▪ WebKit for Internet HTML pages rendering with JavaScript engine

▪▪ OpenSSL for secure communications

Figure 2: Libraries.

w w w. m e nto r. co m
4
Porting the Android Platform Beyond Mobile Phone Applications

android runtime
Android runtime is the most critical part of the Android OS (Figure 3). Android is designed for straight-forward
software reuse, which could be difficult to achieve if the Android Framework was implemented in C/C++ and
re-compiled natively for each of the hardware platforms. In fact, all of the Android application framework and
applications are written in Java and run inside of the Google Dalvik virtual machine (DalvikVM).

The key distinguishing fact is that DalvikVM is not an Oracle Java VM. It implements its own register-based virtual
architecture, as opposed to stack-based JavaVM, and executes its own byte code (DEX).

The way in which this works is all Java programs are converted to JavaVM byte code by the standard Oracle Java
language tools and then converted to a DalvikVM byte code with a special DEX compiler provided by Android.
This allows the developer to remain compatible with Java language when adopting existent Java applications.

Unlike the Oracle JavaVM which is designed to work on top of different operating systems, the DalvikVM is tied to
the Linux kernel and directly uses interfaces provided by the Linux kernel and Bionic. For example, it relies on the
“pthreads” library to implement threading in Java programs. Each Android application is executed by a separate
instance of the Java machine and communicates with the Android Framework and other applications using IPC.

DalvikVM implements the Java Native Interface (JNI) bridge for Java programs in order to call methods
implemented in natively compiled libraries.

Figure 3: Android Runtime and the Dalvik VM.

w w w. m e nto r. co m
5
Porting the Android Platform Beyond Mobile Phone Applications

application framework
The Android Application Framework (Figure 4) is a Java-based set of services and systems supporting Android
Applications. Some services are intended to manage applications in Android (Package Manager, Activity Manager,
Window Manager) while others provide access to system functions and resources (Notification Manager, Power
Manager). On top of that, the framework provides hundreds of APIs and standard Java libraries for application
development.

The Application Framework defines two types of applications: Activities and Services. Both manage application
lifecycles in a system. An “Activity” is always associated with user interaction, while a “Service” is typically a
background process. There can be only one Activity running in a system at a given time – the one the user selects.
An Activity is an entry point to an application that could implement multiple Activities and Services. One Activity
could call other Activities that will stack on top of each other forming a “Task.” Thus, an Android Framework task
could actually be formed by Activities belonging to different application packages and Linux processes.

An application user interface is represented by a ViewGroup and View objects, associated with an application. A
“View” represents a user interface object, while a “ViewGroup” defines a user interface layout. A “Window Manager”
system service controls applications Views.

The Android Application Framework implements high-level IPC mechanisms – “Intents” and “Android Interface
Definition Language” (AIDL). Intents look like one way messages used to launch Activities, Services, or broadcast
events to a system. AIDL is an Android Remote Procedure Call (RPC) mechanism that allows Services (application or
system) to publish their capabilities for other applications. AIDL defines a meta-language to define an interface of
server and client, which then gets compiled to stub Java classes. AIDL is based on Binder IPC that also allows
calling Services from outside of the Java-based framework.

Figure 4: The Android Application Framework.

w w w. m e nto r. co m
6
Porting the Android Platform Beyond Mobile Phone Applications

applications
Android Applications (Figure 5) comprise a package (.apk) that includes application DalvikVM byte code and
metadata handled by the framework system services, such as Package Manager or Activity Manager. Metadata
includes all the necessary information to manage an application within the system such as list of Activities,
Services, application entry point, user interface layout, and so on.

Android Applications work on top of the Application Framework APIs. Each application is represented by an
Activity or a Service that runs in a separate instance of the DalvikVM and requests system services via AIDL/Binder
IPC mechanisms.

All applications are Java programs. However, they may make use of native shared libraries via DalvikVM JNI bridge.

An application can implement a service and expose it for other applications. A good example of this is a phone
application that provides a Bluetooth handset profile service to control Bluetooth headsets. A phone application is
one of the default applications set by Google, as well as SMS, Contacts, Calendar, Web Browser, and Email.

Android Applications also provides additional security mechanisms to protect core system services and applications.
It defines certain permission and/or permission groups and application needs in order to do certain things, such as
making a phone call, accessing contacts information, etc. An Activity or Service can request specific permissions
and may require certain permissions to get accessed. Only if a calling application has the required permissions can
it launch a specific Activity or bind to a specific Service.

Figure 5: Applications.

w w w. m e nto r. co m
7
Porting the Android Platform Beyond Mobile Phone Applications

Android Development
The Android OS is distributed as a complete code base along with necessary configuration files and build scripts
to build and deploy the Android images on a real hardware device or emulator. The Android build system is not
self-sufficient. Unlike the Android runtime environment, the build system relies on existing external tools such as
GNU tool chain, GNU make, and Oracle Java SDK 1.5. The Android build system does not require a complete GNU
tool chain since it does not depend on GNU libc.

The Android build system has a modular structure. It defines a common set of rules to build software packages
of various types such as native library or executable, Android framework library, or an Android application. Each
of the software packages has an associated “Android.mk” file that includes generic rules and provides necessary
information to build a module such as module source files, dependencies, type, and so on.

The build system is required to build the Android Framework and all software packages essential for system
functions. However, it’s not needed to develop external components, such as an Android application. One of
the build system outputs is the Android Software Development Kit (SDK).

The Android SDK is a subset of the build system with pre-built components and tools required to develop Android
applications in Java. It provides nice debugging capabilities by utilizing the Android Debug Bridge (ADB) to com-
municate with an Android device over USB or TCP/IP connection. The ADB allows for the collecting of device logs,
accessing the Android shell, and installing and debugging applications. To facilitate the application development
process, the SDK also provides a virtual QEMU-based target.

All SDK features are consolidated into an Eclipse-based Integrated Development Environment (IDE), which is an
Eclipse Android Development Tools (ADT) plug-in.

In some cases, it’s preferable to implement a part of an application as a shared library. For example, to achieve
better application performance or avoid porting an existing code to Java. The Android Native Development Kit
(NDK) facilitates this process by providing a set of command line tools and prebuilt libraries.

Android Framework Development

The Android source base, and in turn, its build system are managed with a mixture of existing open source tools
and tools developed and provided by Google. To keep the Android source code, Google utilizes an open source
software revisions control system git. Each of the Android software modules are kept in a dedicated git tree. To
manage multiple git trees, Google provides a command line repo tool. The repo tool requires a XML manifest file
that describes what Android modules need to be checked out and their revisions.

Once checked out, a repo tool can track the changes introduced to different Android software modules and
prepare them for submission to an Android code review and tracking system gerrit.

The Android code review process is based on multiple roles such as Author, Approver, and Verifier. It is performed
using the gerrit tool, which has a Web interface to track and review changes and is linked to the Android project
git trees to apply the changes once approved.

Android Applications Development

Applications are developed outside of the build system using the Android SDK and NDK. Normally a developer will
use an Eclipse ADT. It’s important to remember that all Android applications are actually Java programs developed
with standard Java tools. The complete Android API and Java libraries are available to develop applications.

w w w. m e nto r. co m
8
Porting the Android Platform Beyond Mobile Phone Applications

The Eclipse ADT will set up a new Android project, assist to create an application user interface, build an application
package (.apk), and deploy it on a virtual or real hardware target using ADB.

Sometimes a developer will make a decision to implement a portion of an application as a natively compiled
library. The Android NDK provides all the necessary tools to build a shared library, but it’s not integrated into the
Eclipse IDE. The library is separately installed to the Android target device and can be linked and accessed in run-
time from Java code using DalvikVM JNI bridge.

Accelerating Embedded Development with Android

The Android OS platform has been growing so fast that more companies and individuals are getting involved in
development and submitting their changes back to the Android project, which helps Google define the future
direction of Android. The fact that Android is licensed under permissive open source licenses makes it attractive
for commercial vendors since it reduces risk of releasing proprietary software and sharing secrets.

Since its first commercial release (“Cupcake”), the Android platform has become a dominate mobile software
platform in the United States. But Android has found its way into non-handset devices as well and is now
implemented by industrial-grade suppliers to deliver next generation products.

From a technical perspective, the Android OS is a complete application framework on top of the well-known Linux
kernel that supports many different architecture and processors. It has sophisticated functionality and provides
numerous capabilities to develop interactive user applications with attractive user interfaces such as games,
Internet services, media players, and so on.

The key feature of the Android design is that it’s based on Java and gets converted to a machine independent byte
code that’s simply re-used without explicit porting to any of the devices running Android. Therefore, the amount of
foundation work required to build a product platform based on the Android OS is significantly less compared to
migrating and building a platform based on other existing operating systems such as Linux OS. Figure 6 provides a
relative comparison of the amount of foundation required to build devices based on Android versus Linux OS.

Figure 6: Android vs. Linux OS.

w w w. m e nto r. co m
9
Porting the Android Platform Beyond Mobile Phone Applications

Android is available as a complete code base and is supplemented by a comprehensive set of tools to perform
development in the Android Framework and creating new Android applications. Android architecture makes it
possible to leverage thousands of available applications and create a home-grown Android application store, which
does not have to be limited to a specific set of applications “certified” to work on a device. An application store can
be easily expanding to provide any Android applications coming from various sources.

The Android OS implements security features on different levels. Starting from the Linux kernel which provides
basic permission mechanisms to system resources – all the way up to the framework level ensuring that an
application cannot access system capabilities (Services) without having required permissions. The Android OS is
designed in a way to protect system core functions from applications that could potentially misbehave.

Challenges porting the android os

The Android OS has a great many design trade-offs, which make it flexible and scalable to satisfy the requirements
and needs of a variety of embedded systems. However, it should always be taken into account that Android was
created and implemented for mobile phones. Consequently, there are certain boundaries that can curtail
implementation decisions. On the surface, this might make the Android porting task more complicated, but
that’s simply not the case.

The phone stack is a major component of the Android Framework. There are phone-specific events and interfaces
defined at the framework level and implemented by the phone application and Services. A certain portion of the
Bluetooth API, namely support for the Bluetooth headset, is delegated to the phone application rather than making
it a general purpose API. Thus, making an embedded device equipped with a Bluetooth headset, used for non-
phone communications, is not straightforward with Android. The Contacts application is tied to phone
functionality and implements a phone dialer. While it’s reasonably straight forward to make a phone, this might
not work so well for other devices.

The Android stack assumes that certain I/O devices are present in a system. For example, a SD card is used as a
default non-volatile application data and content storage. Audio hardware is expected to be present and if
Bluetooth connectivity is presented, it has to be connected to audio over a hardware PCM link. User notification
mechanisms use LEDs and vibrator.

The following are a few key challenges developers might encounter when porting Android.

1) Android Human Machine and User Interfaces

The user interface is a key distinguishing feature for most embedded products, especially in the consumer market
where many suppliers are making similar gadgets. On one hand, Android is designed for easy software reuse.
However, it also leads to a problem as making an Android port to an embedded device won’t be enough because
it’s not going to look different from the others. The Android SDK does offer basic GUI customization, while the
major components such as Notification Bar and Home Applications have to be re-worked. It gets further
complicated by the fact that modifications might be required at the Android Framework level.

A user interacts with the Android OS using certain input methods such as a touch screen, track ball, and buttons.
Some buttons are handled at the Android Framework level, and in fact, play an important role in Android
architecture. Namely, home and back buttons, which are essential for Android operations since they are necessary
to manipulate tasks running in the system. Since Android operation relies on the buttons they have to be somehow
present in a system, i.e. either available at hardware level or emulated. However, the buttons that are emulated
might not be easy and implementation may vary depending on device requirements and use cases.

w w w. m e nto r. co m
10
Porting the Android Platform Beyond Mobile Phone Applications

2) Power Management
The Android OS implements a layered power management model working on top of standard Linux Power
Management capabilities controlled by the Android Framework and applications. The Android Power Manager
service implements a wakelock concept when applications request and hold wakelocks preventing the system
from entering sleep state.

The default Power Manager implementation controls backlight brightness and dims the backlight when there are
no applications active in a system. This achieves a good balance between device responsiveness and power
savings while idling, which is essential for a mobile phone. However, different embedded devices might have
different requirements where a different power management model needs to be implemented. For example,
entering a sleep state, such as to suspend RAM or suspend to disk. Another example is when a display has to be
always turned on while all unnecessary peripheral devices should be disabled to minimize power consumption.

Addressing such requirements will require major rework of the Power Manager service.

3) Boot time
Android takes a while to boot up. Actual boot time depends on various factors including the Android version and
hardware speed. For many embedded products, a fast boot time is one of the key requirements and as such,
Android might not fit well in that scenario.

Android takes as much time to boot as it needs to go through all boot steps. For example, DalvikVM does not
work directly with byte code generated during Android build. Instead, it works with optimized byte code version
(DalvikVM cache) which is generated in runtime on a target device. DalvikVM caches have interdependencies
between each other. During boot process, Android needs to make sure that DalvikVM cache is valid and the whole
system is consistent. Another example is a Package Manager that scans for available application packages in the
system and dynamically generates a runtime list of installed packages and then creates runtime data for Intents
resolver. Both these design trade-offs allow developers to achieve faster runtime performance and flexibility (e.g.
application installation process is quite straightforward) with sacrificing Android boot time.

There is no common solution to speed up Android boot time. If one existed it would have already been
implemented. However, based on particular product use-cases, requirements, and implementation, certain
methods and techniques could be used to identify and optimize boot-up bottlenecks.

The boot process has multiple stages. First, it is necessary to make sure that both a boot loader and Linux kernel
are optimal. There are a number of tools available to profile the Linux kernel and Android early in the process such
as kernel tracers and bootchart. Oprofile could also be used to perform a system wide profiling and profiling
particular components to find bottlenecks.

Sometimes the order in which system services are loaded may impact the total boot time. The interdependencies
between system services should be carefully examined and proper boot order is determined.

File storage type and partitioning scheme also can have impact on system boot time. Rebuilding a DalvikVM cache
in runtime during system boot could be faster than reading and checking prebuilt caches from external storage.

Also complete system shut down and startup sequences could be eliminated by using system sleep states such as
“suspend to RAM” and “suspend to disk.” It might not be always appropriate but if system configuration is fixed it
could help.

w w w. m e nto r. co m
11
Porting the Android Platform Beyond Mobile Phone Applications

Figure 7: Extending Android.

Extending Android
Making a non-handset device in Android might require extending Android to provide new functions depending on
embedded product purposed. Simply put, the phone stack needs to be taken out and some other software unique
to the product needs to be implemented or integrated. And it might have to be done on all levels of Android as
depicted on Figure 7.

New device drivers (from the Android perspective) can be added or enabled in the Linux kernel. Some native code
would have to be implemented to interface with the driver over system call interfaces and be accessible of Java
framework extension over DalvikVM JNI bridge. The framework extension could implement new system services,
modify existing source (e.g. change a notification bar design). New Intents or AIDL might be added at the
framework level as well, as new permission groups for applications use them. And on top, the Android API could
be extended for applications to use for new Android functions.

This also introduces the problem of maintaining product-specific Android extensions in regards to upgrading to
future Android releases. This might be considered a disadvantage for Android. However, there is another problem
that deserves a separate discussion, which is integrating an existing source code into Android.

Legacy software integration

It’s very likely that Android could be selected to create a next generation of existing embedded products which
entails migrating from some other OS. In this case, the software implementing the necessary functions could
already exist and should be integrated to Android.

w w w. m e nto r. co m
12
Porting the Android Platform Beyond Mobile Phone Applications

Even though Bionic libc and core libraries are derived from a UNIX-like operating system, it’s been done with a
minimalistic approach, providing only those system functions that are required to run Android. Thus, certain
libraries and interfaces used by the software working in the GNU environment might not be available in Android.
Several examples include:

▪▪ No SysV IPC support

▪▪ No STL support

▪▪ Partial pthreads support

▪▪ No Linux-headers package

▪▪ Minimal “scrubbed” set of headers

This means that compiling GNU-based software might be a difficult task and will require either changes to existing
source code or Bionic. This might not be acceptable for various reasons. If this is the case, another approach should
be considered to make use of legacy software in the Android runtime environment.

Figure 8: Running both GNU and Bionic in parallel.

w w w. m e nto r. co m
13
Porting the Android Platform Beyond Mobile Phone Applications

Co-existing GNU and Bionic

One of the methods of using existing GNU-based software is to run both GNU and Bionic runtime environments
in parallel as depicted in Figure 8. In this case, Android would communicate with GNU-based software via IPC
mechanisms provided by the Linux kernel. It could be a native Android IPC such as Binder, if the GNU runtime is
extended to support it, or conventional mechanisms such as network sockets. The existing software could be
extended by an upper-level communication layer, which would be kept separately from original software that
stays untouched.

The multi-OS approach

Sometimes a situation might arise when a hybrid approach described previously might not be possible for various
reasons. Migration to Android could be performed from a different operating system either commercial or home
grown. Certain system requirements need to be implemented such as performance, boot time, response time, or
other real-time characteristics. Android software licenses reduce the risk of releasing software IP, but might not
completely mitigate it. Certification might be required for certain software, which could be more difficult if it’s a
part of Android.

The list of reasons could easily continue, but there may be one solution to address most of them. It’s running the
Android OS in parallel with another operating system. The solution for this scheme could vary depending on
features provided by the SoC.

Figure 9: The multi-OS approach.

In case of single core, various virtualization solutions (commercial or open source) could be utilized. For multicore
processors, it can be either virtual machine/hypervisor or both OSes could run on separate cores with static
hardware resource separation.

The communication between OSes (Figure 9) is provided by the virtualization layer (e.g. virtual network) or it
can be explicitly be implemented for both OSes via shared system resources, such as shared memory and inter-
processor interrupts (e.g. MCAPI).

w w w. m e nto r. co m
14
Porting the Android Platform Beyond Mobile Phone Applications

Applications for the multi-OS approach could be embedded products with a user interface driven by Android and
core device functions run by other OSes/RTOS. Examples include multi-function printer, Automotive IVI systems,
medical devices and so on.

Hardware resources
With its great design, Android is not a true embedded OS that fits a minimal system configuration. By using Java,
it achieves high machine independency levels requiring more processor power and memory to run. All rich
graphics and multimedia capabilities provide more than ample room for creativity designing user interfaces and
corresponding applications, but it will require more processor power and memory, as well as hardware assistance
for graphics operations and audio/video decoding to off-load main processor core.

Modern processors and graphics acceleration features are sufficient to power Android. However, selecting a higher
level SoC and adding more memory will impact the cost of a final product. So there are always open questions that
need to be carefully analyzed before making a final decision towards migration to Android.

▪▪ Is it going to be a display-driven device?

▪▪ Is a processor powerful enough to run Android?

▪▪ Is there hardware acceleration for graphics and multimedia available?

▪▪ What is the memory budget?

Obviously, there are no common answer to all of these questions. It all depends on product requirements and use
cases. Sometimes, having a low-power processor with a reduced feature set is enough – if there are no multimedia
or graphics requirements. If display size is small enough there may not be a need for installing large amount of
memory. Having source code integrated to Android rather than running in parallel using some sort of virtualization
approach might impact hardware cost, reducing software implementation costs.

Conclusion
Android is a rapidly growing software platform. Even though it was originally created for mobile phones, it is
quickly being deployed on many different types of embedded devices. By performing a low-level Android port
to an embedded device, it will bring the complete Android Framework available leveraging existing Android
applications. There are certain challenges in making an Android-based product. However, once these problems
are addressed the development cycle for future revisions will significantly shorten.

w w w. m e nto r. co m
15
Porting the Android Platform Beyond Mobile Phone Applications

References for market data:

http://www.digitaltrends.com/mobile/only-36-2-percent-of-android-devices-run-froyo/

http://www.pcworld.com/article/209803/developers_will_focus_on_winpho7_and_android_apps_in_2011.html

http://www.computerworld.com/s/article/9194278/Android_phones_outsell_iPhone_2_to_1_says_research_firm

http://www.androidtapp.com/list-of-android-devices/

http://en.wikipedia.org/wiki/Comparison_of_Android_devices

About the Author

A Software Architect at Mentor Embedded Professional Services, Vlad Buzov has more than 7 years experience in
Embedded Linux programming which includes porting, customizing and optimizing existent products, and developing
new custom solutions based on open source components for Mentor Embedded customers. Prior to Mentor, Vlad
served as Senior Engineer at Embedded Alley and MontaVista Software. Originally from Russia where Vlad received his
Master Degree in Computer Science from St. Petersburg State University, he is now based in San Jose, California.

Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries

For the latest product information, call us or visit: w w w.m e n t o r.c o m

©2010 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and
may be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies.
In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks
mentioned in this document are the trademarks of their respective owners.

MGC 12-10 TECH9390-w