Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Enhancing and Modifying the core Android OS

Arnav Gupta
October 09, 2014

Enhancing and Modifying the core Android OS

A presentation given at Mobile Developer Summit, Bangalore, 2014

Arnav Gupta

October 09, 2014

More Decks by Arnav Gupta

Other Decks in Technology


  1. College • Undergrad student, Electronics and Electrical Engineering, Delhi Technological

    University. • Expecting to graduate in 2016, (if I can survive college for another 2 years)
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. • 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
  7. • 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
  8. • 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
  9. • 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
  10. • 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
  11. • 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
  12. • 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
  13. • 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
  14. • 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
  15. • 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
  16. • 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
  17. • 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
  18. • 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
  19. • 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
  20. • 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
  21. • 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
  22. • 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
  23. • 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 ?