6-android - Duke University

publicyardΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

91 εμφανίσεις

D u k e S y s t e m s

Android (Simplified)

Jeff Chase

Duke University

Part 1: Background

From Bloomberg


Krall and General Counsel Bruce Sewell
have amassed a team of lawyers from
inside Apple and some of the top U.S. law
firms to fight Samsung, HTC, and Google’s
Motorola Mobility unit over Google’s
Android mobile operating system and the
smartphones and tablets that run on it.


The fight is central to Apple’s identity…it
got 46.4 percent of its sales from the
iPhone last quarter and 26 percent from
the iPad. The iPhone generated $47 billion
in sales last fiscal year….


Apple and Samsung together make more
than half of the smartphones sold in the
world. Samsung is the biggest player in the
global market and Apple is dominant in the
U.S. The companies are vying for …a
market that …grew 62 percent to $219 B…

B
a
c
k t
o pr
e
vi
ous
pa
ge
Wh
y n
e
w
M
ac
B
ook
A
i
r
s
c
r
as
h
w
h
e
n
r
u
n
n
i
n
g
G
oogl
e

s
C
h
r
om
e
By

V
e
n
t
u
r
e
Be
a
t
.
c
o
m
,

Pu
b
l
i
s
h
e
d
:
J
u
n
e

2
9
A
s
pa
t
e
of
c
r
a
s
hi
ng ne
w

M
a
c
B
ook A
i
r
l
a
pt
ops
r
unni
ng
G
oogl
e

s
C
hr
om
e
br
ow
s
e
r
ha
d t
he
t
e
c
h
c
ons
pi
r
a
c
i
s
t
s
i
n a
t
i
z
z
y
, w
ha
t
w
i
t
h t
he
f
r
e
ne
m
i
e
s
r
e
l
a
t
i
ons
hi
p be
t
w
e
e
n i
P
hone
-
m
a
ke
r
A
ppl
e
a
nd
A
ndr
oi
d-
c
r
e
a
t
or
G
oogl
e
. B
ut
t
he
r
oot
c
a
us
e
of
t
he
pr
obl
e
m
t
ur
ns
out
t
o be
m
uc
h m
or
e
m
unda
ne
:
t
he
M
a
c
B
ook’
s
gr
a
phi
c
a
c
c
e
l
e
r
a
t
or
.

W
e
ha
ve
i
de
nt
i

e
d a
l
e
a
k of
gr
a
phi
c
r
e
s
our
c
e
s
i
n t
he
C
hr
om
e
br
ow
s
e
r
r
e
l
a
t
e
d t
o t
he
d
r
a
w
i
ng of
pl
ugi
ns
on M
a
c
O
S
X
,”
G
oogl
e
t
ol
d
G
i
z
m
odo
T
hur
s
da
y
. T
he
l
e
a
ky r
e
s
our
c
e
i
s
c
a
us
i
ng a
ke
r
ne
l
pa
ni
c
i
n t
he
ne
w
M
a
c
B
ook A
i
r

s
I
nt
e
l

H
D
4000
gr
a
phi
c
s
c
hi
p, w
hi
c
h ha
s
t
he
M
ount
a
i
n V
i
e
w
, C
a
l
i
f
. I
nt
e
r
ne
t
gi
a
nt
be
f
uddl
e
d, t
e
r
m
i
ng t
he
pr
obl
e
m
a
pot
e
nt
i
a
l

bug”
by A
ppl
e
.
W
hi
l
e
bot
h G
oogl
e
a
nd A
ppl
e
i
nve
s
t
i
ga
t
e
, t
he
C
hr
om
e
br
ow
s
e
r
w
a
s
upda
t
e
d t
o di
s
a
bl
e
s
o
m
e
gr
a
phi
c
s
a
c
c
e
l
e
r
a
t
i
on on t
he
M
a
c
B
ook A
i
r
. A
m
or
e
pe
r
m
a
ne
nt

x w
i
l
l
be
pus
he
d out

