Enhancing and modifying_the_core_android_os
3 likes1,528 views
This document discusses modifying and enhancing the Android OS. It provides an overview of the Android framework, including applications, system UI, providers and APIs, Dalvik/Android runtime, libraries, and the kernel. It describes how to build Android for a phone by getting a build machine ready, downloading the source code, and building the OS. It outlines how to modify different parts of Android like apps, framework, hardware abstraction layer, libraries, and kernel. It also discusses open source custom Android distributions and contributing changes back to the Android Open Source Project.
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 • 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.
- 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. Contribute back to Google's Android Open Source Project (AOSP)
- 76. 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. 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
- 77. 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).
- 80. Compatibility : A tiny caveat
- 81. 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”.
- 82. 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.
- 83. 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.