Download ppt

ANDROID
ARCHITECTURE AND APPS
ANDROID ARCHITECTURE

http://www.tutorialspoint.com/android/android_architecture.htm
LINUX KERNEL
Provides basic system functionality (e.g. process
management, memory management, device
management – like the camera, etc.)
Also handles things like networking and the various
device drivers which ease the effort of interfacing
with peripheral hardware.
LIBRARIES
Give you the ability to handle different kinds of
data on the device
Examples: media framework library supports
playback and recording of various audio and video
formats, 3d acceleration library for accelerometer,
web browser library.
Also contains SQLite datebase.
ANDROID RUNTIME
Core Libraries: Includes a set of libraries that allow
programmers to build their apps using Java.
Dalvik Virtual Machine: Sort of like the JVM that is
designed specifically for Android. Uses core
libraries like memory management and multithreading.
APPLICATION FRAMEWORK
Provides higher level services to applications in the
form of Java classes.
Application developers have full access to the
framework.
Allows App developers to take advantage of the
processing features of the device.
Makes life easier for developer.
APPLICATION FRAMEWORK
APPLICATIONS
Top layer of Android Architecture.
Primary interaction layer for the device user.
Contacts, games, Browser, etc…
ANDROID APPLICATION LIFE CYCLE
APP FUNDAMENTALS
Apps are written in the Java Programming Language
The Android Software Development Kit (SDK)
compiles code (and related data and resources)
into an Android package (.apk).
ANDROID FUNDAMENTALS - SECURITY
 Once installed each app lives in its own security sandbox.
 Each app is a different user as far as the underlying Linux system
(multi-user) is concerned
 Each app assigned a unique Linux user ID. Permissions for file are
set such that only apps with correct ID can access them.
 Each process has its own VM so that it is isolated from other
apps.
 Every app runs in its own Linux process.
 Principle of least privilege.
APPLICATION DATA SHARING
You can arrange for two applications to share the
same Linux user ID which allows file sharing. This
allows them to share same VM to conserve system
resources.
Applications can request permission to access
device data such as user’s contacts, SMS messages,
camera, etc – these are granted at install time.
APPLICATION COMPONENTS
Four types of application components:
Activities
Services
Content Providers
Broadcast receivers
ACTIVITIES
Represents a single screen with a user interface.
Allows the user to interact with the application.
A typical application will have multiple activities.
For example an email app will have an activity to
show a list of new emails, another activity to
compose an email, and another activity to read
email.
Implemented as a subclass of Activity
SERVICES
 This component runs in the background (does not provide a user
interface).
 Performs a long-running operation or does work for a remote
process.
 Example: A service might play music in the background while the
user performs some other function, fetch data over a network
while the user interacts with another activity.
 Services can be started by another component such as an
activity.
 Implemented as a subclass of Service.
CONTENT PROVIDERS
 Manages application data.
 Data can be stored in the file system, an SQLite database,
on the web, or any other persistent storage location that
your application can access.
 An application can query or modify (w/ appropriate
privileges) the data .
 Examples: user’s contacts, notes created with notepad app.
 Implemented as a subclass of ContentProviders
BROADCAST RECEIVERS
 Responds to system-wide broadcast announcements.
 Many are initiated from the system – screen is turned off, battery
low, etc.
 Apps can initiate broadcasts for things like letting other apps
know that data has been downloaded to the device.
 No GUI but may create a status bar notification.
 Primary function is to be a “gateway” to other components (e.g.
initiate a service to perform some work based on an event.
 Implemented as a subclass of BroadcastReceiver
COMPONENT SHARING
 Android allows apps to start another app’s
components.
 E.g. If your app needs a photo capture, there is
probably an app on the device that already does that
and you can use it. When complete, the photo is
returned to your app so you can use it.
 Appears as if these components are a part of your app.
 Because of security, your app cannot directly access
other applications.
INTENTS
 Intents are used to activate activities, services, broadcast
receivers.
 Content Providers are activated when targeted by a request
from a ContentSolver.
 Intents are asynchronous messages that request an action
from other components in your app or another app.
 Created with an Intent object.
 Defines a message to activate a specific component or
specific type of component.
ACTIVATING COMPONENTS
 You can start an activity (or give it something new to do) by passing
an Intent to startActivity() orstartActivityForResult() (when you want
the activity to return a result).
 You can start a service (or give new instructions to an ongoing service)
by passing an Intent to startService(). Or you can bind to the service by
passing an Intent to bindService().
 You can initiate a broadcast by passing an Intent to methods
like sendBroadcast(), sendOrderedBroadcast(),
or sendStickyBroadcast().
 You can perform a query to a content provider by calling query() on
a ContentResolver.
MANIFEST FILE
 The manifest does a number of things in addition to declaring the
application's components, such as:
 Identify any user permissions the application requires, such as Internet access or
read-access to the user's contacts.
 Declare the minimum API Level required by the application, based on which APIs the
application uses.
 Declare hardware and software features used or required by the application, such as
a camera, bluetooth services, or a multitouch screen.
 API libraries the application needs to be linked against (other than the Android
framework APIs), such as theGoogle Maps library.
 And more
APPLICATION RESOURCES
Non-code items needed in the application
E.g. audio files, images, things related to visual
presentation.
For every resource, the SDK tools define a unique
integer ID. Use the ID in code to access the
resource.
Provide alternative resources for different devices.