Android

Document Sample
Android Powered By Docstoc
					ANDROID
INTRODUCTION
   What is Android?
       Android is a software stack for mobile devices that includes
        an operating system, middleware and key applications.
       It is based on the Linux operating system and developed by
        Google and the Open Handset Alliance.
       It allows developers to write applications in Java using
        Google-developed Android SDK.
       It uses the Dalvik virtual machine with just-in-time
        compilation to run Dalvik bytecode.
       There are currently approximately 300,000 apps available
        for Android, from a total of 500,000 apps over the life of
        Android.
       Apps can be downloaded from third-party sites or through
        online stores such as Android Market, the app store run by
        Google.
HISTORY
   Foundation
     Android, Inc. was founded in Palo Alto, California,
      United States in October, 2003 by Andy Rubin (co-
      founder of Danger), Rich Miner (co-founder of
      Wildfire Communications, Inc.), Nick Sears (once VP
      at T-Mobile), and Chris White (headed design and
      interface development at WebTV).
     Despite the obvious past accomplishments of the
      founders and early employees, Android Inc. operated
      secretly, revealing only that it was working on
      software for mobile phones.
HISTORY
   Acquisition by Google
     Google acquired Android Inc. in August 2005, making
      Android Inc. a wholly owned subsidiary of Google Inc.
     Key employees of Android Inc., including Andy
      Rubin, Rich Miner and Chris White, stayed at the
      company after the acquisition.
     Not much was known about Android Inc. at the time
      of the acquisition, but many assumed that Google
      was planning to enter the mobile phone market with
      this move.
HISTORY
   Post-acquisition development
     At Google, the team led by Rubin developed a mobile
      device platform powered by the Linux kernel.
     Google marketed the platform to handset makers and
      carriers on the premise of providing a flexible,
      upgradable system.
     Google had lined up a series of hardware component
      and software partners and signaled to carriers that it
      was open to various degrees of cooperation on their
      part.
HISTORY
   Open Handset Alliance
     On November 5, 2007, the Open Handset Alliance, a
      consortium of several companies which include Broadcom
      Corporation, Google, HTC, Intel, LG, Marvell Technology
      Group, Motorola, Nvidia, Qualcomm, Samsung Electronics,
      Sprint Nextel, T-Mobile and Texas Instruments unveiled
      itself.
     The goal of the Open Handset Alliance is to develop open
      standards for mobile devices. On the same day, the Open
      Handset Alliance also unveiled their first product, Android,
      a mobile device platform built on the Linux kernel version
      2.6.
     On December 9, 2008, 14 new members joined, including
      ARM Holdings, Atheros Communications, Asustek
      Computer Inc, Garmin Ltd, Huawei Technologies,
      PacketVideo, Softbank, Sony Ericsson, Toshiba Corp, and
      Vodafone Group Plc.
HISTORY
   Licensing
       With the exception of brief update periods, Android has
        been available under free and open source software
        licenses from October 21, 2008.
       Google published the source code for their Linux kernel
        changes under the GNU General Public License version 2,
        and the rest of the code under the Apache License version
        2.0.
       Google also keeps the reviewed issues list publicly open for
        anyone to see and comment.
       Even though the software is open source, device
        manufacturers cannot use Google's Android trademark
        unless Google certifies that the device complies with their
        Compatibility Definition Document (CDD).
       Devices must also meet this definition to be eligible to
        license Google's closed-source applications, including the
        Android Market.
HISTORY
   Version history
     Android has seen a number of updates since its
      original release, each fixing bugs and adding new
      features. Each version is named, in alphabetical
      order, after a dessert.
     Recent releases
         2.3 Gingerbread is the latest Android version that is
          available to phones.
         3.0 Honeycomb was a tablet-orientated release.

         4.0 Ice Cream Sandwich, announced on October 19, 2011,
          brought Honeycomb features to smart phones and added
          new features including facial recognition unlock, network
          data usage monitoring and control, unified social
          networking contacts, photography enhancements, offline
          email searching, and information sharing using NFC.
