Application Fundamentals

Post on 23-Feb-2016

37 views 0 download

description

Qin LIU 2010.5.26. Application Fundamentals. Agenda. Android architecture Android application Application component Activity; Service; Broadcast Receiver; Content Provider; Intent The manifest file Intent filters Life cycle for Application Component. Android Architecture. - PowerPoint PPT Presentation

Transcript of Application Fundamentals

APPLICATION FUNDAMENTALS

Qin LIU2010.5.26

Agenda Android architecture Android application Application component

Activity; Service; Broadcast Receiver; Content Provider;

Intent The manifest fileIntent filters

Life cycle for Application Component

Android Architecture

Linux Kernel

Android is built on the Linux kernel, but Android is not Linux

Provide core system services such as process, memory, power management, network stack, driver model and security

Does not include the full set of standard Linux utilities

The Android kernel source is available today http://git.android.com

Linux Kernel

Drivers in Android Android Unique

DriversAshmemLoggerBinderAndroid Power

ManagementLow Memory KillerAndroid PMEM

Hardware Equipment DriversFramebufferEventV4l2OSSALSAMTDBluetoothWlan

Ashmem The ashmem subsystem is a new

shared memory allocator /dev/ashmem Major Number:10 (Misc Driver)

Binder corba-like IPC /dev/binder Major Number:10 (Misc Driver)

Framebuffer Driver for Display Equipment /dev/fbX Major Number: 29

Libraries

Bionic Libc Function Libraries Native Servers Hardware Abstraction Libraries

Native Libraries

• C/C++ library• Custom libc implementation, optimized for

embedded use.• Pros (compare with glibc)

– BSD License– Small size and fast code paths– Very fast and small custom pthread implementation

• Not compatible with Gnu Libc (glibc)

Bionic Libc

• WebKit– Based on open source WebKit browser– Full CSS, Javascript, DOM, AJAX support

• Media Framework– Based on PacketVideo OpenCORE platform– Supports standard video, audio, still-frame formats

• SQLite– Light-weight transactional data store– Back end for most platform data storage

Function Libraries

• Provides system-wide surface “composer”, handling all surface rendering to frame buffer device

• Can combine 2D and 3D surfaces and surfaces from multiple applications

Native Servers-Surface Flinger

Manages all audio output devices Handles audio routing to various outputs

Native Servers- Audio Flinger

Hardware Abstraction Libraries

• User space C/C++ library layer• Defines the interface that Android requires hardware

“drivers” to implement• Separates the Android platform logic from the

hardware interface• Why do we need a user-space HAL?

– Not all components have standardized kernel driver interfaces

– Kernel drivers are GPL which exposes any proprietary IP– Android has specific requirements for hardware drivers

Hardware Abstraction Libraries

Libraries

Application Developed language : Java Dalvik Virtual Machine

Instruvtion set : Dalvik Excutable Java Standard Library

Compile java code to Dalvik Excutable (dex format)

Android Runtime

• Android custom implementation virtual machine– Provides application portability and runtime consistency– Runs optimized file format (.dex) and Dalvik bytecode– Java .class / .jar files converted to .dex at build time

• Designed for embedded environment– Supports multiple virtual machine processes per device– Highly CPU-optimized bytecode interpreter– Efficiently Using runtime memory

• Core Libraries– Core APIs for Java language provide a powerful, yet simple

and familiar development platform

Dalvik Virtual Machine

DVMGoogleDalvik excutable

JVMSun○ Java bytecode

What else ?

DVM vs JVM

Application Framework

• Activity manager– Manage the life cycle of applications

• Content Provider– Share data between applications

• Resource Manager– Manager non-code resource

• Notification Manager– Display custom alerts in the status bar

• Views System– A rich and extensible set, which can construct UI

Application Framework

Application Framework

Use the powerful and flexible application framework to develop your application

Written by JAVA programming language

Applications

Why use Linux for a phone? Linux kernel is a proven core platform. Reliability is more important than performance

when it comes to a mobile phone, because voice communication is the primary use of a phone.

Linux can help meet this requirement. Linux provides a hardware abstraction layer,

letting the upper levels remain unchanged despite changes in the underlying hardware.

As new accessories appear on the market, drivers can bewritten at the Linux level to provide support, just as on other Linux platforms.

Dalvik Virtual Machine User applications, as well as core

Android applications, are written in the Java programming language and are compiled into byte codes.

Android byte codes are interpreted at runtime by an interpreter known as the Dalvik virtual machine.

Why another JavaVirtual Machine? Android bytecode files are logically

equivalent to Java bytecodes, but they permit Android to– run its applications in its own virtual

environment – is free from Sun’s licensing restrictions

and– an open platform upon which Google, and

