47
APPLICATION FUNDAMENTALS Qin LIU 2010.5.26

Application Fundamentals

  • Upload
    talli

  • View
    37

  • Download
    0

Embed Size (px)

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

Citation preview

Page 1: Application Fundamentals

APPLICATION FUNDAMENTALS

Qin LIU2010.5.26

Page 2: Application Fundamentals

Agenda Android architecture Android application Application component

Activity; Service; Broadcast Receiver; Content Provider;

Intent The manifest fileIntent filters

Life cycle for Application Component

Page 3: Application Fundamentals

Android Architecture

Page 4: Application Fundamentals

Linux Kernel

Page 5: Application Fundamentals

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

Page 6: Application Fundamentals

Drivers in Android Android Unique

DriversAshmemLoggerBinderAndroid Power

ManagementLow Memory KillerAndroid PMEM

Hardware Equipment DriversFramebufferEventV4l2OSSALSAMTDBluetoothWlan

Page 7: Application Fundamentals

Ashmem The ashmem subsystem is a new

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

Page 8: Application Fundamentals

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

Page 9: Application Fundamentals

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

Page 10: Application Fundamentals

Libraries

Page 11: Application Fundamentals

Bionic Libc Function Libraries Native Servers Hardware Abstraction Libraries

Native Libraries

Page 12: Application Fundamentals

• 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

Page 13: Application Fundamentals

• 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

Page 14: Application Fundamentals

• 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

Page 15: Application Fundamentals

Manages all audio output devices Handles audio routing to various outputs

Native Servers- Audio Flinger

Page 16: Application Fundamentals

Hardware Abstraction Libraries

Page 17: Application Fundamentals

• 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

Page 18: Application Fundamentals

Libraries

Page 19: Application Fundamentals

Application Developed language : Java Dalvik Virtual Machine

Instruvtion set : Dalvik Excutable Java Standard Library

Compile java code to Dalvik Excutable (dex format)

Android Runtime

Page 20: Application Fundamentals

• 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

Page 21: Application Fundamentals

DVMGoogleDalvik excutable

JVMSun○ Java bytecode

What else ?

DVM vs JVM

Page 22: Application Fundamentals

Application Framework

Page 23: Application Fundamentals

• 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

Page 24: Application Fundamentals

Application Framework

Page 25: Application Fundamentals

Use the powerful and flexible application framework to develop your application

Written by JAVA programming language

Applications

Page 26: Application Fundamentals

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.

Page 27: Application Fundamentals

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.

Page 28: Application Fundamentals

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.

Page 29: Application Fundamentals

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

tool -> .apk file ->distributing and installing

CodeData

Resource files

Android Asset Packaging Tool

.apk file

Page 30: Application Fundamentals

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.

Page 31: Application Fundamentals

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

Page 32: Application Fundamentals

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

Page 33: Application Fundamentals

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.

Page 34: Application Fundamentals

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.

Page 35: Application Fundamentals

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.

Page 36: Application Fundamentals

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.

Page 37: Application Fundamentals

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.

Page 38: Application Fundamentals

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.

Page 39: Application Fundamentals

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.

Page 41: Application Fundamentals

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().

Page 42: Application Fundamentals

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().

Page 43: Application Fundamentals

Declare the activity

Page 44: Application Fundamentals

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.

Page 45: Application Fundamentals

Intent filters

Page 46: Application Fundamentals

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

or an element in the manifest file.

Page 47: Application Fundamentals

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.