嵌入式Android开发：ROM定制与系统内核探索

需积分: 10 4 浏览量更新于2024-07-22 收藏 1.85MB PDF 举报

"嵌入式Android开发，涉及到ROM定制，Porting、Extending和Customizing" 在嵌入式Android开发中，我们关注的是将Android操作系统适应并优化到各种硬件平台，尤其是那些非传统的移动设备，如智能家居设备、汽车娱乐系统、医疗设备等。这通常涉及到对Android系统的深度理解和定制，以满足特定硬件的需求。标题"嵌入式android开发"指出了这个领域的主要工作内容，即在嵌入式设备上进行Android应用和系统的开发。这一过程包括了Porting（移植）、Extending（扩展）和Customizing（定制），意味着需要将Android操作系统从一个平台迁移到另一个平台，并根据目标硬件的特性进行相应的功能添加和个性化调整。描述中的"rom定制"是嵌入式Android开发的一个关键环节，ROM（Read-Only Memory）定制涉及到修改Android的核心组件，如内核、系统库和框架服务，以适应特定硬件的性能和功耗要求。开发者可能需要调整启动流程、优化驱动程序、集成新的功能模块，甚至创建独特的用户界面，以提供与标准Android系统不同的用户体验。标签"android rom"进一步强调了对Android系统固件的定制。固件定制不仅包含系统级别的修改，也涵盖了应用程序和服务的定制，例如预装特定的应用程序，或者修改系统设置以提升设备性能或增强安全特性。部分内容详细列出了嵌入式Android开发的一些核心概念和技术。例如，"AppDeveloper's View"讨论了从应用开发者角度看到的Android系统，包括Android的基本概念、框架介绍以及应用开发工具。"Android Concepts"涵盖了Android的基本架构和设计理念，比如组件化、生命周期管理等。"Framework Intro"则涉及到了Android框架层，它是应用与系统服务交互的关键部分。 "Native Development"提到了C/C++原生代码开发，这是为了实现高性能和低级别硬件控制所必需的。"Linux Kernel"部分强调了Android基于Linux内核的事实，开发者需要了解如何为特定硬件配置和优化内核。"Wakelocks"和"Low Memory Killer"则涉及到电源管理和内存管理策略，这些都是嵌入式系统优化的关键，因为这些设备通常电池寿命有限，内存资源也更为宝贵。 "Binder"是Android系统中的关键IPC（Inter-Process Communication）机制，它允许不同进程间的数据交换和服务调用。"Anonymous Shared Memory (ashmem)"是一种高效的数据共享方式，而"Alarm"和"Logger"则涉及到了系统定时器和日志记录系统，对于调试和性能监控至关重要。此外，文件中还提到了"Compliance Requirements"，即设备必须满足的Android兼容性标准，以确保应用的兼容性和用户体验的一致性。"Compliance Test Suite"则是一套测试工具，用于验证设备是否符合这些标准。嵌入式Android开发是一个涵盖硬件适配、系统定制、性能优化等多个层面的复杂过程，需要开发者具备扎实的Linux基础、深入的Android系统理解，以及一定的硬件知识。随着物联网(IoT)的发展，嵌入式Android开发的重要性只会进一步增加。

been a true open source project, a public mailing list archive would exist where all this

information, or pointers to it, would be available.

That being said, it's important to remember how significant a contribution Google is

making by distributing Android under an open source license. Despite its awkward

development model from an open source community perspective, it remains that Goo-

gle's work on Android is a godsend for a large number of developers. Plus, it has ac-

complished one thing no other open source projects was ever able to: create a massively

successful Linux distribution. It would, therefore, be hard to fault Android's develop-

ment team for their work.

Furthermore, it can easily be argued that from a business and go-to-market perspective

a community-driven process would definitely knock the wind out of any product an-

nouncements Google would attempt to release, making it impossible to create "buzz"

around press announcements and the like since every new feature would be developed

in the open. That is to say nothing of the non-deterministic nature of community-driven

processes that can see a group of people take years to agree on the best way to implement

a given feature set. And, simply based on track record, Android's success has definitely

benefited from Google's ability to rapidly move it forward and generate press interest

based on releases of cool new products.

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 approx-

imate 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 prerog-

atives. Hence, in that version, very little regard was made to preserving backward com-

patibility with the phone form-factor. And given that, Google did not wish to make the

code available to avoid fragmentation of its platform. Instead, at the time of this writing,

6 | Chapter 1: Introduction

plans are that both the phone and tablet form factor support will be merged into the

upcoming Android 4.0/Ice-Cream Sandwich release.

Ecosystem

As of June 2011:

• 400,000 Android phones are activated each day, up from 300,000 in December

2010 and 200,000 in August of that same year.