potentially the open source community, can improve as necessary.

Android Application Java Code; Data; Resource files->by appt

tool -> .apk file ->distributing and installing

CodeData

Resource files

Android Asset Packaging Tool

.apk file

Android application’s world By default, every application runs in its

own Linux process. Each process has its own virtual

machine (VM), so application code runs in isolation from the code of all other applications.

By default, each application is assigned a unique Linux user ID.

Application Components A central feature of Android is that one

application can make use of elements of other applications (provided those applications permit it).

Application ComponentsActivitiesServicesBroadcast receiversContent providers

Application Building BlocksName Description

Activity UI component typically corresponding to one screen

BroadcastReceiver Responds to notifications or status changes. Can wake up your process

Service Faceless task that run in the background

Content Provider Enable application to share data

Activities An activity presents a visual user interface for one

focused endeavor the user can undertake.Each one is implemented as a subclass of the Activity

base class.An application might consist of just one activity or, like the

text messaging application just mentioned, it may contain several.

Each activity is given a default window to draw in. The visual content of the window is provided by a

hierarchy of views — objects derived from the base View class.

A view hierarchy is placed within an activity's window by the Activity.setContentView() method.

Services A service doesn't have a visual user

interface, but rather runs in the background for an indefinite period of time. Each service extends the Service base class. It's possible to connect to (bind to) an ongoing

service (and start the service if it's not already running).

Like activities and the other components, services run in the main thread of the application process.

Broadcast receivers A broadcast receiver is a component

that does nothing but receive and react to broadcast announcements. All receivers extend the BroadcastReceiver

base class. Broadcast receivers do not display a user

interface. However, they may start an activity in response to the information they receive, or they may use the NotificationManager to alert the user.

Content providers A content provider makes a specific set of

the application's data available to other The content provider extends the

ContentProvider base class to implement a standard set of methods that enable other applications to retrieve and store data of the type it controls.

However, applications do not call these methods directly. Rather they use a ContentResolver object and call its methods instead.

Activating components: intents Content providers are activated when they're

targeted by a request from a ContentResolver. The other three components — activities, services, and broadcast receivers — are activated by asynchronous messages called intents.

An intent is an Intent object that holds the content of the message.

For activities and services, it names the action being requested and specifies the URI of the data to act on, among other things.

Activating an activity An activity is launched (or given something new to do)

by passing an Intent object to Context.startActivity() or Activity.startActivityForResult().

One activity often starts the next one. If it expects a result back from the activity it's starting, it calls startActivityForResult() instead of startActivity().

The responding activity can look at the initial intent that caused it to be launched by calling its getIntent() method. Android calls the activity's onNewIntent() method to pass it any subsequent intents.

Activating a service A service is started (or new instructions are given to an

ongoing service) by passing an Intent object to Context.startService().

Android calls the service's onStart() method and passes it the Intent object.

Similarly, an intent can be passed to Context.bindService() to establish an ongoing connection between the calling component and a target service.

The service receives the Intent object in an onBind() call.

Shutting down components A content provider is active only while it's responding to a

request from a ContentResolver.

And a broadcast receiver is active only while it's responding to a broadcast message.

An activity can be shut down by calling its finish() method. One activity can shut down another activity (one it started with startActivityForResult()) by calling finishActivity().

A service can be stopped by calling its stopSelf() method, or by calling Context.stopService().

The manifest file Before Android can start an application component, it must

learn that the component exists. Therefore, applications declare their components in a manifest file that's bundled into the Android package, the .apk file

The manifest is a structured XML file and is always named AndroidManifest.xml for all applications.

Activities, services, and content providers that are not declared in the manifest are not visible to the system and are consequently never run. However, broadcast receivers can either be declared in the manifest, or they can be created dynamically in code (as BroadcastReceiver objects) and registered with the system by calling Context.registerReceiver().

Declare the activity

Intent filters An Intent object can explicitly name a target

component. If it does, Android finds that component

(based on the declarations in the manifest file) and activates it.

But if a target is not explicitly named, Android must locate the best component to respond to the intent.

It does so by comparing the Intent object to the intent filters of potential targets.

Intent filters

Activities and Tasks A task is a stack of activities, not a class

or an element in the manifest file.

Processes and Threads When the first of an application's components needs to be run,

Android starts a Linux process for it with a single thread of execution. The process where a component runs is controlled by the manifest

file. All components are instantiated in the main thread of the specified

process, and system calls to the component are dispatched from that thread.

Android may decide to shut down a process at some point, when memory is low and required by other processes that are more immediately serving the user.

When deciding which processes to terminate, Android weighs their relative importance to the user.

Even though you may confine your application to a single process, there will likely be times when you will need to spawn a thread to do some background work.