際際滷

際際滷Share a Scribd company logo
Modifying and 
Enhancing the Core 
Android OS 
Arnav Gupta 
Student, DTU 
Android 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
Enhancing and modifying_the_core_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.
Framework : Providers & APIs 
 Users 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.
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.
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.
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.
Building Android for your Phone
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
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
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
What can be modified ? And how ?
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.
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.
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.
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.
A look at Open Source Community 
maintained Custom Android 
distributions : 
AOKP 
CyanogenMod 
ParanoidAndroid
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Cube26 feature preview
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
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
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
Contribute back to Google's 
Android Open Source Project 
(AOSP)
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
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).
Enhancing and modifying_the_core_android_os
Enhancing and modifying_the_core_android_os
Compatibility : A tiny caveat
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.
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.
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.
Arnav Gupta 
@championswimm 
er 
championswimmer 
.in

More Related Content

Enhancing and modifying_the_core_android_os

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