01-10-2012, 03:52 PM
Embedded Android
EmbAndroid.pdf (Size: 1.85 MB / Downloads: 94)
Introduction
Putting Android on an embedded device is a complex task involving an intricate understanding
of its internals and a clever mix of modifications to the Android Open
Source Project (AOSP) and the kernel on which it runs, Linux. Before we get into the
details of embedding Android, however, let's start by covering some essential background
that embedded developers should factor in when dealing with Android, such
as Android's hardware requirements and the legal framework surrounding Android and
its implications within an embedded setting. First let's look at where Android comes
from and how it's developed.
History
The story goes* that back in early 2002 Google's Larry Page and Sergey Brin attended
a talk at Stanford about the development of the then-new Sidekick phone by Danger
Inc. The speaker was Andy Rubin, Danger's CEO at the time, and the Sidekick was one
of the first multi-function, Internet-enabled devices. After the talk, Larry went up to
look at the device and was happy to see that Google was the default search engine. Soon
after, both Larry and Sergey became Sidekick users.
Despite its novelty and enthusiatic users, however, the Sidekick didn't achieve commercial
success. By 2003, Rubin and Danger's board agreed it was time for him to leave.
After trying out a few things, Rubin decided he wanted to get back into the phone OS
business. Using a domain name he previously-owned, android.com, he set out to create
an open OS for phone manufacturers. After investing most of his savings on the project
and having received some additional seed money, he set out to get the company funded.
Soon after, in August 2005, Google acquired Android Inc. with little fanfare.
Development Model
When considering whether to use Android, it's crucial that you understand the ramifications
its development process may have on any modifications you make to it or any
dependencies you may have towards its internals.
Differences With "Classic" Open Source Projects
Android's open source nature is one of its most trumpeted features. Indeed, as we've
just seen, many of the software engineering benefits that derive from being open source
apply to Android.
Despite its licensing, however, Android is unlike most open source projects in that its
development is mostly done behind closed doors. The vast majority of open source
projects, for example, have public mailing lists and forums where the main developers
can be found interacting with each other, and public source repositories providing
access to the main development branch's tip. No such thing can be found for Android.
This is best summarized by Andy Rubin himself: “Open source is different than a community-
driven project. Android is light on community-driven, somewhat heavy on
open source.”
Whether we like it or not, Android is mainly developed within Google by the Android
development team and the public is not privy to either internal discussions or the tip
of the development branch. Instead, Google makes code-drops every time a new version
of Android ships on a new device, which is usually every 6 months.
Feature Inclusion, Roadmaps, and New Releases
In brief, there is no publicly available roadmap for features and capabilities in future
Android releases. At best, Google will announce ahead of time the name and approximate
release date of the next version. Usually, you can expect a new Android release
to be made in time for the Google I/O conference, which is typically held in May, and
another release by year end. What will be in that release, though, is anyone's guess.
Typically, however, Google will choose a single manufacturer to work with on the next
Android release. During that period, Google will work very closely with that single
manufacturer's engineers to ready up the next Android version to work on a targeted
upcoming flagship device. During that period, the manufacturer's team is reported to
have access to the tip of the development branch. Once the device is put on the market,
the corresponding source code dump is made to the public repositories. For the next
release, they choose another manufacturer and start over.
There is one notable exception to that cycle: Android 3.x/Honeycomb. In that specific
case, Google has not released the source code to the corresponding flagship product,
the Motorola Xoom, and all indications suggest that that code may never be publicly
available. The rationale in this case seems to be that the Android development team
essentially forked the Android code-base at some point in time in order to start working
on getting a tablet-ready version of Android out ASAP based on market timing prerogatives.
Hence, in that version, very little regard was made to preserving backward compatibility
with the phone form-factor.