Professional Documents
Culture Documents
Android
Open
so6ware
pla8orm
for
mobile
development
A
complete
stack:
OS,
Middleware,
ApplicaDons
An
Open
Handset
Alliance
(OHA)
project
Powered
by
Linux
operaDng
system
Open
source
under
the
Apache
2
license
Email,
calendar,
browser,
maps,
text
messaging,
contacts,
camera,
dialer,
music
player,
seOngs
and
others
A bit of process
Set
up
Set
up
your
development
environment
Install
the
Android
SDK,
Android
Development
Tools,
and
Android
pla8orms
Set
up
AVDs
and
devices
for
tesDng
Create
Android
Virtual
Devices
(AVDs)
and
connect
hardware
devices
on
which
you
can
install
your
applicaDons
Development Create your applicaDon Create an Android project with your source code, resource les, and Android manifest le
Build and run your applicaDon Build and run your applicaDon in debug mode
Debug your applicaDon Debug your applicaDon using the Android debugging and logging tools
Test your applicaDon Test your applicaDon using the Android tesDng instrumentaDon framework
Publishing
Prepare your applicaDon for release Congure, build, and test your applicaDon in release mode
Release your applicaDon Publicize, sell, and distribute your applicaDon to users
Linux
Kernel
Based
on
Linux
kernel
2.6
Works
as
a
Hardware
AbstracDon
Layer
Provides
High
security
Device
drivers
Memory
management
Process
management
Networking
Libraries
C/C++
libraries
Interface
through
Java
Surface
manager
UI
Windows
RunDme
DVM
(Dalvik
Virtual
Machine)
Java
source
code
is
compiled
to
a
class
le
(.class)
Later
transformed
to
Dalvik
Executable
(.dex)
Compact
and
ecient
Limited
memory
and
bacery
power
Core
Libraries
Java
standard
ediDon
CollecDons,
I/O
etc
Highest
levels
ApplicaDon
Framework
Provides
all
kinds
of
APIs
needed
to
develop
applicaDons
AcDvity
manager
manages
applicaDon
life
cycle
ApplicaDons
ApplicaDons
developed
with
Java
email
client,
SMS
program,
calendar,
browser
and
contacts
applicaDons
Packaging
An
applicaDon
is
a
single
APK
(applicaDon
package)
le
An
APK
le
roughly
has
three
main
components
Dalvik
executable:
all
your
Java
source
code
compiled
down
to
Dalvik
executable
Resources:
everything
that
is
not
code
(images,
audio/video
clips,
XML
les
describing
layouts,
language
packs,
and
so
on)
NaDve
libraries:
e.g.
C/C++
libraries
Manifest
User
permissions
the
applicaDon
requires
Minimum
API
Level
required
by
the
applicaDon
Hardware
and
so6ware
features
used
or
required
by
the
applicaDon
API
libraries
the
applicaDon
needs
to
be
linked
against
And
more
Security
model
Android
OS
is
a
mulD-user
Linux
system
in
which
each
applicaDon
is
a
dierent
user
The
system
assigns
each
applicaDon
a
unique
Linux
user
ID
(the
ID
is
unknown
to
the
applicaDon)
The
system
sets
permissions
for
all
the
les
in
an
applicaDon
so
that
only
the
user
ID
assigned
to
that
applicaDon
can
access
them
4
building
blocks
AcDviDes
Services
Content
providers
Broadcast
receivers
AcDviDes
Represent
the
presentaDon
layer
of
an
Android
applicaDon
An
acDvity
consists
of
a
single
screen
the
user
sees
For
example,
an
acDvity
that
shows
a
list
of
new
emails,
another
acDvity
to
compose
an
email,
and
another
acDvity
for
reading
emails
Although
acDviDes
work
together,
each
one
is
independent
of
the
others
An
acDvity
is
implemented
as
a
subclass
of
Ac#vity
An
applicaDon
can
start
any
one
of
these
acDviDes
Services
Are
component
that
run
in
the
background
to
perform
long-running
operaDons
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 dierent applicaDon, or it might fetch data over the network without blocking user interacDon with an acDvity Another component, such as an acDvity, can start the service and let it run or bind to it in order to interact with it A service is implemented as a subclass of Service
Content
providers
Manage
a
shared
set
of
applicaDon
data
You
can
store
the
data
in
the
le
system,
an
SQLite
database,
on
the
web,
or
any
other
persistent
storage
locaDon
your
applicaDon
can
access
Through
the
content
provider,
other
applicaDons
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
informaDon
Any
applicaDon
with
the
proper
permissions
can
query
it
to
read
and
write
informaDon
about
a
parDcular
person
Content providers are also useful for reading and wriDng data that is private to your applicaDon and not shared. Provide uniform APIs for: querying, deleting, updating, and inserting elements
A content provider is implemented as a subclass of ContentProvider and must implement a standard set of APIs that enable other applicaDons to perform transacDons
Broadcast
receivers
Are
components
that
respond
to
system-wide
broadcast
announcements
Many
broadcasts
originate
from
the
systemfor
example,
a
broadcast
announcing
that
the
screen
has
turned
o,
the
bacery
is
low,
or
a
picture
was
captured
ApplicaDons
can
also
iniDate
broadcastsfor
example,
to
let
other
applicaDons
know
that
some
data
has
been
downloaded
to
the
device
and
is
available
for
them
to
use
For
instance,
it
might
iniDate
a
service
to
perform
some
work
based
on
the
event
A
broadcast
receiver
is
implemented
as
a
subclass
of
BroadcastReceiver
and
each
broadcast
is
delivered
as
an
Intent
object
A broadcast receiver is just a "gateway" to other components and is intended to do a very minimal amount of work
Key terminology
AcDvaDng
Components
AcDviDes,
services,
and
broadcast
receivers
are
acDvated
by
Intent
Intents
bind
individual
components
to
each
other
at
runDme
An
intent
is
created
with
an
Intent
object,
which
denes
a
message
to
acDvate
either
a
specic
component
or
a
specic
type
of
component
For
acDviDes
and
services,
an
intent
denes
the
acDon
to
perform
For
broadcast
receivers,
the
intent
simply
denes
the
announcement
being
broadcast
They
are
acDvated
when
targeted
by
a
request
from
a
ContentResolver
This
leaves
a
layer
of
abstracDon
between
the
content
provider
and
the
component
requesDng
informaDon
(for
security)
Example
methods
There
are
separate
methods
for
acDvaDng
each
type
of
component
You
can
start
an
acDvity
(or
give
it
something
new
to
do)
by
passing
an
Intent
to
startAcDvity()
or
startAcDvityForResult()
(when
you
want
the
acDvity
to
return
a
result)
You
can
start
a
service
(or
give
new
instrucDons
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
iniDate
a
broadcast
by
passing
an
Intent
to
methods
like
sendBroadcast(),
sendOrderedBroadcast(),
or
sendSDckyBroadcast()
You
can
perform
a
query
to
a
content
provider
by
calling
query()
on
a
ContentResolver
Main
characterisDcs
Any
applicaDon
can
start
another
applicaDons
component
For
example,
one
can
simply
start
the
acDvity
in
the
camera
applicaDon
that
captures
a
photo.
When
complete,
the
photo
is
even
returned
to
your
applicaDon
so
you
can
use
it
When
the
system
starts
a
component,
it
starts
the
process
for
that
applicaDon
and
instanDates
the
classes
needed
for
the
component
For
example,
if
one
starts
the
acDvity
in
the
camera
applicaDon
that
captures
a
photo,
that
acDvity
runs
in
the
process
that
belongs
to
the
camera
applicaDon,
not
in
your
applicaDon's
process
To
acDvate
a
component
in
another
applicaDon,
you
must
deliver
a
message
to
the
system
that
species
your
intent
to
start
a
parDcular
component
The
system
then
acDvates
the
component
for
you
An applicaDon cannot directly acDvate a component from another applicaDon, but the Android system can
SQLite