mobile computing - fenix.tecnico.ulisboa.pt · mobile communications market continued to build...

Mobile Computing – 2011/2012

Mobile Computing

Introduction to Android

Mobile Computing – 2011/2012 2

What is Android?

• Open-source software stack for mobile devices

• OS, middleware and key applications

• Based upon a modified version of the Linux kernel

• Java-based, object-oriented application framework on top of Java core libraries running on a Dalvik virtual machine

• Libraries written in C include the surface manager, OpenCore media framework, SQLite relational database management system, OpenGL ES 1.0 3D graphics API, WebKit layout engine, SGL graphics engine, SSL, and Bionic libc.


History (1/2)

• October, 2003 - Android Inc. founded by Andy Rubin et al. to develop "...smarter mobile devices that are more aware of its owner's location and preferences."

• August, 2005 - Google acquired Android Inc. 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. Speculation about Google's intention to enter the mobile communications market continued to build through December 2006.

• September, 2007 - Google filed several patent applications in the area of mobile telephony.


History (2/2)

• November 5, 2007 - Unveiling of the Open Handset Alliance, a consortium of several companies whose goal is to develop open standards for mobile devices. Also unveiled is their first product, Android, a mobile device platform built on the Linux kernel version 2.6. Members include Texas Instruments, Broadcom Corporation, Google, HTC, Intel, LG, Marvell Technology Group, Motorola, Nvidia, Qualcomm, Samsung Electronics, Sprint Nextel and T-Mobile.

• September 23, 2008 – Android 1.0 is released.

• December 9, 2008 - 14 new members joined, including PacketVideo, ARM Holdings, Atheros Communications, Asustek Computer Inc, Garmin Ltd, Softbank, Sony Ericsson, Toshiba Corp, and Vodafone Group Plc.


Versions• 1.0 - Released September 23, 2008

• 1.1 - Released February 9, 2009

• 1.5 (Cupcake) - Released April 30, 2009

• 1.6 (Donut) - Released September 15, 2009

• 2.0 / 2.1 (Eclair) - Released October 26, 2009 (2.0) and January 12, 2010 (2.1)

• 2.2 (Froyo) - Released May 20, 2010

• 2.3 (Gingerbread) - Released December 6, 2010

• 3.0 (Honeycomb) - Released February 22, 2011

• Optimized tablet-only release featuring new UI, refined multi-tasking, hardware acceleration and support for multi-core processors. Source was never released.

• 4.0 (Ice Cream Sandwich) – Released October 19, 2011

• Phone and tablet release, merging some of the new features of 3.0 (Honeycomb)


Features

• Application framework enabling reuse and replacement of components

• Dalvik virtual machine optimized for mobile devices

• 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, accelerometer and gyroscope (hardware dependent)

• Rich development environment including a device emulator, tools for debugging, memory and performance profiling, and a plugin for the Eclipse IDE


Architecture


Message-driven component-based framework

• Loose-coupling allows component sharing between applications thus improving code reuse, reducing development time and providing for better resource usage

• Components of core applications (e.g. Browser, phone caller, contact list, media player, map viewer, etc.) are all available to the app developer provided that the required permissions are granted (see below)

• Security is still an important issue!

• Each component specifies a set of permissions which the caller is required to be granted with by the user (at install time)

• Each application runs within its own process space

• If an application makes use of components belonging to other apps those components will run within their own separate processes


Intent

• Object which encapsulates a message sent between components

• Component name (optional)

• Action – operation to be performed

• Data – URI and MIME type of the data to be acted upon (see about content providers later on)

• Category – additional information about the kind of component that should handle the message

• Extras – key-value pairs providing extra information to the component which will handle the message

• Flags – various sorts, many instruct the Android system on how a component should be launched


Intent resolution and intent filters

• Intent resolution

• Explicit intents – the name of the target component is specified

• Implicit intents – no target is specified, the intent is broadcast in the system and its properties are matched to the intent filters of all available components

• Intent filter

• Matched properties: action, data and category

• Extras and flags play no part in intent resolution

