Click here to load reader

Android Architecture

  • View
    5

  • Download
    1

Embed Size (px)

Text of Android Architecture

CARNEGIE MELLON UNIVERSITY, PITTSBURGH

Android architectureCopyright Karan Khanna 7/28/2010

We try to explore the architectural drivers that shaped Android, its architecture at a high level, and then try to relate each architectural driver with various tactics that satisfy it.

CONTENTS1. 2. Introduction .............................................................................................................................................................................................................................................. 3 Architectural drivers ............................................................................................................................................................................................................................. 4 Functional goals ........................................................................................................................................................................................................................................... 4 Quality attributes: ....................................................................................................................................................................................................................................... 5 Constraints: .................................................................................................................................................................................................................................................... 7 3. 4. 5. 6. 7. 8. Android mobile stack architecture [Dynamic view, 1st level decomposition]: ............................................................................................................. 9 Android mobile stack architecture [Dynamic view, 2nd level decomposition, Linux process and Android application]: ........................ 15 Android mobile stack architecture [Dynamic view, 3rd level decomposition, Android component: Activity]: ............................................ 22 Android mobile stack architecture [Dynamic view, 2nd level decomposition, application framework components]:.............................. 23 Android mobile stack architecture [Dynamic view, 2nd level decomposition, application framework start-up sequence]: .................. 30 Strategies and tactics to accomplish various architectural drivers:................................................................................................................................ 31 Security:........................................................................................................................................................................................................................................................ 31 Time Performance: .................................................................................................................................................................................................................................. 32 Extensibility: ............................................................................................................................................................................................................................................... 34 Be open source but keep GPL out of user space:.......................................................................................................................................................................... 35 Long battery life: ....................................................................................................................................................................................................................................... 35 Fitting short memory (RAM): .............................................................................................................................................................................................................. 36 9. References .............................................................................................................................................................................................................................................. 37

Copyright Karan Khanna, Carnegie Mellon University, 2010

Page 2

1.

INTRODUCTION

Recent years have seen rapid evolution of mobile phones as computation platforms [beyond the basic voice telephony], which could soon rival traditional desktop computing in many respects Internet seems incipient. This has shifted focus of major players in the area of general purpose desktop computing Microsoft, Apple, and so on towards mobile computing, and we have seen some very fine offerings like the iPhones, Andriod phones and Windows-mobile phones. From my recent but brief introduction to Android and iPhone OS, I like to believe that in creating mobile software platforms, existing expertise and knowledge in the area of desktop computing has been re-applied and desktop software systems have been re-factored. It therefore becomes intriguing to explore what drives the architecture of a modern world mobile software platform, and how these forces reshape the architecture of traditional desktop software platform to that of mobile software platform. There were several motivating factors to take this Independent study. Android is young, exciting product, and I wanted to learn more about it. I also wanted to augment my architectural thinking on the lines advocated in the Architectures for software systems course at Carnegie Mellon University. Also, there is not a comprehensive documentation yet available publicly, as far as the architecture and design of Android is concerned. There is a set of videos from Google which give a high level insight, and then there is an API reference plus the sample applications. While it may not be easy to search specific information from within videos, API reference is sometimes hard to comprehend. I hope to add more information, and make corrections to this initial draft, as my understanding of the architecture grows.

Copyright Karan Khanna, Carnegie Mellon University, 2010

Page 3

2.

ARCHITECTURAL DRIVERS

FUNCTIONAL GOALSAndroid has been designed to meet amongst others, following larger functional goals: Ability to provide the basic Telephony service of making and receiving calls, along with a possibility of being configurable for non-telephony usage, quite like the iPods and so forth. To serve as a robust network stack and Internet client To provide a comprehensive coding environment for mobile devices, giving application programmers freedom to take advantage by developing using: o Native code o Managed code o Web-browser based applications (so that applications can run on multiple phones)Google I/O 2009 How do I code Thee? Let me count the ways http://developer.android.com/videos/index.html#v=GARMe7Km_gk

[R1]

Copyright Karan Khanna, Carnegie Mellon University, 2010

Page 4

QUALITY ATTRIBUTES:

Security

As in case of Desktops, and other mobile platforms, security against malicious code that may cause bad user experience by bringing down the system is important. Additionally, in case of mobile, also important is to guard against any malicious code that may cause bad user experience by consuming unreasonable amount of battery, by making uncontrolled calls, and accessing private user data like contacts.

Time performance [R2]

The platform should provide a pleasing user experience by having short application launch and switching times. Switching context becomes even more important in case of mobile because of the limited display/screen real-estate, where a single user-interaction almost always takes-up the entire screen. Consequently, moving from one step to another within a single user task might mean rendering complete screen several times in a short period of time. More specifically, Android sets guidelines such as: Browser should launch in < 1300 ms MMS/SMS should launch in < 700 ms Alarm clock should launch in < 650 ms When more than one application has been launched, re-launching an already-running application must take les that the original launch time

Complete system software upgrade [R2]

It should be possible to upgrade entire system software (Restart OK), without wiping out user data. Any of the following is allowed: Over the air downloads with offline update via reboot Tethered updates via USB from a host PC Offline updates via reboot and update from a file on a removable storagePage 5

Copyright Karan Khanna, Carnegie Mellon University, 2010

Extensibility

One of the fundamental requirements of Android application framework is the re-use and replacement of components. If your application likes to integrate the Google Maps feature, it should be able to do so. On the other hand, if you like to make a device version with custom home application, it should be possible to do so. Backward compatibility of the framework, as the platform stack is revised over time. It should be easy for the OEMs to port the stack to their hardware

Battery[R3]

The goal is to maximize the time before the phone battery must be recharged before it can be used again. A minimum target cannot be specified here since how long the battery lasts largely depends upon how the device gets used. However, there are some statistics which can give a qualitative idea of the same: HTC Dream has: 1150 mAh battery Macbook PRO has: 5600 mAh battery A 500 MHz CPU used at 100% clock-rate consumes around 100 mA Using 3G at full rate consumes 150 mAh Using WiFi at full rate consumes 275 mAh Watching Youtube consumes 240 mAh Typical usage: The phone on an average is used for 10 min/Hour, and the remaining time

Search related