38,39 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Create the perfectly customized system by unleashing the power of Android OS on your embedded device
About This Book
- Understand the system architecture and how the source code is organized
- Explore the power of Android and customize the build system
- Build a fully customized Android version as per your requirements
Who This Book Is For
If you are a Java programmer who wants to customize, build, and deploy your own Android version using embedded programming, then this book is for you.
What You Will Learn
- Master Android architecture and system design
- Obtain source code and understand the modular organization
- Customize and build your first system image for the Android emulator
- Level up and build your own Android system for a real-world device
- Use Android as a home automation and entertainment system
- Tailor your system with optimizations and add-ons
- Reach for the stars: look at the Internet of Things, entertainment, and domotics
In Detail
Take a deep dive into the Android build system and its customization with Learning Embedded Android Programming, written to help you master the steep learning curve of working with embedded Android. Start by exploring the basics of Android OS, discover Google's “repo” system, and discover how to retrieve AOSP source code. You'll then find out to set up the build environment and the first AOSP system. Next, learn how to customize the boot sequence with a new animation, and use an Android “kitchen” to “cook” your custom ROM. By the end of the book, you'll be able to build customized Android open source projects by developing your own set of features.
Style and approach
This step-by-step guide is packed with various real-world examples to help you create a fully customized Android system with the most useful features available.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 297
Veröffentlichungsjahr: 2016
Ähnliche
Table of Contents
Learning Embedded Android N Programming
Learning Embedded Android N Programming
Copyright © 2016 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: July 2016
Production reference: 1260716
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78528-288-1
www.packtpub.com
Credits
Authors
Ivan Morgillo
Stefano Viola
Reviewer
Andrew Reitz
Commissioning Editor
Nadeem Bagban
Acquisition Editor
Kirk D'costa
Content Development Editor
Sanjeet Rao
Technical Editor
Narsimha Pai
Copy Editors
Dipti Mankame
Laxmi Subramanian
Project Coordinator
Judie Jose
Proofreader
Safis Editing
Indexer
Hemangini Bari
Graphics
Kirk D'penha
Production Coordinator
Shantanu N. Zagade
Cover Work
Shantanu N. Zagade
About the Authors
Ivan Morgillo is a computer engineer, a conference speaker, and a community organizer. He is passionate about programming and embedded systems—from DIY domotics to Android devices.
He is cofounder of Alter Ego Solutions, a mobile development consulting company.
He is also the author of RxJava Essentials, by Packt Publishing and Grokking Rx, by Manning Publications.
I want to thank my sister, Selenia, and my mother for their love and support.
Stefano Viola is an embedded software developer with proved experience with Linux embedded devices and microcontrollers. He is an Android platform expert and application developer. He is passionate about programming and embedded systems, from DIY domotics and robots to customized Android devices.
He is currently working at SECO as an embedded software engineer. He is part of AXIOM project, an R&D project by the European Community, and the UDOO team.
I want to thank my wife, Carolina, my friend, Antonio, and my family for their love and support.
About the Reviewer
Andrew Reitz is an Android developer by day and an outdoor enthusiast by night. He is a maintainer of the Groovy Android plugin and Android Spock. Besides programming, Andrew likes rock climbing, biking, camping, and hanging out with his dog.
www.PacktPub.com
eBooks, discount offers, and more
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www2.packtpub.com/books/subscription/packtlib
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can search, access, and read Packt's entire library of books.
Why subscribe?
Preface
Android has caused one of the greatest revolutions of our time. Being present on smartphones, TV, tables, watches, embedded boards, it can be considered ubiquitous. Its open source nature gives companies, expert users, and hackers the opportunity to learn from, improve, and customize the system, creating a tailored version of the most popular mobile operating system.
This book is a journey from the origins of the Android project to what's in the future, walking through all the phases needed to build a custom Android system from source and from binary images.
What this book covers
Chapter 1, Understanding the Architecture, explains the Android hardware and software architecture, the Android Compatibility Definition Document, the Android Compatibility Test Suite, and the Android Runtime.
Chapter 2, Obtaining the Source Code – Structure and Philosophy, explains the Android Open Source Project.
Chapter 3, Set up and Build – the Emulator Way, teaches how to set up the build environment and build a system image for the Android Emulator.
Chapter 4, Moving to Real-World Hardware, tells you about how to build a real device and how to flash the system image.
Chapter 5, Customizing Kernel and Boot Sequence, dives into kernel and boot sequence customization, in order to tailor the perfect system.
Chapter 6, "Cooking" Your First ROM, discusses about custom recovery images, root privileges, and Android Kitchen.
Chapter 7, Tailoring Your Personal Android System, discusses hacking the Android framework, adding apps, and optimizing the system.
Chapter 8, Beyond the Smartphone, discusses what's next, what the Android possibilities are once you step away from the smartphone world.
More about Android N Programming: In this chapter, you will find some more information about Android N Programming at https://www.packtpub.com/sites/default/files/downloads/MoreaboutAndroidNProgramming.pdf.
What you need for this book
All you need for the journey is a personal computer, Ubuntu Linux or OS X will do, an Internet connection, and your passion!
Who this book is for
If you are a programmer or embedded systems hacker who wants to customize, build, and deploy your own Android version, then this book is definitely for you.
Conventions
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "We can include other contexts through the use of the include directive."
A block of code is set as follows:
Any command-line input or output is written as follows:
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "Clicking the Next button moves you to the next screen."
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail <[email protected]>, and mention the book's title in the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
You can download the code files by following these steps:
You can also download the code files by clicking on the Code Files button on the book's webpage at the Packt Publishing website. This page can be accessed by entering the book's name in the Search box. Please note that you need to be logged in to your Packt account.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Learning-Embedded-Android-N-Programming. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at <[email protected]>, and we will do our best to address the problem.
Chapter 1. Understanding the Architecture
In this chapter, the user will learn about Android hardware and software architecture. We will provide an overview on the Android Compatibility Definition Document to properly understand what we need in order to create a fully compliant and certified device.
The user will learn about the Android Application Framework (AAF), the two different Android runtime systems—Dalvik, and ART, and a collection on Google-provided system libraries.
The user will have a first hands-on moment, setting up and running Android Compatibility Test Suite. We will test together an existing certified device and we will take the first step on the path towards the creation of a certified device.
An overview of the Android system
Android, as with every other operating system, has a layer-based structure. The next image shows a properly abstracted overview of the whole system architecture:
We can divide the system into the following main layers:
The software layer closest to the hardware architecture is the Linux kernel. This layer is in charge of communicating with the hardware components and provides an easy-to-use interface for the layer above.
Moving up on the architecture path, we have Android runtime and core libraries. This layer provides the basics tools for the application framework. The application framework is a collection of ready-to-use components that the system provides to the Applications layer via the Android SDK. The top layer contains all those applications we use everyday—games, productivity apps, multimedia, and so on.
Linux kernel
Android is based on the Linux kernel, but it's not a classic Linux-based desktop system: it's not Ubuntu. However, Android architecture designers and developers rely on the Linux kernel, because it's open source, it's extensively tested worldwide, and it can be easily tailored to fit Android-specific hardware needs, on any kind of device.
From a very pragmatic point of view, choosing to base the system on an open source heart reinforced the Android philosophy of being an open system, supported by its community and trusted by enterprise companies, thanks to its transparency. Besides, this approach saved a lot of development time—they didn't have to start from scratch and they could focus on the rest of the architecture, taking advantage of a popular and well-documented core.
The vanilla Linux kernel needed some love to properly fit all the Android requirements. Most of the contributions by Google were focused on:
From a hardware point of view, the Android team made a great effort to add new goodies to the Linux kernel. Lots of fixes and hacks were released to improve Bluetooth support and management, lots of General Purpose Input/Output (GPIO) drivers were added, ARM compatibility was enhanced, as ARM was the primary Android-supported architecture and also MMC management received lots of contributions. The new ADB gadget driver was added to help developers to communicate via USB with external devices.
From a memory point of view, the Android team introduced PMEM, the process memory allocator. This gave the ability to manage large physically contiguous memory regions between user space and kernel space. Working in a specific low-resource hardware domain, the Android team released Ashmem, Android Shared Memory, which targeted low-memory devices and provided an easy-to-use file-based API to manage shared memory, especially under memory pressure.
From a power management point of view, the Android team introduced an improved suspend system, wakelocks, and Android Alarm Timers, the kernel implementation to support Android Alarm Manager.
The other interesting contributions were the kernel support for Android logcat command, that provides logs of system messages, application debug messages, and exceptions, and Android Binder, an Android-specific interprocess communication system, used for remote method invocation too.
Hardware abstraction layer – HAL
To overcome the increasing hardware fragmentation, Android engineers created an abstraction layer that allows the system to interact with the hardware just being aware of a specific intercommunication interface. The system completely ignores the low-level implementation of hardware and drivers. This approach enforces the idea of developing software against an interface instead of against an implementation. With this approach, the Android system does not know and does not need to know how hardware is accessed or managed.
As a mid-level layer between the hardware and the system, Android HAL is commonly developed using native technology—C/C++ and shared libraries. There is no constraint from Google about how we need to implement our HAL and our device drivers: it's up to us to design it as we think best for our scenario. There is only one simple rule:
Our implementation must provide the same interface that the system is expecting.
Libraries and the application framework
Going up on the architecture ladder, we find the two most important software layers. The Android application framework and Android system libraries are the middleware between the bare hardware, managed by the Linux kernel, and all those fancy, shiny apps we have on our smartphones.
Libraries
Android system libraries are a set of libraries, specifically created to work on Android, to allow and help with system components and app development. The most important are:
The application framework
This is the core of the Android software ecosystem. It provides a plethora of managers that facilitate the most common tasks of Android developers and the Android system itself. The most important components of the Application Framework are:
Everything on Android is achieved using the official Android SDK that provides a consistent and documented way to use all these system managers, views, and logic components to let you create the next big hit of the Google Play Store.
Binder IPC
From an Application Framework point of view, the Binder Inter-Process Communication (IPC) is a hidden layer. It takes care of creating a transparent communication channel between the high-level Android API, accessible via the Android SDK, and the actual Android system.
The application layer
All the applications created by third-party entities, such as smartphone manufacturers or Android programmers will be installed on the application layer.
Usually, this relies on a read/write area of the handset solid memory, but for software provided by manufacturers, typically, it uses a read-only memory area to be sure that these applications will always be installed no matter what. Apps such as Google Maps, YouTube, Samsung TouchWiz Nature, and HTC Sense are examples of apps in this very group: they are shipped with the device's operating system, they are installed on a read-only memory area of the device, and they are meant to be uninstallable as a core component of the system.
As we will see, this is not 100% true—once you have the proper skill set, you will be able to manipulate the whole system. In the following chapters, you will acquire these skills and you will learn how to heavily modify an already existing Android version and get rid of those apps, if necessary.
Android compatibility
Every successful Android device on the market, before being launched, has been certified. Manufacturers have designed, developed, and tested their device according to precise guidelines, rules, and constraints.
To make the task as easy as possible, Google has created the Android Compatibility Program that defines details and tools that help OEMs to create a device that will properly support the OS, the SDK, and the developers' expectations:
"To run Android apps on a variety of Android devices."
As a manufacturer, creating and distributing a certified device has critical importance. Our goal is to create a device with a unique, but at the same time familiar, user experience: we have to be cool, but not weird! Users want to customize their Android device and they want to be sure that their favorite apps will run smoothly, without problems of any sort. Developers want to be sure that they won't waste time fixing bugs on every different smartphone, tablet, or TV—they want a common ecosystem on which they can rely.
A well-defined and well-supported ecosystem brings more certified devices that bring more and more developers that bring more and more happy users. The following diagram shows exactly how the Android ecosystem lives thanks to the constant creation of well-designed, well-produced, certified devices:
The Android Compatibility Definition Document
The Android Compatibility Definition Document (CDD) is Google's way to specify guidelines, rules, and constraints to be considered for an Android-compatible device. Every device designer and manufacturer has to refer to the CDD to be able to easily port Android onto its own hardware platform.
For each release of the Android platform, Google provides a detailed CDD. The CDD represents the policy aspect of Android compatibility and its role is to codify and clarify all the requirements and eliminate any ambiguity. The main goal is to provide rules for manufacturers to let them create complex hardware devices, compatible with Android SDK and Android apps.
Designing and developing a new device is no easy task. Even the smallest detail matters. Think about OpenGL support. There is no possible way to be sure that the graphical experience will be great for the user. The only thing that's possible is working according to the guidelines and then "test, test, and test". That's why providing as many details and guidelines as possible is the only way to help the manufactures to achieve their goal.
However, the CDD does not attempt to be comprehensive—it couldn't be. It just serves as guidance to approach as easily as possible the final goal—a compatible device. Further help comes from the source code itself and from the Android SDK API that can be considered a compatibility-proof test bench. Think about CDD as an overview of the minimum set of constraints to be compliant with: it's the very first step of the journey.
Device types
In the beginning, Android was born to run on digital cameras. Luckily for us, a lot has happened since then: smartphones invaded our world! Then we had tablets and mp3 players. Nowadays, we have TVs, watches, media centers, glasses, and even cars, running Android and Android apps. Every device on the market will probably land in one specific category, according to its features. CDD gives a few pointers about which category your new device would be placed in:
Software compatibility
From a software execution point of view, the basic requirement is being capable of executing the Android Dalvik bytecode. Our device must support the Android Application Programming Interface and must provide complete implementations of any documented behaviors of any documented API exposed by the Android SDK or annotated with the @SystemAp annotation.
Hardware compatibility is a tricky task, because even if our device is lacking some specific hardware, for instance GPS or accelerometers, our implementation must contain GPS-related code and should be capable of handling inappropriate requests in a reasonable way to avoid crashes or misbehaviors.
One of the main players of software compatibility is the ability of our device to support intents. Every device properly implementing Android API must support Android loose-coupling intent system. Intents allow Android apps to easily request functionality from other Android components and avoid the effort to implement everything from scratch. The Android system has a set of core applications that implement the intent pattern:
As a vendor, we could integrate the default Android components or implement our own component, according to the public API. Those components will have special system permissions to act as system apps and they will be the first proposed choice for the matching intent filter.
For instance, when a developer ask to open a web page, the system will suggest "our browser component" as the first chosen app to perform the task. Of course, being a good citizen means that we must provide a proper settings menu to give the user the possibility to override our default choice and let the final user pick a different app for the task.
Beyond Java
Android applications development is mostly based on Java programming. The SDK is based on Java, the runtime system is fully compliant with Java6, partially with Java7, and Google is already experimenting with Java8. Most developers will easily approach the platform if they already know Java programming language. However, Android offers a lot more to those developers that are dealing with heavy-duty, performance-oriented scenarios: Android Native API.
Native API
Native API gives the developers the opportunity to call native C, and partially C++, code from an Android Java application. Native code is compiled as standard ELF .so files and stored in the app APK file. Being native code, it has to be compiled for every architecture we are going to support, because, contrary to the bytecode, it can't be built once and run on every architecture.
As integrators, we must embrace one or more Android Application Binary Interfaces (ABIs) and aim for having full compatibility with the Android NDK. Of course, Google provides guidelines and constraints to easily reach this goal. These are the basic rules for proper compatibility:
From a libraries point of view, our implementation must be source-compatible (that is, header compatible) and binary-compatible (for the ABI) with all the following libraries:
These libraries also provide minimal support for the C++ JNI interface as well as support for OpenGL.
An implementation of each one of these libraries must be present in our system to be compatible with Android NDK. This is a dynamic list and we cannot treat it as a definitive set of libraries: future versions of Android could add new libraries and increase development possibilities and scenarios. That's why native code compatibility is challenging. For this reason, Google strongly suggests to use the implementations of the libraries listed earlier from the Android Open Source Project, taking advantage of the Open Source philosophy of Android and to enjoy well-supported and well-tested source code.
Maintaining 32-bit support
Nowadays, all major manufactures are switching to 64-bit architecture and new ARMv8 architecture deprecates lots of old CPU operations. Unfortunately, the market is still full of 32-bit compatible software and even on 64-bit architecture we must still support these deprecated operations, to avoid scaring developers and losing precious market share. Fortunately, we can choose to make them available via real hardware support or software emulation, at the expense of performance.
Supporting 32-bit architecture can be very tricky. We can just think about one simple scenario, for example, accessing the /proc/cpuinfo file. Legacy versions of the Android NDK used /proc/cpuinfo to discover CPU features. For compatibility with applications built using 32-bit NDK, we must specifically include the following things in /proc/cpuinfo when it is read by 32-bit ARM applications:
The tricky part is that these requirements only apply when /proc/cpuinfo is read by 32-bit ARM applications. The file must be not altered when read by 64-bit ARM or non-ARM applications.
From Dalvik to ART runtime
The original Android runtime implementation was Dalvik. Dalvik was a virtual machine, specifically created for Android, due to the necessity to target low-memory devices. It was an integral part of the system until Android KitKat.
As we already said, Android applications are mostly written in Java. When Dalvik was the in-use runtime system, the Java code was compiled into bytecode. This bytecode was then translated to Dalvik bytecode and finally stored into a .dex (Dalvik Executable). After this procedure, Dalvik was able to run the Android app.
Although Dalvik had been designed for slow devices, with low memory, its performance has never been astonishing, not even when the Just-In-Time compilation was introduced, back with Android 2.2 Froyo. Dalvik JIT was supposed to bring a huge performance boost to Android apps and, from some points of view, it did, but with limitations, such as the infamous maximum methods number, and the pressure from alternative solutions forced Google to look forward to a new runtime:
The Android runtime
When Android 4.4 KitKat was released, users could select a new experimental runtime environment in the Settings