i
n t
he
c
om
i
ng da
ys
,”
G
oogl
e
a
s
s
ur
e
s
c
onc
e
r
ne
d M
a
c
B
ook A
i
r
ow
ne
r
s
.
T
he
r
e
s
pons
e
t
o
a
l
l
t
he
f
us
s
s
e
e
m
s
t
o ha
ve
dr
i
ve
n M
a
c
f
a
ns
a
w
a
y f
r
om
C
hr
om
e
a
nd m
or
e
s
ol
i
dl
y
t
ow
a
r
d A
ppl
e

s
S
a
f
a
r
i
br
ow
s
e
r
. “
C
hr
om
e
i
s
gr
e
a
t
f
or
m
y D
a
d’
s
2003 vi
nt
a
ge
P
C
. B
ut
on
m
y M
a
c
i
t
of
f
e
r
s
no a
dva
nt
a
ge
…i
t

s
j
us
t
a
not
he
r
pi
e
c
e
of
r
e
dunda
nt
s
of
t
w
a
r
e
t
o m
a
i
nt
a
i
n. S
a
f
a
r
i
a
l
l
t
he
w
a
y
,”
s
a
i
d a
9t
o5M
a
c
us
e
r
na
m
e
d “
T
i
ge
r
l
i
l
l
y
.”
O
t
he
r
s
que
s
t
i
one
d G
oogl
e
pl
a
c
i
ng bl
a
m
e
on A
ppl
e
f
or
a

bug”
i
n t
he
ne
w
M
a
c
B
ook A
i
r
. W
hi
c
h ge
t
s
us
ba
c
k t
o t
he
c
ons
pi
r
a
c
y t
he
or
i
e
s
. P
r
e
s
um
a
bl
y
, A
ppl
e
de
ve
l
ope
r
s
t
e
s
t
e
d t
he
ne
w
M
a
c
B
o
ok A
i
r
on a
w
i
de
r
a
nge
of
s
of
t
w
a
r
e
, l
ooki
ng f
or
pr
obl
e
m
s
. T
he
t
r
oubl
e
w
i
t
h C
hr
om
e
m
a
y ha
ve
s
ur
f
a
c
e
d, but
be
e
n
ove
r
l
ooke
d. A
f
t
e
r
a
l
l
, w
oul
dn’
t
a
pr
obl
e
m
w
i
t
h C
hr
om
e
pus
h A
ppl
e
f
a
ns
de
e
pe
r
i
nt
o t
he
a
r
m
s
of
S
a
f
a
r
i
— a
s
i
s
ha
ppe
ni
ng now
?
C
opyr
i
ght
2012, V
e
nt
ur
e
B
e
a
t
©
T
he
W
a
s
hi
ngt
on P
os
t
C
om
pa
ny
G
oogl
e
C
hr
om
e
bl
a
m
e
d f
or
ne
w
M
a
c
B
ook A
i
r
c
r
a
s
he
s
-
T
he
W
...
ht
t
p:
/
/
w
w
w
.w
a
s
hi
ngt
onpos
t
.c
om
/
bus
i
ne
s
s
/
t
e
c
hnol
ogy/
googl
e
-
c
...
1 of
1
7/
1/
12 8:
47 A
M
“Conspiracy theory”?


Leading tech companies are filled with good
system builders with vision, strong principles,
and a commitment to technological purity.


Others in the company focus on market
strategy and tactics. By US law their
commitment to profits for the company’s
owners dominates other values.


Good system builders learn to understand the
social, legal, and market context for their
work. Technology choices are always
intertwined with market structure and strategic
concerns.


Unix, looking backward: UI+IPC


Conceived around keystrokes and byte streams


User
-
visible environment is centered on a text
-
based
command shell.


Limited view of how programs interact


files: byte streams in a shared name space


pipes: byte streams between pairs of sibling processes


Unix, looking backward: upcalls


Limited view of how programs interact with the OS.


The kernel directs control flow into user process at a fixed entry
point: e.g., entry for exec() is _crt0 or “main”.


Process may also register a
signal handlers

for events relating to
the process, (generally) signalled by the kernel.


Process lives until it exits voluntarily or fails


“receives an unhandled signal that is fatal by default”.


data

data

Protected
system calls

...and upcalls
(e.g., signals
)

X Windows (1985)

Big change
:
GUI.

1.
Windows

2.
Window server

3.
App events

4.
Widget toolkit


Unix, looking backward: security


Presumes multiple users sharing a machine.


Each user has a userID.