FEATURES
   Application Framework
       It is used to write applications for Android.
       Unlike other embedded mobile environments,
        Android applications are all equal, for instance,
        an applications which come with the phone are no
        different than those that any developer writes.
       The framework is supported by numerous open
        source libraries such as openssl, SQLite, etc.
       It is also supported by the Android core libraries.
       From the point of security, the framework is
        based on UNIX file system permissions that assure
        applications have only those abilities that mobile
        phone owner gave them at install time.
FEATURES
   Dalvik Virtual Machine
     The Dalvik virtual machine is a register-based virtual
      machine, designed and written by Dan Bornstein with
      contributions from other Google engineers as part of the
      Android mobile phone platform.
     It is optimized for low memory requirements, and is
      designed to allow multiple VM instances to run at once,
      relying on the underlying operating system for process
      isolation, memory management and threading support.
     Dalvik is often referred to as a Java Virtual Machine, but
      this is not strictly accurate, as the bytecode on which it
      operates is not Java bytecode.
     Instead, a tool named dx, included in the Android SDK,
      transforms the Java Class files of Java classes compiled by
      a regular Java compiler into another class file format (the
      .dex format).
FEATURES
   Integrated Browser
       The web browser available in Android is based on the
        open-source WebKit layout engine.
       They added a two pass layout and frame flattening.
       Two pass layout loads a page without waiting for
        blocking elements, such as external CSS or
        external JavaScript and after a while renders again
        with all resources downloaded to the device.
       Frame flattening converts founded frames into
        single one and loads into the browser.
       These features increase speed and usability
        browsing the internet via mobile phone.
FEATURES
   Optimized Graphics
       As Android supports 2D graphics and 3D graphics,
        possibly we will see great applications like
        Google Earth and spectacular games like Second
        Life, which come on Linux version.

       At this moment, the shooting legendary 3D game
        Doom was presented using Android on the mobile
        phone.
FEATURES
   Data Storage
       SQLite is used for structured data storage.
       SQLite is a powerful and lightweight relational
        database engine available to all applications
       It is integrated in Android.
       It is based on function calls and single file, where all
        definitions, tables and data are stored.
       This simple design is more than suitable for a
        platform such as Android.
FEATURES
   Handset Layouts
     The platform is adaptable to both larger, VGA, 2D
      graphics library, 3D graphics library based on
      OpenGL ES 1.0 specifications, traditional smart
      phone layouts.
     Surface Manager manages access to the display
      subsystem and seamlessly composites 2D and 3D
      graphic layers from multiple applications.


   Connectivity
       Android supports a wide variety of connectivity
        technologies including GSM, CDMA, Bluetooth,
        EDGE, EVDO, 3G, 4G and Wi-Fi.
FEATURES
   Development Environment
       Includes a device emulator, tools for debugging,
        memory and performance profiling, a plugin for the
        Eclipse IDE. A great work was done for the
        developers to start work with Android using
        device emulator.

       There are a number of hardware dependent
        features, for instance, a huge media and
        connections support, GPS, improved support for
        Camera and simply GSM telephony.
FEATURES
   Media Support
       Android will support common audio, video, and still
        media formats such as MPEG-4, H.264, MP3, and
        AAC, AMR, JPEG, PNG, GIF.


   Streaming Media Support
     RTP/RTSP streaming (3GPP PSS, ISMA), HTML
      progressive download (HTML5 <video> tag).
     Adobe Flash Streaming (RTMP) and HTTP Dynamic
      Streaming are supported by the Flash plug-in.
     Apple HTTP Live Streaming is supported by
      RealPlayer for Mobile, and by the operating system
      in Android 3.0 (Honeycomb).
FEATURES
   Multi-touch
     Android has native support for multi-touch which was
      initially made available in handsets such as the HTC Hero.
     The feature was originally disabled at the kernel level
      Google has since released an update for the Nexus One and
      the Motorola Droid which enables multi-touch natively.

   Bluetooth
     Supports A2DP, AVRCP, sending files (OPP), accessing the
      phone book (PBAP), voice dialing and sending contacts
      between phones.
     Keyboard, mouse and joystick (HID) support is available in
      Android 3.1+, and in earlier versions through
      manufacturer customizations and third-party applications.

   Multitasking
       Multitasking of applications is available.
