Android

Top level goals:

  • Open: Linux kernel + Java VM, Apache License (not GPL)
  • All apps are equal and replaceable
  • Middleware to support sharing data among applications (e.g. contacts)
  • Good development environment: Eclipse + Debugging + Emulator (plus vi, emacs, IntelliJ)

Open Handset Alliance

  • “30 technology companies” supporting Android
  • Marvel, ARM, Qualcomm, TI, Wind River, ST Micro, NEC, ???
  • Mostly hardware companies
  • Carriers: Sprint/Nextel and Verizon expressed support

Features

  • Application framework enabling reuse and replacement of components
  • Dalvik virtual machine optimized for mobile devices
    • Not actually a JVM: Java source code converted Jave bytecode and then to Dalvik bytecodes
    • Claim: better power, “register based” and optimized for CPU
    • Each app runs in its own Dalvik VM (but shares code)
    • Each app also runs its own Linux process (to reclaim resources)
  • Integrated browser based on the open source WebKit engine
  • Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL ES 1.0 specification (hardware acceleration optional)
  • SQLite for structured data storage
  • Media support for common audio, video, and still image formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)
  • GSM Telephony (hardware dependent)
  • Bluetooth, EDGE, 3G, and WiFi (hardware dependent)
  • Camera, GPS, compass, and accelerometer (hardware dependent)
  • Rich development environment including a device emulator, tools for debugging, memory and performance profiling, and a plugin for the Eclipse IDE

code.google.com_android_images_system-architecture.jpg

Video overview of the architecture

Application Framework

Developers have full access to the same framework APIs used by the core applications. The application architecture is designed to simplify the reuse of components; any application can publish its capabilities and any other application may then make use of those capabilities (subject to security constraints enforced by the framework). This same mechanism allows components to be replaced by the user.

Underlying all applications is a set of services and systems, including:

  • A rich and extensible set of Views that can be used to build an application, including lists, grids, text boxes, buttons, and even an embeddable web browser
    • Includes Google map view and iPhone like image browswer
  • Content Providers that enable applications to access data from other applications (such as Contacts), or to share their own data
    • Each CP is like one SQL table, with a simple query language, fixed types for the columns, and a cursor
    • Handles persistence and sharing
    • There is no other way to share data among applications (files?)
  • A Resource Manager, providing access to non-code resources such as localized strings, graphics, and layout files
    • Typically an XML file with strings, or a collection of images
    • Bound at load time based on environment settings (e.g. screen size, locale)
  • A Notification Manager that enables all applications to display custom alerts in the status bar
  • An Activity Manager that manages the life cycle of applications and provides a common navigation backstack
    • Each activity is one screen
  • A service is a background task, such as playing music

Components

  • Key idea: build components not apps
  • Use components as late-bound subroutines
  • Example: “Pick a photo” component should be used by any app that wants to the user to pick a photo or image
  • Query issued to find the component at runtime; matching component then executes
  • Implies anyone can upgrade the photo picker for all apps
  • Components are implemented as “sub activities” and can return results

Application Lifecycle

  • Two goals: “back” button through different activities, use explicit continuations to minimize resources
  • Four main states: foreground, paused (visible but not foreground), stopped (not visible but has state), icicle
  • The icicle state has no process, but its continuation (the icicle) has been saved and it may be recreated

  • onCreate takes a continuation as its argument, in case this activity was killed earlier
  • onFreeze makes the continuation in case it is needed
  • onPause syncs persistent state (commit changes to Content Providers)
 
android.txt · Last modified: 2008/03/03 23:06 by brewer
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki