How Android is different from other systems – An exploration of the design decisions in Android


Published on

“Google’s Android is a brand new platform for mobile phones, and has been created from scratch specifically for this purpose. This means that it is a ‘modern’ system that does not suffer from any legacy issues, and has taken the best ideas from various other projects to build a system that is arguably better than any of the other, competing, systems. Thus, for example, it uses the Java language as the development language, but has rejected the rest of the Java ecosystem. Specifically it uses a completely new virtual machine (Dalvik) which is redesigned with mobiles in mind – and has a number of very interesting design decisions that we will discuss. Similarly, the Android application framework represents a departure from the traditional way of doing things, and has a learning curve, but once you get used to it, it is great, especially for allowing different apps to share data, code, and in general co-operate. We will explore and discuss this and various other design decisions in Android. This talk can serve as your introduction to “”What is Android”", and more importantly, “”Why is Android”"

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

How Android is different from other systems – An exploration of the design decisions in Android

  1. 1. Why is Android the way it is ... Navin Kabra
  2. 2.  Navin Kabra  Background: ▸ Computer Science ▸ B.Tech, IIT-Bombay ▸ Ph.D, Univ of Wisconsin-Madison, USA  Currently ▸ CTO, ▸ Also founder of PuneTech  Links: ▸ ▸ ▸  Twitter: @_navin, @punetech  Email:
  3. 3.  Operating system − Initially targeting mobile phones − Now on more and more devices  By: Open Handset Alliance − Primarily Google − Also: HTC, Motorola, Intel, T-mobile, TI, Samsung − And: 47 others…  Stack − Linux Kernel − Java programming language − OpenGL graphics − Android’s own app development framework Photo Credit:Android Home by Unnamed 102 (via wikipedia)
  4. 4.  Kernel − Drivers: display, camera, bluetooth, flash memory, binder(IPC), usb, keypad, wifi, audio, power mgmt  Libraries − Surface, media, sqlite, opengl|es, freetype(fonts), webkit(browser), libc, ssl, sgl  Java − Dalvik Virtual Machine, Core java libraries  Application Framework − Window manager, Activities, Content Providers, View System, Notification Mgr, Package manager, Telephony manager, Resources, Location, Gtalk  Applications − Home, Contacts, Phone, Browser
  5. 5.  Re-design for mobile − i.e. CPU and memory constrained systems  Re-design for open-ness − Everything is open source − Open-ness friendly license  Re-design for reuse − Framework encourages mashups/interoperability
  6. 6.  Brand new Virtual Machine: Dalvik VM  Optimized for low-memory requirements  No JARs – use DEX files − Regular DEX file smaller than compressed JAR  No JIT yet − but (so?) lots of native code  Allow multiple VMs − one per app − better security  Better use of OS kernel features − Process isolation, memory mgmt, threading
  7. 7.  Use Apache license  GPL scares off device manufacturers − Android kernel = linux kernel = LGPL − Not as scary  Java wants centralized control (JCP) − Another reason why no JVM − And Java standard libraries missing  Everything is replaceable/rewriteable − Including contacts, sms, telephony…
  8. 8.  App development framework encourages mashups  Activities  Intents  Content Providers
  9. 9.  Apps broken up into activites  Each activity independently invokable  Example - email activites: − Show one email − Show email list − Create an email − Pick an email recipient  Share these across different apps
  10. 10.  Inter-app communication via “intents”  Specify what you want − Don’t specify how or who  System picks who does it − Other apps register with system − Indicate which intents they’re interested in handling  Loose coupling allows ease of replacement − Intents = XML format
  11. 11.  Abstract, high-level API for storing/retreiving data  Level of indirection between app & data storage  Content provider chooses data storage mechanism − File-system, database, cloud (internet) − (By the way, SQLite is in-built)
  12. 12.  Java programming language used  But not the Java Runtime − No JVM − No standard Java libraries − No JCP (Java community process) − No Java license − No JARs (i.e. no byte-code compatibility)
  13. 13.  Linux Kernel  No native windowing support − i.e. no Xwindows/Xfree86/Xorg/GNOME/KDE  No standard C library − i.e. no glibc − “Bionic” – customized, partial libc implementation − Only 200k (half of glibc) − Designed for low CPU devices − Customized High performance pthread library  No standard linux utilities − Some are there, most are missing
  14. 14.  In addition to Java: − C, C++, Python, Lua, Scala  Supports GSM (not CDMA?)  Touch, but not multi-touch (yet)
  15. 15.  Targeted Machine  CPU: 250-500MHz  Bus: 100MHz  Data-cache: 16-32K  Memory: 64MB − Low-level startup takes up 24MB − High-level startup takes up another 20MB − System library takes up another 10MB − Only 10MB available for apps
  16. 16.  Resources Alternatives by: − MCC=mobile country code − Language and region − screen orientation: port, land, square − screen pixel density: 92dpi, 108dpi, − touchscreen type: notouch, stylus, finger − keyboard: keysexposed, keyshidden, keyssoft − primary input type: nokeys, qwerty, 12keys − primary navigation method: nonav, dpad, trackball, wheel − screen dimensions: 320x240, 640x480 − sdk version: v1 (1.0), v2 (1.1), v3(1.5)