FEATURES
   Messaging
       SMS, MMS, and XMPP are available forms of
        messaging including threaded text messaging.


   Additional Hardware Support
       Android can use video/still cameras, touch screens,
        GPS, accelerometers, gyroscopes, barometers,
        magnetometers, dedicated gaming controls, proximity
        and pressure sensors, thermometers, etc.
ANDROID ARCHITECTURE
   The diagram in the next slide shows the major
    components of the Android operating system.
    Each section is described in more detail below.
APPLICATIONS
 At the top of Android Architecture we have all
  the applications, which are used by the final user.
 By installing different applications, the user can
  turn his mobile phone into the unique, optimized
  and smart mobile phone.
 Android ships with a set of core applications
  including an email client, SMS program,
  calendar, maps, browser, contacts, and others.
 All applications are written using the Java
  programming language.
APPLICATION FRAMEWORK
   By providing an open development platform, Android offers
    developers the ability to build extremely rich and
    innovative applications.

   Developers are free to take advantage of the device
    hardware, access location information, run background
    services, set alarms, add notifications to the status bar, and
    much, much more.

   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).
APPLICATION FRAMEWORK
   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.
       Content Providers that enable applications to access data
        from other applications (such as Contacts), or to share their
        own data.
       A Resource Manager, providing access to non-code
        resources such as localized strings, graphics, and layout
        files.
       A Notification Manager that enables all applications to
        display custom alerts in the status bar.
       An Activity Manager that manages the lifecycle of
        applications and provides a common navigation back stack.
LIBRARIES
   System C library
       a BSD-derived implementation of the standard C system
        library (libc), tuned for embedded Linux-based devices.

   Media Libraries
       based on PacketVideo's OpenCORE; the libraries support
        playback and recording of many popular audio and video
        formats, as well as static image files, including MPEG4,
        H.264, MP3, AAC, AMR, JPG, and PNG.

   Surface Manager
       manages access to the display subsystem and seamlessly
        composites 2D and 3D graphic layers from multiple
        applications.

   LibWebCore
       a modern web browser engine which powers both the Android
        browser and an embeddable web view.
LIBRARIES
   SGL
       the underlying 2D graphics engine.

   3D libraries
       an implementation based on OpenGL ES 1.0 APIs; the
        libraries use either hardware 3D acceleration (where
        available) or the included, highly optimized 3D software
        rasterizer.

   Free Type
       bitmap and vector font rendering.

   SQLite
       a powerful and lightweight relational database engine
        available to all applications.
ANDROID RUNTIME
 Android includes a set of core libraries that
  provides most of the functionality available in the
  core libraries of the Java programming language.
 Every Android application runs in its own
  process, with its own instance of the Dalvik
  virtual machine.
 Dalvik has been written so that a device can run
  multiple VMs efficiently.
 The Dalvik VM executes files in the Dalvik
  Executable (.dex) format which is optimized for
  minimal memory footprint.
ANDROID RUNTIME
   The VM runs classes compiled by a Java
    language compiler that have been transformed
    into the .dex format by the included "dx" tool.

   The Dalvik VM relies on the Linux kernel for
    underlying functionality such as threading and
    low-level memory management.
LINUX KERNEL
   Android relies on Linux version 2.6 for core
    system services such as security, memory
    management, process management, network
    stack, and driver model.

   The kernel also acts as an abstraction layer
    between the hardware and the rest of the
    software stack.
APPLICATION FUNDAMENTALS
   Android applications are written in the Java
    programming language.

   The Android SDK tools compile the code—along
    with any data and resource files—into an
    Android package, an archive file with an .apk
    suffix.

   All the code in a single .apk file is considered to
    be one application and is the file that Android-
    powered devices use to install the application.
APPLICATION FUNDAMENTALS
   Once installed on a device, each Android application
    lives in its own security sandbox:
     The Android operating system is a multi-user Linux
      system in which each application is a different user.
     By default, the system assigns each application a unique
      Linux user ID (the ID is used only by the system and is
      unknown to the application). The system sets permissions
      for all the files in an application so that only the user ID
      assigned to that application can access them.
     Each process has its own virtual machine (VM), so an
      application's code runs in isolation from other applications.
     By default, every application runs in its own Linux process.
      Android starts the process when any of the application's
      components need to be executed, then shuts down the
      process when it's no longer needed or when the system
      must recover memory for other applications.
