A presentation given at Mobile Developer Summit, Bangalore, 2014

1. Modifying and
Enhancing the Core
Android OS
Arnav Gupta
Student, DTU
Android Framework Engineer, Cube26

2. A little about myself . . .

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.

6. Understanding the Android OS

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
• User’s 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.

14. Building Android for your Phone

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

18. What can be modified ? And how ?

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

71. Cube26 feature preview

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

76. Cube26 : The company

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

78. Contribute back to Google's
Android Open Source Project
(AOSP)

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).

83. Compatibility : A tiny caveat

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.

87. Arnav Gupta
@championswimm
er
championswimmer
.in