• A component which does not have any intent filters can only receive explicit intents

• Two different kinds of broadcasts!

• For foreground operations (changes what the user is interacting with): startActivity

• For background operations: sendBroadcast


Components

• Activity – provides a screen for the user to interact with

• Service – performs long-running background operations, does not provide UI

• Content provider – allows the sharing of data across applications, provides store and retrieve operations

• Can use any kind of persistent storage (filesystem, SQLite, cloud, etc.)

• Data is identified by a URI

• For each MIME type there is a corresponding registered content provider

• Broadcast receiver – responds to system-wide broadcast announcements (sent with sendBroadcast)

• Intended to do minimal amount of work, just a gateway to other components


Activities

• Each activity represents a single screen with a user interface

• Activities work together to provice a cohesive user experience, however each one is independent of the others

• Different activities can be started by different apps (as long as the application allows it)

• UI for an activity is provided by a hierarchy of views (more on this later)

• An activity can start another activity by calling startActivity() or startActivityForResult() (the result will be passed as an argument to the onActivityResult() callback)

• Shutdown of the current activity by calling finish() or by a different one calling finishActivity()


Back stack• Running activities for the same task are managed in a back stack

• Current activity is the one on top of the stack

• Starting a new activity will push it to the top of the stack

• Pressing the back button or finishing the activity will pop the current activity from the top of the stack and go back to the previous

• Activity management can be modified by use of flags.

• Examples:

• The application can bring forward an existing activity instead of creating a new one on top of the back stack

• A new activity can be started in a new task (i.e. a new back stack) instead of the current one

• On leaving an activity the back stack can be cleared of all activities with exception of the root activity

• Use with care! Most apps won’t need to change the defaults. Always test if you do!


Activity lifecycle


Views

• UI building blocks

• Each view is an object derived from the View class

• Each view controls a rectangular space within the activity’s window and responds to user interaction

• Two basic kinds of views:

• Widgets – basic interactive screen elements (e.g. button, checkbox, etc.)

• Layouts – views derived from ViewGroup which define how their children are arranged in the screen (e.g. linear, grid, relative, etc.)

• Layouts (view hierarchies) can be defined programatically or in a XML file (most common approach)

• Use setContentView() to specify an activity’s root ViewGroup


Services

• Components which perform long-running operations in the background (e.g. network communication, file I/O, media file playing, etc.)

• Can continue running even if the user switches to another application

• A service can be started by calling startService()

• The service can run indefinitely even if the calling component is terminated

• The service should stop itself after the operation is completed

• A service can be bound by calling bindService()

• A bound service offers a client-server interface for allowing client components to interact with it (send requests, get results)

• Binding can be performed across process boundaries with IPC

• A bound service runs only as long as the component bound to it

• Multiple components can be bound to the service

• When the last component is unbound the service is destroyed


Service lifecycle


Broadcast receivers• Listen to system-wide broadcast intents

• Two major classes of broadcast:

• Normal broadcasts sent with sendBroadcast() – completely asynchronous, all receivers are run in an undefined order, often at the same time

• Ordered broadcasts sent with sendOrderedBroadcast – each receiver is called one at a time

• Order is defined by the priority of each receiver

• Each receiver propagates a result to the next one, or can abort the broadcast so it won’t be passed to the others

• A BroadcastReceiver object is only valid for the duration of the call to onReceive(Context, Intent)

• Therefore asynchronous operations are not available

• Use the NotificationManager API for showing dialogs

• Use Context.startService() to send a command to a service


Content providers• Android provides a number of content providers for common data types (audio,

video, images, personal contact information, etc.)

• Two ways to share your data with other apps:

• Add your data to an existing provider for your data type (as long as you have write permissions)

• Write your own by extending the ContentProvider class

• Implement the following methods: query(), insert(), update(), delete(), getType() and onCreate()

• Both content providers and their data are identified by URIs

• A record URI consists of the URI for its content provider appended with the record’s ID

• A query receives the URI for the provider and a set of filtering arguments and return a cursor object

• Format of the filtering arguments is based on SQL syntax