APPLICATION FUNDAMENTALS
   In this way, the Android system implements the
    principle of least privilege.

   That is, each application, by default, has access
    only to the components that it requires to do its
    work and no more.

   This creates a very secure environment in which
    an application cannot access parts of the system
    for which it is not given permission.
APPLICATION FUNDAMENTALS
   However, there are ways for an application to
    share data with other applications and for an
    application to access system services:
     It's possible to arrange for two applications to share
      the same Linux user ID, in which case they are able
      to access each other's files. To conserve system
      resources, applications with the same user ID can
      also arrange to run in the same Linux process and
      share the same VM (the applications must also be
      signed with the same certificate).
     An application can request permission to access
      device data such as the user's contacts, SMS
      messages, the mountable storage (SD card), camera,
      Bluetooth, and more. All application permissions
      must be granted by the user at install time.
APPLICATION FUNDAMENTALS
   That covers the basics regarding how an Android
    application exists within the system. The rest of
    this document introduces to:
     The core framework components that define our
      application.
     The manifest file in which we declare components
      and required device features for our application.
     Resources that are separate from the application code
      and allow our application to gracefully optimize its
      behavior for a variety of device configurations.
APPLICATION COMPONENTS
   Application components are the essential
    building blocks of an Android application.

   Each component is a different point through
    which the system can enter your application.

   Not all components are actual entry points for
    the user and some depend on each other, but
    each one exists as its own entity and plays a
    specific role—each one is a unique building block
    that helps define your application's overall
    behavior.
APPLICATION COMPONENTS
   There are four different types of application
    components.

   Each type serves a distinct purpose and has a
    distinct lifecycle that defines how the component
    is created and destroyed.

   Here are the four types of application
    components:
     Activities
     Services
     Content Providers
     Broadcast Receivers
APPLICATION COMPONENTS
   Activities
     An activity represents a single screen with a user
      interface. For example, an email application might
      have one activity that shows a list of new emails,
      another activity to compose an email, and another
      activity for reading emails.
     Although the activities work together to form a
      cohesive user experience in the email application,
      each one is independent of the others.
     As such, a different application can start any one of
      these activities (if the email application allows it).
      For example, a camera application can start the
      activity in the email application that composes new
      mail, in order for the user to share a picture.
APPLICATION COMPONENTS
   Services
     A service is a component that runs in the background
      to perform long-running operations or to perform
      work for remote processes.
     A service does not provide a user interface. For
      example, a service might play music in the
      background while the user is in a different
      application, or it might fetch data over the network
      without blocking user interaction with an activity.
     Another component, such as an activity, can start the
      service and let it run or bind to it in order to interact
      with it.
APPLICATION COMPONENTS
   Content Providers
     A content provider manages a shared set of application
      data. You can store the data in the file system, an SQLite
      database, on the web, or any other persistent storage
      location your application can access.
     Through the content provider, other applications can query
      or even modify the data (if the content provider allows it).
      For example, the Android system provides a content
      provider that manages the user's contact information.
     As such, any application with the proper permissions can
      query part of the content provider to read and write
      information about a particular person.
     Content providers are also useful for reading and writing
      data that is private to your application and not shared.
APPLICATION COMPONENTS
   Broadcast Receivers
       A broadcast receiver is a component that responds to
        system-wide broadcast announcements.
       Many broadcasts originate from the system—for example,
        a broadcast announcing that the screen has turned off, the
        battery is low, or a picture was captured.
       Applications can also initiate broadcasts—for example, to
        let other applications know that some data has been
        downloaded to the device and is available for them to use.
       Although broadcast receivers don't display a user interface,
        they may create a status bar notification to alert the user
        when a broadcast event occurs.
       More commonly, though, a broadcast receiver is just a
        "gateway" to other components and is intended to do a very
        minimal amount of work. For instance, it might initiate a
        service to perform some work based on the event.
APPLICATION COMPONENTS
 A unique aspect of the Android system design is that
 any application can start another application’s
 component. For example, if we want the user to
 capture a photo with the device camera, there's
 probably another application that does that and our
 application can use it, instead of developing an
 activity to capture a photo ourselves. We don't need to
 incorporate or even link to the code from the camera
 application. Instead, we can simply start the activity
 in the camera application that captures a photo.
 When complete, the photo is even returned to our
 application so we can use it. To the user, it seems as if
 the camera is actually a part of our application.
