Enhancing and Modifying the core Android OS

A presentation given at Mobile Developer Summit, Bangalore, 2014

Transcript

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. • 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
11. • 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
12. • 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
13. • 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
14. Building Android for your Phone
15. • 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
16. • 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
17. • 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
18. What can be modified ? And how ?
19. • 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
20. • 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
21. • 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
22. • 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
23. A look at Open Source Community maintained Custom Android distributions : AOKP CyanogenMod ParanoidAndroid
71. Cube26 feature preview
75. • 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
76. Cube26 : The company
77. • 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
78. Contribute back to Google's Android Open Source Project (AOSP)
79. • 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
80. • 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
83. Compatibility : A tiny caveat
84. • 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
85. • 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
86. • 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 ?
87. Arnav Gupta @championswimmer championswimmer.in