1. Modifying andEnhancing the CoreAndroid OSArnav GuptaStudent, DTUAndroid Framework Engineer, Cube26

2. A little about myself . . . 3. College Undergrad student, Electronics and ElectricalEngineering, Delhi Technological University. Expecting to graduate in 2016, (if I can survivecollege for another 2 years) 4. Work Cube26 Joined - March 14 Android Framework Engineer Working on projects of various clients likeMicromax, LAVA, Intex Developing and integrating smart gesturebased interaction methods into Android OS. Smart lockscreens, enhanced camera modesfor phones like Micromax Canvas A290, A310. 5. Work Open SourceCommunity Contributor and developer on communitymodded ROMs like CyanogenMod and AOKP Open source development partner with SonyMobile Making latest open source Android stack workon Sony Xperia phones. Developing various software-based featuresfor these modified versions of Android. 6. Understanding the Android OS 7. Applications Everything opened from anicon on the launcher is an app Almost every user-facinginterface in Android is an app Very generic in nature, andrarely interdependent. Bundled in the form of .apkfiles, like we can get from thePlay Store. 8. Framework : SystemUI Lockscreen, Status bar,Notification pane, Navigationbar Defines how Toasts, Dialogboxes look like Lays out the basic look andfeel of the UI. Packaged as .apk, but isdevice-dependent, and not100% generic. 9. 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 interactwith lower stacks of the OS. Media, graphics, audio etc implementation could besignificantly different across different hardware. Provide and regulate access to contents andservices present on the device. 10. Dalvik / Android Runtime An implementation much similar to the Java VirtualMachine. Dalvik older runtime. Now being superseded by anewer Android Runtime from Android L. Executes bytecode. Dalvik bytecode very muchsimilar to java bytecode. All applications, including the Framework, run on theDalvik VM. Each process is a fork of zygote. 11. Libraries Android contains a set of dynamically linkablelibraries (.so files, much like .dll of Windows) whichare required for various purposes. Libraries like libc contain core functions, used byalmost every process. There are OpenGLES libs forgraphics, security and cryptography related libs likelibcrypto, libssl. Almost all hardware relatedsubsystems are accessible by Hardware AbstractionLayer libs. Apps are provided the features of libraries via theAPIs of the framework. Native code can link to themdirectly. 12. Kernel Based on the Linux kernel, with a few differences inimplementation of memory and power management. CPU, IO, Crypto, Audio, Video etc are all same asmainline Linux kernel. A major difference absence of root rights to humanusers, and read-only mode of /data partition The directory structure is pretty different from usualLinux distros, divided into /system, /data, and /cachepartitions. 13. Building Android for your Phone 14. Getting a build machine ready 64-bit Linux or Mac, with minimum 4GB RAM. Morethe horsepower, faster the build. Upwards of 40GB of free space. SSD recommendedover conventional HDD Sun/Oracle Java 6 JDK for building Android 4.4.4 orbelow. Android L can be built with OpenJDK 7https://source.android.com/source/initializing.html 15. Downloading the source About 9GB of source code for Android Kitkat. Spread across 400+ separate git repositories. Each app is maintained independently. Theframework is one large repository. All Apachelicensed. Most library stacks are independently maintained.Many derived from original GNU/Linux libraries, andmodified to suit needs of Android.https://source.android.com/source/downloading.html 16. Building the Android OS The linux kernel, over 150 libraries, 30+ apps, andthe android runtime and various framework packagesbuilt and compressed into a ~250MB package. A makefile driven process, with no role of any IDE. Device and platform specific builds ( staying true toit's embedded linux roots ) that are not cross-compatiblewith other devices.https://source.android.com/source/building-running.html 17. What can be modified ? And how ? 18. 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 UXin these apps are used as differentiating factor byOEM-built Android flavours like TouchWiz, Sense,MotoBlur or MIUI. App developers with few months of experience canstart taking a crack at this. 19. Modifying Android : Framework Improve UX by rethinking the core components likenotifications, lockscreen, navigation bar, recents. Refresh the look and feel by redesigning the UIcomponents and theme/style elements. Extend the ecosystem by adding your own APIs. Get3rd party developers onto your ecosystem. More experiences Android developers with deeperunderstanding of underlying APIs can start off. 20. Modifying Android : HAL & Libraries Lower level feature addition often accompaniedwith development of superior hardware technologies. Common examples include HDR mode photography,audio equalisers and enhancements, high senstivitytouchscreens for glove mode. Improving algorithms for accuracy and sensitivity forsensors. 21. Modifying Android : Kernel Interesting low-level implementations like ringingAlarm in switched-off phone. Add support for custom hardware like heart ratesensor, IR blaster etc. Improve performance, extend battery life writingefficient CPU/GPU governors, schedulers. Typical playground for (Embedded) Linuxenthusiasts. 22. A look at Open Source Communitymaintained Custom Androiddistributions :AOKPCyanogenModParanoidAndroid 23. Cube26 feature preview 24. Contribute back to Google'sAndroid Open Source Project(AOSP) 25. Source control in Android Android is maintained across 400+ git repositories.Besides the platform, the ADT, Android Studio, theARM GCC cross compiler are also part of theAndroid Open Source Project.https://android.googlesource.com Code submissions pass through a code reviewserver called gerrit. Gerrit is a git code reviewsoftware written by Google to manage projects likeAndroid and Chromium.https://android-review.googlesource.com 26. Submitting patches to Google Google tends to take only bugfixes from thecommunity. 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 theAndroid team. Moderate to advanced knowledge of git and gerrit isessential to submit patches. (often involves rebasingand manual conflict resolving). 27. Compatibility : A tiny caveat 28. Staying compatible with Android Android can be modified to any extent wanted. Beyond certain constraints, modifications may notremain compatible. Compatibility is defined by Google as per the CDD(Compatibility Definition Document) Compatibility Test Suite and CTS Verifier - set oftests designed to test compatibility. Non-compliance with CDD disqualifies the OS to becalled as Android. 29. Goals of compatibility Providing uniform and stable environment to 3rd partyapp developers. Level playing field across the whole ecosystem. Reduce fragmentation Quality control of the Android brand. Ease of use and familarity for users. 30. 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 alarger family.