UserID owns all files created by all programs user runs.


Any program can access any file owned by userID.


Each user trusts all programs it chooses to run.


We “deputize” every program.


Some deputies get confused.


Result
: decades of
confused deputy
security problems.


Contrary view: give programs the privileges they
need, and nothing more.



Principle of Least Privilege

Confused deputy

http://finntrack.co.uk/
, erights.org

http://www.cap
-
lore.com/CapTheory/ConfusedDeputyM.html

Bob has the Power. Bob
wishes to hold the power
and use it properly.

Alice considers Bob her deputy in the use of this
Power. Alice trusts Bob to deny the power to Mal.

Mal wants the power. Can
Mal trick Bob to get it?

Android protection


Each application (“app”) runs with its own identity.


Each app has a private space of files, processes, etc. that
defines a “sandbox”.


It does not matter that they run on behalf of the same user:
the code matters more than the user. No deputies!


The system mediates access to the sensors and UI
by applications.


GPS, camera, microphone, touchpad, etc.


Each app declares the named permissions it needs.


subject to user approval


Each app declares the permissions another app
needs to interact with it.




Part 2, Android technology


The goal here is to present an overview of the
Android structure, and rationale for that structure.


We won’t learn how to program Android apps.
Detailed docs are available.


developer.android.com


What we offer is the conceptual underpinnings and
connections to other OS concepts.


We choose Android for its instructive value: open source.


Some images are borrowed from material on the
web. E.g., Google material:


Anatomy and Physiology of Android