APPLICATION COMPONENTS
 When the system starts a component, it starts
 the process for that application (if it's not already
 running) and instantiates the classes needed for
 the component. For example, if our application
 starts the activity in the camera application that
 captures a photo, that activity runs in the process
 that belongs to the camera application, not in our
 application's process. Therefore, unlike
 applications on most other systems, Android
 applications don't have a single entry point
 (there's no main() function, for example).
APPLICATION COMPONENTS
 Because the system runs each application in a
 separate process with file permissions that
 restrict access to other applications, our
 application cannot directly activate a component
 from another application. The Android system,
 however, can. So, to activate a component in
 another application, you must deliver a message
 to the system that specifies your intent to start a
 particular component. The system then activates
 the component for you.
ANDROIDMANIFEST.XML
   The AndroidManifest.xml file is the control file that tells the
    system what to do with all the top-level components
    (specifically activities, services, intent receivers, and content
    providers described below) you've created. For instance, this is
    the "glue" that actually specifies which Intents your Activities
    receive.

   A developer should predefine and list all components, which
    he wants to use in the specific AndroidManifest.xml file.

   It is a required file for all the applications and is located in
    the root folder.

   It is possible to specify all global values for the package, all
    the components and its classes used, intent filters, which
    describe where and when the certain activity should start,
    permissions and instrumentation like security control and
    testing.
ANDROIDMANIFEST.XML
Here is an example of AndroidManifest.xml file:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
   package="dk.mdev.android.hello">
<application android:icon="@drawable/icon">
<activity class=".HelloAndroid" android:label="@string/app_name">
<intent-filter>
<action android:value="android.intent.action.MAIN" />
<category android:value="android.intent.category.LAUNCHER"/>
</intent-filter>
</activity>
</application>
</manifest>
ANDROIDMANIFEST.XML
 The line 2 is a namespace declaration, which
 makes a standard Android attributes available
 for that application. In the line 4 there is a single
 <application> element, where the developer
 specifies all application level components and
 its properties used by the package. Activity
 class in the line 5 represents the initial screen
 the user sees and it may have one or more
 <intent-filter> elements to describe the actions
 that activity supports.
APPLICATION LIFECYCLE
   In Android, every application runs in its own process,
    which gives better performance in security, protected
    memory and other benefits.

   Therefore, Android is responsible to run and shut
    down correctly these processes when it is needed.

   It is important that application developers
    understand how different application components (in
    particular Activity, Service, and Broadcast Receiver)
    impact the lifetime of the application's process.

   Not using these components correctly can result in
    the system killing the application's process while it is
    doing important work.
APPLICATION LIFECYCLE
    To determine which processes should be killed when low on
    memory, Android places each process into an "importance
    hierarchy" based on the components running in them and the
    state of those components. These process types are (in order of
    importance).

   A foreground process is one that is required for what the user
    is currently doing. Various application components can cause
    its containing process to be considered foreground in different
    ways. A process is considered to be in the foreground if any of
    the following conditions hold:
           It is running an Activity at the top of the screen that the user is interacting
            with (its onResume() method has been called).

           It has a BroadcastReceiver that is currently running (its
            BroadcastReceiver.onReceive() method is executing).

           It has a Service that is currently executing code in one of its callbacks
            (Service.onCreate(), Service.onStart(), or Service.onDestroy()).
APPLICATION LIFECYCLE
   A visible process is one holding an Activity that is visible to
    the user on-screen but not in the foreground (its onPause()
    method has been called). This may occur, for example, if
    the foreground Activity is displayed as a dialog that allows
    the previous Activity to be seen behind it. Such a process is
    considered extremely important and will not be killed
    unless doing so is required to keep all foreground processes
    running.

   A service process is one holding a Service that has been
    started with the startService() method. Though these
    processes are not directly visible to the user, they are
    generally doing things that the user cares about (such as
    background mp3 playback or background network data
    upload or download), so the system will always keep such
    processes running unless there is not enough memory to
    retain all foreground and visible process.
APPLICATION LIFECYCLE
   A background process is one holding an Activity that is not
    currently visible to the user (its onStop() method has been
    called). These processes have no direct impact on the user
    experience. Provided they implement their Activity life-cycle
    correctly (see Activity for more details), the system can kill
    such processes at any time to reclaim memory for one of the
    three previous processes types. Usually there are many of
    these processes running, so they are kept in an LRU list to
    ensure the process that was most recently seen by the user is
    the last to be killed when running low on memory.

   An empty process is one that doesn't hold any active
    application components. The only reason to keep such a
    process around is as a cache to improve startup time the next
    time a component of its application needs to run. As such, the
    system will often kill these processes in order to balance
    overall system resources between these empty cached
    processes and the underlying kernel caches.
SOFTWARE DEVELOPMENT
   Development Requirements
     Java
     Android SDK
     Eclipse IDE
     Android Development Tools Plugin for Eclipse
SOFTWARE DEVELOPMENT
 IDE and Tools

    Android SDK
      Class Library
      Emulator and System Images

      Documentation and Sample Code




    Eclipse IDE + ADT (Android Development Tools)
      Reduces Development and Testing Time
      Makes User Interface-Creation easier

      Makes Application Description Easier
SECURITY ISSUES
   Android mobile phone platform is going to be more secure
    than Apple’s iPhone or any other device in the long run. There
    are several solutions nowadays to protect Google phone from
    various attacks. One of them is security vendor McAfee, a
    member of Linux Mobile (LiMo) Foundation. This foundation
    joins particular companies to develop an open mobile-device
    software platform. Many of the companies listed in the LiMo
    Foundation have also become members of the Open Handset
    Alliance (OHA).

   As a result, Linux secure coding practice should successfully
    be built into the Android development process. However, open
    platform has its own disadvantages, such as source code
    vulnerability for black-hat hackers. In parallel with great
    opportunities for mobile application developers, there is an
    expectation for exploitation and harm. Stealthy Trojans
    hidden in animated images, particular viruses passed from
    friend to friend, used for spying and identity theft, all these
    threats will be active for a long run.
SECURITY ISSUES
   Another solution for such attacks is SMobile Systems
    mobile package. SecurityShield –an integrated
    application that includes anti-virus, anti-spam,
    firewall and other mobile protection is up and ready
    to run on the Android operating system. Currently,
    the main problem is availability for viruses to pose as
    an application and do things like dial phone numbers,
    send text messages or multi-media messages or make
    connections to the Internet during normal device use.
    It is possible for somebody to use the GPS feature to
    track a person’s location without their knowledge.
    Hence SMobile Systems is ready to notify and block
    these secure alerts. But the truth is that it is not
    possible to secure your mobile device or personal
    computer completely, as it connects to the internet.
    And neither the Android phone nor other devices will
    prove to be the exception.
ADVANTAGES
   There are a host of advantages that Google’s Android will derive
    from being an open source software. Some of the advantages
    include:
      Open - Android allows you to access core mobile device
        functionality through standard API calls.
      All applications are equal - Android does not differentiate
        between the phone's basic and third-party applications --
        even the dialer or home screen can be replaced.
      Breaking down boundaries - Combine information from the
        web with data on the phone -- such as contacts or
        geographic location -- to create new user experiences.
      Fast and easy development - The SDK contains what you
        need to build and run Android applications, including a
        true device emulator and advanced debugging tools.
DISADVANTAGES
   Bluetooth limitations
     Android doesn't support
        Bluetooth stereo (before 2.3)
        Contacts exchange (before 2.3)

        Wireless keyboards

        Screen capture natively (before 4.0)



    But it'll work with Bluetooth headsets, but that's about it

    Firefox Mobile isn't coming to Android
       Apps in Android Market need to be programmed with a
       custom form of Java
         → Mozilla won't have that
CONCLUSION
 With all upcoming applications and mobile
 services Google Android is stepping into the next
 level of Mobile Internet.
REFERENCES
 http://developer.android.com/index.html
 https://market.android.com/

 http://en.wikipedia.org/wiki/Android_%28operati
  ng_system%29
 http://www.android.com/

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:6/6/2013
language:Unknown
pages:58
jiang lifang jiang lifang
About