• The Android Market contains arond 200,000 apps. In comparison, the Apple App

Store has 350,000 apps.

• More than a third of all phones sold in the US are based on Android.

Android is clearly on the upswing. In fact, Gartner predicted in April 2011 that Android

would hold about 50% of the smartphone market by 2015. Much as Linux disrupted

the embedded market about a decade ago, Android is poised to make its mark. Not

only will it flip the mobile market on its head, eliminating or sidelining even some of

the strongest players, but in the embedded space it is likely going to become the de-

facto standard UI for a vast majority of user-centric embedded devices.

An entire ecosystem is therefore rapidly building around Android. Silicon and system-

on-chip (SoC) manufacturers such as ARM, TI, Qualcomm, Freescale, NVidia and TI

have added Android support for their products, and handset and tablet manufacturers

such as Motorola, Samsung, HTC, Sony-Ericsson, LG, Archos, DELL, ASUS, etc. ship

an ever-increasing number of Android-equipped devices. This ecosystem also includes

an increasing number of diverse players, such as Amazon, Verizon, Sprint and

Barnes&Nobles, creating their own application markets.

Grass-roots communities and projects are also starting to sprout around Android, even

though it is developed behind closed doors. Some of those efforts follow in the footsteps

of phone modders, which essentially rely on hacking the binaries provided by the man-

ufacturers to create their own modifications or variants, while others have a more open

source tint to them, relying on the Android sources to create their own forks or addi-

tions. The xda-developers.com online forum, for instance, is traditionally frequented

by modders, while the cyanogenmod.com site hosts an Android fork which modifies

the Android sources to provide additional features and enhancements. Other Android

