Modifying and Enhancing the Core Android OS

Arnav Gupta

Student, DTUAndroid Framework Engineer, Cube26

A little about myself . . .

College

•Undergrad student, Electronics and Electrical Engineering, Delhi Technological University.

• Expecting to graduate in 2016, (if I can survive college for another 2 years)

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.

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.

Understanding the Android OS

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.

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.

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

Framework : Providers & APIs

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

Dalvik / Android Runtime

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

Libraries

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

Kernel

Building Android for your Phone

• 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

Getting a build machine ready

• 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

Downloading the source

• 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

Building the Android OS

What can be modified ? And how ?

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

Modifying Android : Apps

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

Modifying Android : Framework

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

Modifying Android : HAL & Libraries

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

Modifying Android : Kernel

A look at Open Source Community maintained Custom Android

distributions : AOKP

CyanogenModParanoidAndroid

Cube26 feature preview

• 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

Cube26 : The company

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

Cube26 : The company

Contribute back to Google's Android Open Source Project

(AOSP)

• 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

Source control in Android

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

Submitting patches to Google

Compatibility : A tiny caveat

• 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”.

Staying compatible with Android

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

Goals of compatibility

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

Why remain compatible ?

Arnav Gupta

@championswimm

er

championswimmer.

in