[http://www.android.com]

Virtual
Machine

(JVM)

C/C++

Dalvik JVM (Interpreter)

Bytecode is an abstract
machine instruction set.


Java source compiles
to bytecode.


Android apps
compile to bytecode.


Dalvik has various
optimizations for the
Android platform.


Dalvik interprets
Java
bytecode
.


Android: components


Apps declare typed components.


metadata list of components (
manifest
)


Components have
upcall

interfaces visible to system.


System instantiates and destroys
components driven by events in
the system and UI.


System
upcalls

components to
notify them of lifecycle events.


Apps may interact by typed
messages among components.


events (
intents
)


object invocation (
binder RPC
)


Component

intents, RPC

System

App

upcalls

Components run in contexts


C
omponents are Java code.


A component is a class in an app.


Its name is
(
appname
,
classname
)
.


Apps are named as packages.


Components run in JVM contexts.


Each component runs at most one
instance in exactly one context.


Context is a process with a JVM and a
trusted system library.


Android library defines
context

object with
system API
.



app

context

(app process)

JVM+lib

instances

component
launch
(activate)

Apps are isolated


Components in the same app
generally share a context.


Components in different apps are
always in different contexts.


Apps cannot reference each
other’s memory contexts:


“soft” JVM protection


hard process boundaries


Apps interact only via IPC.


intents, events


service RPC and content put/get


Apps run with distinct user IDs.


Principle of Least Privilege




app

app “sandbox”

context

app
files

JVM+lib

Component launch


To launch a component:


Select a JVM context to run it.


Tell JVM to instantiate the class.


System communicates with the
context via its system library.


System obtains info about the
component from app manifest.


Class


捯浰潮敮琠瑹灥㨠瑨攠
捯浰潮敮琠捬c獳 摥d捥湤猠晲潭⁡
獹獴s洠扡b攠捬c獳.


List of event profiles (
intent filters
)
that trigger component launch.

System

JVM+lib

launch

manifest

read
manifest

load
class

app context

app

If there is no JVM context active for the
component’s app, then the system must start one.

App launch

JVM+lib

Linux kernel

Activity
Manager
Service

etc.

JVM+lib

Zygote

start

fork

JVM+lib

children

setuid to
app uid

How do we launch the application’s code? Exec?

Zygote

is a preinitialized “warm”
JVM image for unborn children.

App launch

JVM+lib

Linux kernel

Activity
Manager
Service

etc.

JVM+lib

Zygote

No exec needed: all Android contexts run the same
Linux program: the JVM. Fork is just right!

launch

open

read

App files

forked child
context

Binder: object RPC channels

JVM+lib

Linux kernel

Activity
Manager
Service

etc.

Android services and libraries communicate by sending
messages through shared
-
memory channels set up by
binder
.

JVM+lib

Android binder

A client
binds

to a service.

Bindings are
reference
-
counted.

Services
register

to
advertise for
clients.

an add
-
on kernel driver
for binder RPC

Android environment server

JVM+lib

Activity
Manager
Service

etc.

The Activity Manager maintains a binding to every app context.

Apps call system APIs and receive events via binder RPC calls
to/from Android Activity Manager etc.

JVM+lib

Post
-
note


Zygote also forks a system
service manager
on
system startup.


SM is a process that forks a lot of the basic Java
android services.


SM looks for installed apps with binder services in
the manifest, and starts those components.

-

They include daemons that listen to
usb
, audio etc.
and send events


Deactivating components and apps

JVM+lib

Activity
Manager
Service

etc.

The Activity Manager decides when to deactivate
components and tear down app contexts.

JVM+lib

If a service has no
bound clients, the
system may
deactivate it.

X

Deactivating components and apps

JVM+lib

Activity
Manager
Service

etc.

The Activity Manager decides when to deactivate
components and tear down app contexts.

JVM+lib

If an app has no
active components,
the system may
deactivate it.

X

Deactivating components and apps

JVM+lib

Activity
Manager
Service

etc.

The Activity Manager decides when to deactivate
components and tear down app contexts.

JVM+lib

If an app has no
active components,
the system may
deactivate it.

X

Deactivating components and apps

Activity
Manager
Service

etc.

JVM+lib

The user navigates with
the screen and buttons,
activating components
and moving on.

The components set up interactions among
themselves as needed to serve the user.

The system monitors activity and memory pressure and
cleans up behind components as needed.

The four component types

1.
Activity
. Display a screen.


Push on a “back stack”.


May be launched by other apps.

2.
Service
. Serve an API.


Establish an external binder interface.


Public methods are externally visible.

3.
Provider
. Get/put content objects.


Serve a URI space with MIME types.


Backed by SQLite database tables.

4.
Receiver
. Respond to events.


E.g., low battery.

Intents for activities and receivers


Intents

are named events.


Components signal intents with various attributes and data.


They declare
filters

to specify which intents they may receive.


Filter specifies named permissions the sender must have.


A component may invoke an activity with an
explicit

intent, which invokes a named target component.


A component may broadcast an
implicit

intent for
delivery to any interested receiver component.


Sender names permissions that each receiver must have.


The event may be sent to its receivers in order or in parallel.


See also
: implicit vs. explicit invocation in Garlan/Shaw.


Explicit intents and ordered broadcasts may receive a result.


Post
-
note


We did not discuss the state diagrams on the
following slides in any detail.


But understand that each executing
component is a
finite state machine
.


States are defined by the component type.


Transitions are driven by UI events and/or other
system or app events.


These events generate system upcalls or intents
to the component, which change its state.


Components in certain states are eligible to be
reclaimed by the system.


Activity


System
upcalls

component as its
state changes due to
user actions.


If another activity is
started, the activity is
paused.


If a paused activity is
not visible to the
user, it is stopped.


A stopped activity
may be destroyed.


And its app process
may be killed.


Saving/restoring activity state

Service


Services advertise one
or more binder
endpoints.


Clients choose to
bind/unbind (or unbind
when stopped).


A service with no bound
clients may be shut
down.

Service

For later


Threading models and concurrency


Each app has a main thread (
activity thread
) that controls its
UI and invokes the upcalls of its components as they are
needed. Apps must never block the activity thread.


Components can create other threads in various ways.


Binder/RPC structure


Service threading/queue models and request handling


RPC data translation


Permission structure


An extensible namespace of permissions whose meaning is
defined by system or by apps. For any interaction, both
components define the permissions needed by the other.

A note on “subsystems”


A
subsystem

is a server that provides system
functions to untrusting contexts, but runs with only
partial system privilege.


E.g., this code cannot manipulate the hardware state except
by invoking the kernel.

Android

AMS

subsystem

JVM+lib


Android AMS manipulates contexts.


With no special kernel support! It
uses same syscalls as anyone else.


Unix provides no syscalls for
managing another context (just kill).


AMS controls user contexts by
forking them with a trusted lib, and
issuing RPC commands to that lib.

Linux
kernel

binder