forks include Replicant (http://replicant.us), which aims at replacing as many of the

Android components with Free Software as possible, and MIUI (http://en.miui.com/),

which provides some cool UI hacks.

A Word on the Open Handset Alliance

As I mentioned earlier, the OHA was the initial vehicle through which Android was

first announced. It describes itself on its website as "... a group of 82 technology and

mobile companies who have come together to accelerate innovation in mobile and offer

Ecosystem | 7

consumers a richer, less expensive, and better mobile experience. Together we have

developed Android™, the first complete, open, and free mobile platform."

Beyond the initial announcement, however, it is unclear what role the OHA plays. For

example, an attendee at the "Fireside Chat with the Android Team" at Google I/O 2010

asked the panel what privileges were confered to him as a developer for belonging to a

company which is part of the OHA. After asking around the panel, the speaker essen-

tially answered that they didn't know because they aren't the OHA. Hence, it would

appear that OHA membership benefits are not clear to the Android development team

itself.

The role of the OHA is further blurred by the fact that it does not seem to be a full-time

organization with board members and permanent staff. Instead, it's just an "alliance."

In addition, there is no mention of the OHA within any of Google's Android an-

nouncements, nor do any new Android announcements emanate from the OHA. In

sum, one would be tempted to speculate that Google likely put the OHA together

mainly as a marketing front to show how much industry support there was for Android,

but that in practice it has little to no bearing on Android's development.

Getting "Android"

There are two main pieces required to get Android working on your embedded system:

an Android-compatible Linux kernel and the Android Platform.

As of this writing, you cannot use a "vanilla" kernel from kernel.org to run the Platform.

Instead, you need to either use one of the kernels available within the AOSP or patch

a "vanilla" kernel for it to be Android-compatible. Unfortunately, while a few attempts

have been made to merge the Android modifications into the mainline kernel, these

efforts haven't yet succeeded. It is expected that, in the long term, the pending issues

will be resolved and the mainline kernel will support Android "out of the box." For the

time being, however, we must contend with the fact Android-compatible kernels are

essentially forks of the mainline and will continue being so for the foreseable future.

The Android Platform is essentially a custom Linux distribution containing the user-

space packages which make up what is typically called "Android." The releases listed

in Table 1-1 are actually Platform releases. We will discuss the content and architecture

of the Platform in the next chapter. For the moment being, keep in mind that a Platform

release has a similar role to standard Linux distributions such as Ubuntu or Fedora. It's

a self-coherent set of software packages that, once built, provides a specific user expe-

rience with specific tools, interfaces, and developer APIs.

8 | Chapter 1: Introduction

While the proper term to identify the source code corresponding to the

Android distribution running on top of an Android-compatible kernel

is "Android Platform," it is commonly referred to as "the AOSP"—as is

the case in fact throughout this book—even though the Android Open

Source Project proper, which is hosted at http://android.git.kernel.org/,

contains a few more components in addition to the Platform, such as

sample Linux kernel trees and additional packages that would not typ-

ically be downloaded when the Platform is fetched using the usual

repo command.

Hacking Binaries

Lack of access to Android sources hasn't discouraged passionate modders from actually

hacking and customizing Android to their liking. For example, the fact that Android

3.x/Honeycomb isn't available hasn't precluded modders from getting it to run on the

Barnes&Noble Nook. They achieved this by retrieving the executable binaries found

in the emulator image provided as part of the Honeycomb SDK and used those as-is

on the Nook, albeit forfeiting hardware accelaration. The same type of hack has been

used to "root" or update versions of various Android components on actual devices for

which the manufacturer provides no source code.

Legal Framework

Like any other piece of software, Android's use and distribution is constricted by a set

of licenses, intellectual property restrictions, and market realities. Let's look at a few of

these.

Code Licenses

As we discussed earlier, there are two parts to "Android": an Android-compatible Linux

kernel and an AOSP release. Even though it is modified to run the AOSP, the Linux

kernel continues to be subject to the same GNU GPLv2 license that it has always been

under. As such, remember that you are not allowed to distribute any modifications you

make to the kernel under any other license than the GPL. Hence, if you take a kernel

version from android.git.kernel.org and modify it to make it run on your system, you

are allowed to distribute the resulting kernel image in your product only so long as you

abide by the GPL and, therefore, make the sources used to create the image, including

your modifications, available to recipients under the terms of the GPL.

The kernel also includes a notice by Linus Torvalds in its COPYING file in its sources

that clearly identifies that only the kernel is subject to the GPL and that applications

running on top of it are not considered "derived works." Hence, you are free to create

Legal Framework | 9

applications that run on top of the Linux kernel and distribute them under the license

of your choice.

These rules and their applicability are generally well understood and accepted within

open source circles and by most companies that opt to support the Linux kernel or use

it as the basis for their products. In addition to the kernel, a large number of key com-

ponents of Linux-based distributions are typically licensed under one form or another

of the GPL. The GNU C libary (glibc) and the GNU compiler (GCC), for example, are

licensed under the LGPL and the GPL respectively. Important packages commonly used

in embedded Linux systems such as uClibc and BusyBox are also licensed under the

LGPL and the GPL.

Not everyone is comfortable with the GNU GPL, however. Indeed, the restrictions it

imposes on the licensing of derived works can pose a serious challenge to large organ-

izations, especially given geographic distribution, cultural differences amongst the var-

ious locations of development sub-units, and the reliance on external subcontractors.

A manufacturer selling a product in North America, for example, might have to deal

with dozens, if not hundreds, of suppliers to get that product to the market. Each of

these suppliers might deliver a piece which may or may not contain GPL'd code. Yet

the manufacturer whose name appears on the item sold to the customer will be bound

to provide source to GPL components regardless of which supplier originated them. In

addition, processes must be put in place to ensure engineers that work on GPL-based

projects are abiding by the licenses.

When Google set out to work with manufacturers on their "open" phone OS, therefore,

it appears that very rapidly it became clear that the GPL had to be avoided in as much

as possible. In fact, other kernels than Linux were apparently considered, but Linux

was chosen because it already had strong industry support, particularly from ARM

silicon manufacturers, and because it was fairly well isolated from the rest of the system,

so that its GPL licensing would have little impact.

It was decided, though, that every effort would be made to make sure that the vast

majority of user-space components would be based on licenses that did not pose the

same logistical issues as the GPL. That is why the vast majority of the components

created by Google for the AOSP are published under the Apache License 2.0 (a.k.a.

ASL) with some key components, such as the Bionic library and the Toolbox utility,

licensed under the BSD license. Some classic open source projects are also incorporated,

mostly as-is, into the AOSP within the external/ directory. The assumption is that their

distribution in binary form should not pose any problems since they aren't meant to be

typically customized by the OEM (i.e., no derived works are expected to be created)

and are readily available for all to download at android.git.kernel.org, thereby comply-

ing, if applicable, with the GPL's requirement that redistribution of derivative works

contibue being made under the GPL.

§ See this LWN post by Brian Swetland, a member of Android's kernel development team, for more information

on the rationale behind these choices.

10 | Chapter 1: Introduction

剩余131页未读，继续阅读

sashibulidana

粉丝: 3
资源: 10

嵌入式Android开发：ROM定制与系统内核探索

Android嵌入式系统程序开发（基于Cortex-A8）

Embedded Android Porting,Extending, and Customizing

《Android嵌入式应用开发 （第2版）》

嵌入式 Android开发智能家居

嵌入式Android开发环境配置-适用FS4412开发箱

嵌入式Android开发权威指南

嵌入式Android开发深入解析

深入理解嵌入式Android开发权威指南

嵌入式Android开发：架构移植指南

嵌入式Android开发指南：深入理解与实战

最新资源

《Android嵌入式应用开发（第2版）》