This document provides an overview of modifying and enhancing the Android OS. It describes the structure of the Android OS including applications, frameworks, Dalvik/ART runtime, libraries, and kernel. It also discusses how to build Android for a phone, what parts can be modified, and how to contribute changes back to the Android Open Source Project. The document is presented by Arnav Gupta, an undergraduate student and Android Framework Engineer at Cube26, an Indian startup focused on gesture-based features for Android.
1 of 87
Downloaded 18 times
More Related Content
Enhancing and modifying_the_core_android_os
1. Modifying and
Enhancing the Core
Android OS
Arnav Gupta
Student, DTU
Android Framework Engineer, Cube26
3. College
Undergrad student, Electronics and Electrical
Engineering, Delhi Technological University.
Expecting to graduate in 2016, (if I can survive
college for another 2 years)
4. Work Cube26
Joined - March 14
Android Framework Engineer
Working on projects of various clients like
Micromax, LAVA, Intex
Developing and integrating smart gesture
based interaction methods into Android OS.
Smart lockscreens, enhanced camera modes
for phones like Micromax Canvas A290, A310.
5. Work Open Source
Community
Contributor and developer on community
modded ROMs like CyanogenMod and AOKP
Open source development partner with Sony
Mobile
Making latest open source Android stack work
on Sony Xperia phones.
Developing various software-based features
for these modified versions of Android.
8. Applications
Everything opened from an
icon on the launcher is an app
Almost every user-facing
interface in Android is an app
Very generic in nature, and
rarely interdependent.
Bundled in the form of .apk
files, like we can get from the
Play Store.
9. Framework : SystemUI
Lockscreen, Status bar,
Notification pane, Navigation
bar
Defines how Toasts, Dialog
boxes look like
Lays out the basic look and
feel of the UI.
Packaged as .apk, but is
device-dependent, and not
100% generic.
10. Framework : Providers & APIs
Users do not interact directly.
To be used by 3rd party apps
Access to various data, hardware, sensors, media,
audio, graphics etc of the device.
Provides app developers uniform methods to interact
with lower stacks of the OS.
Media, graphics, audio etc implementation could be
significantly different across different hardware.
Provide and regulate access to contents and
services present on the device.
11. Dalvik / Android Runtime
An implementation much similar to the Java Virtual
Machine.
Dalvik older runtime. Now being superseded by a
newer Android Runtime from Android L.
Executes bytecode. Dalvik bytecode very much
similar to java bytecode.
All applications, including the Framework, run on the
Dalvik VM. Each process is a fork of zygote.
12. Libraries
Android contains a set of dynamically linkable
libraries (.so files, much like .dll of Windows) which
are required for various purposes.
Libraries like libc contain core functions, used by
almost every process. There are OpenGLES libs for
graphics, security and cryptography related libs like
libcrypto, libssl. Almost all hardware related
subsystems are accessible by Hardware Abstraction
Layer libs.
Apps are provided the features of libraries via the
APIs of the framework. Native code can link to them
directly.
13. Kernel
Based on the Linux kernel, with a few differences in
implementation of memory and power management.
CPU, IO, Crypto, Audio, Video etc are all same as
mainline Linux kernel.
A major difference absence of root rights to human
users, and read-only mode of /data partition
The directory structure is pretty different from usual
Linux distros, divided into /system, /data, and /cache
partitions.
15. Getting a build machine ready
64-bit Linux or Mac, with minimum 4GB RAM. More
the horsepower, faster the build.
Upwards of 40GB of free space. SSD recommended
over conventional HDD
Sun/Oracle Java 6 JDK for building Android 4.4.4 or
below. Android L can be built with OpenJDK 7
https://source.android.com/source/initializing.html
16. Downloading the source
About 9GB of source code for Android Kitkat.
Spread across 400+ separate git repositories.
Each app is maintained independently. The
framework is one large repository. All Apache
licensed.
Most library stacks are independently maintained.
Many derived from original GNU/Linux libraries, and
modified to suit needs of Android.
https://source.android.com/source/downloading.html
17. Building the Android OS
The linux kernel, over 150 libraries, 30+ apps, and
the android runtime and various framework packages
built and compressed into a ~250MB package.
A makefile driven process, with no role of any IDE.
Device and platform specific builds ( staying true to
it's embedded linux roots ) that are not cross-compatible
with other devices.
https://source.android.com/source/building-running.html
19. Modifying Android : Apps
Basic apps like Phone, Contacts, Mms, Launcher,
Browser, Settings, Camera are part of the base OS.
Functional additions, visual changes, or improved UX
in these apps are used as differentiating factor by
OEM-built Android flavours like TouchWiz, Sense,
MotoBlur or MIUI.
App developers with few months of experience can
start taking a crack at this.
20. Modifying Android : Framework
Improve UX by rethinking the core components like
notifications, lockscreen, navigation bar, recents.
Refresh the look and feel by redesigning the UI
components and theme/style elements.
Extend the ecosystem by adding your own APIs. Get
3rd party developers onto your ecosystem.
More experiences Android developers with deeper
understanding of underlying APIs can start off.
21. Modifying Android : HAL & Libraries
Lower level feature addition often accompanied
with development of superior hardware technologies.
Common examples include HDR mode photography,
audio equalisers and enhancements, high senstivity
touchscreens for glove mode.
Improving algorithms for accuracy and sensitivity for
sensors.
22. Modifying Android : Kernel
Interesting low-level implementations like ringing
Alarm in switched-off phone.
Add support for custom hardware like heart rate
sensor, IR blaster etc.
Improve performance, extend battery life writing
efficient CPU/GPU governors, schedulers.
Typical playground for (Embedded) Linux
enthusiasts.
23. A look at Open Source Community
maintained Custom Android
distributions :
AOKP
CyanogenMod
ParanoidAndroid
75. Cube26 : The company
Founded by three Indians who met while studying at
Cornell University. Now operates out of Santa Clara
and New Delhi.
Vision : Making smart devices smarter
Creating smart gesture based features for 6 leading
Indian smartphone manufacturers, inculding
Micromax, Intex.
More than 1 million devices shipped with features
developed by Cube26 integrated
77. Cube26 : The company
Currently working on integrating various natural
gesture recognition and contextual action based
features with Android.
A growth stage startup. Hiring talented professionals
in the fields of Android development and UI/UX
design.
Reach out to : hr@cube26.com
79. Source control in Android
Android is maintained across 400+ git repositories.
Besides the platform, the ADT, Android Studio, the
ARM GCC cross compiler are also part of the
Android Open Source Project.
Code submissions pass through a code review
server called gerrit. Gerrit is a git code review
software written by Google to manage projects like
Android and Chromium.
https://android-review.googlesource.com
80. Submitting patches to Google
Google tends to take only bugfixes from the
community. UX/UI features are developed in-house,
and code is dropped only during major releases.
(there are exceptions)
Patches must be verified by the automatic buildbot,
and approved by at least one member from the
Android team.
Moderate to advanced knowledge of git and gerrit is
essential to submit patches. (often involves rebasing
and manual conflict resolving).
84. Staying compatible with Android
Android can be modified to any extent wanted.
Beyond certain constraints, modifications may not
remain compatible.
Compatibility is defined by Google as per the CDD
(Compatibility Definition Document)
Compatibility Test Suite and CTS Verifier - set of
tests designed to test compatibility.
Non-compliance with CDD disqualifies the OS to be
called as Android.
85. Goals of compatibility
Providing uniform and stable environment to 3rd party
app developers.
Level playing field across the whole ecosystem.
Reduce fragmentation
Quality control of the Android brand.
Ease of use and familarity for users.
86. Why remain compatible ?
Encash the brand value of Android
Benefit from a rich ecosystem ( 1M+ apps, 50K+
developers )
Benefit from using Google's APIs and services.
Reduce cost of maintenance of code.
Build a unique identity while remainging part of a
larger family.