Enhancing and Modifying the core Android OS

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

A little about myself . . .

Slide 3

Slide 3 text

College • Undergrad student, Electronics and Electrical Engineering, Delhi Technological University. • Expecting to graduate in 2016, (if I can survive college for another 2 years)

Slide 4

Slide 4 text

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.

Slide 5

Slide 5 text

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.

Slide 6

Slide 6 text

Understanding the Android OS

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

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.

Slide 9

Slide 9 text

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.

Slide 10

Slide 10 text

• 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

Slide 11

Slide 11 text

• 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

Slide 12

Slide 12 text

• 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

Slide 13

Slide 13 text

• 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

Slide 14

Slide 14 text

Building Android for your Phone

Slide 15

Slide 15 text

• 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

Slide 16

Slide 16 text

• 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

Slide 17

Slide 17 text

• 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

Slide 18

Slide 18 text

What can be modified ? And how ?

Slide 19

Slide 19 text

• 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

Slide 20

Slide 20 text

• 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

Slide 21

Slide 21 text

• 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

Slide 22

Slide 22 text

• 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

Slide 23

Slide 23 text

A look at Open Source Community maintained Custom Android distributions : AOKP CyanogenMod ParanoidAndroid

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

No content

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

No content

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

No content

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

Cube26 feature preview

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

No content

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

• 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

Slide 76

Slide 76 text

Cube26 : The company

Slide 77

Slide 77 text

• 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 : [email protected] Cube26 : The company

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

• 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. https://android.googlesource.com • 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

Slide 80

Slide 80 text

• 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

Slide 81

Slide 81 text

No content

Slide 82

Slide 82 text

No content

Slide 83

Slide 83 text

Compatibility : A tiny caveat

Slide 84

Slide 84 text

• 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

Slide 85

Slide 85 text

• 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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

Arnav Gupta @championswimmer championswimmer.in