Process lifecycle (1/3)

1. Foregroung process: A process that is required for what the user is currently doing. A process is considered to be in the foreground if any of the following conditions are true:

• It hosts an Activity that the user is interacting with (the Activity's onResume() method has been called).

• It hosts a Service that's bound to the activity that the user is interacting with.

• It hosts a Service that's running "in the foreground"—the service has called startForeground().

• It hosts a Service that's executing one of its lifecycle callbacks (onCreate(), onStart(), or onDestroy()).

• It hosts a BroadcastReceiver that's executing its onReceive() method.



2. Visible process: A process that doesn't have any foreground components, but still can affect what the user sees on screen. A process is considered to be visible if either of the following conditions are true:

• It hosts an Activity that is not in the foreground, but is still visible to the user (its onPause() method has been called). This might occur, for example, if the foreground activity started a dialog, which allows the previous activity to be seen behind it.

• It hosts a Service that's bound to a visible (or foreground) activity.

• A visible process is considered extremely important and will not be killed unless doing so is required to keep all foreground processes running.



3. Service process: A process that is running a service that has been started with the startService() method and does not fall into either of the two higher categories. Although service processes are not directly tied to anything the user sees, they are generally doing things that the user cares about so the system keeps them running unless there's not enough memory to retain them along with all foreground and visible processes.

4. Background process: A process holding an activity that's not currently visible to the user (the activity's onStop() method has been called). These processes have no direct impact on the user experience, and the system can kill them at any time to reclaim memory for a foreground, visible, or service process.

5. Empty process: A process that doesn't hold any active application components.


Threads (1/2)

• UI thread (main thread) created on application launch

• Responsible for event dispatch to UI widgets

• Thread where interaction occurs between the application and the Android UI toolkit components

• All components running in the same process are instantiated in the UI thread

• Long running operations will block the UI thread! (the app will appear to freeze)

• Use worker threads to perform long-running background operations

• However the Android UI toolkit is not thread-safe!

• UI components should not be updated from outside the UI thread!


Threads (2/2)

• Android offers several ways to access the UI thread from other threads

• Activity.runOnUiThread(Runnable)

• View.post(Runnable)

• View.post(Runnable, long)

• Handler class for handling more complex interactions by processing messagesposted to the thread’s message queue

• Extend AsyncTask class (usually the best solution)

• doInBackground(): runs operation in worker thread

• onPostExecute(): runs in UI thread, receives the result fromdoInBackground()


Security and permissions• Android is a privilege-separated OS

• Each app runs with a distinct system identity (Linux user ID and group ID)

• Parts of the system are also separated into distinct identities

• Finer-grained security is provided through the permission mechanism

• Restrictions on the specific operations that a particular process can perform

• Every additional capability not provided by the basic sandbox must beexplicitly authorized

• Per-URI permissions for granting ad-hoc access to specific pieces of data

• Permissions must be declared statically

• No support for setting permissions dinamically (at run-time) because itcomplicates the user experience

• All apps must be signed with a developer certificate (can be self-signed)

• Allows the system to grant/deny access to signature-level permissions andrequests to be given the same Linux identity as another application


Manifest file

• AndroidManifest.xml file is required in the app root directory

• Java package name for the application (serves as a unique identifier)

• Describes the components of the application (activities, services, broadcast receivers, and content providers) and publishes their capabilities (e.g. intent filters)

• Determines which processes will host application components

• Requested permissions for accessing protected parts of the API and interact with other applications

• Required permissions for others to interact with the application's components

• Minimum level of the Android API that the application requires.

• Libraries the application must be linked against.


Today’s class assignment

• Follow the tutorials available from:

• http://developer.android.com/resources/browser.html?tag=tutorial

http://developer.android.com/resources/browser.html?tag=tutorial


Useful links

• Android Developers: http://developer.android.com

• SDK

• Dev Guide

• Reference

• Resources

• Videos

• Blog

• Remember, Google is your friend!

http://developer.android.com/

mobile computing - fenix.tecnico.ulisboa.pt · mobile communications market continued to build...

Documents