Duke Systems

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…
Google Chrome blamed for new MacBook Air crashes - The W... http://www.washingtonpost.com/business/technology/google-c...

Back to previous page

Why new MacBook Airs crash when running

Google’s Chrome
“Conspiracy theory”?
By VentureBeat.com, Published: June 29

A spate of crashing new MacBook Air laptops running Google’s Chrome browser had the tech
conspiracists in a tizzy, what with the frenemies relationship between iPhone-maker Apple and
Android-creator Google. But the root cause of the problem turns out to be much more mundane: the
MacBook’s graphic accelerator.

“We have identified a leak of graphic resources in the Chrome browser related to the drawing of
plugins on Mac OS X,” Google told Gizmodo Thursday. The leaky resource is causing a kernel panic
in the new MacBook Air’s Intel HD 4000 graphics chip, which has the Mountain View, Calif. Internet
giant befuddled, terming the problem a potential “bug” by Apple.

While both Google and Apple investigate, the Chrome browser was updated to disable some graphics
acceleration on the MacBook Air. A more permanent fix will be pushed out “in the coming days,”
Google assures concerned MacBook Air owners.

The response to all the fuss seems to have driven Mac fans away from Chrome and more solidly
toward Apple’s Safari browser. “Chrome is great for my Dad’s 2003 vintage PC. But on my Mac it
offers no advantage…it’s just another piece of redundant software to maintain. Safari all the way,”
said a 9to5Mac user named “Tigerlilly.”

Others questioned Google placing blame on Apple for a “bug” in the new MacBook Air. Which gets
us back to the conspiracy theories. Presumably, Apple developers tested the new MacBook Air on a
wide range of software, looking for problems. The trouble with Chrome may have surfaced, but been
overlooked. After all, wouldn’t a problem with Chrome push Apple fans deeper into the arms of
Safari — as is happening now?

Copyright 2012, VentureBeat

© The Washington Post Company

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

...and upcalls
Protected
(e.g., signals)
system calls
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

Mal wants the power. Can

Mal trick Bob to get it?

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.

http://finntrack.co.uk/, erights.org
http://www.cap-lore.com/CapTheory/ConfusedDeputyM.html
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
 Virtual
Machine
(JVM)

C/C++

[http://www.android.com]
 Dalvik JVM (Interpreter)

Dalvik interprets
Java bytecode. Android apps
compile to bytecode.

Bytecode is an abstract Dalvik has various

machine instruction set. optimizations for the
Android platform.
Java source compiles
to bytecode.
Android: components
• Apps declare typed components.
Component
– metadata list of components (manifest)

• Components have upcall intents, RPC

interfaces visible to system.
• System instantiates and destroys
components driven by events in
the system and UI. upcalls
• System upcalls components to
notify them of lifecycle events.
System App
• Apps may interact by typed
messages among components.
– events (intents)
– object invocation (binder RPC)
Components run in contexts
context
• Components are Java code. (app process)
– A component is a class in an app.
instances
– Its name is (appname, classname).
– Apps are named as packages. JVM+lib
component
• Components run in JVM contexts.
launch
– Each component runs at most one (activate)
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
Apps are isolated app “sandbox”

• Components in the same app app

generally share a context. files
• Components in different apps are
always in different contexts.
• Apps cannot reference each context
other’s memory contexts:
JVM+lib
– “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.
app
– Principle of Least Privilege
Component launch
• To launch a component: app context
– Select a JVM context to run it.
– Tell JVM to instantiate the class.
launch
• System communicates with the JVM+lib
context via its system library. load
• System obtains info about the System class
component from app manifest.
– Class  component type: the
component class descends from a
system base class. manifest
read
– List of event profiles (intent filters)
manifest app
that trigger component launch.

If there is no JVM context active for the

component’s app, then the system must start one.
App launch
Zygote is a preinitialized “warm”
JVM image for unborn children.

Zygote children setuid to

Activity
start app uid
Manager JVM+lib
Service
etc. fork

JVM+lib JVM+lib

Linux kernel

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

App launch

Zygote forked child

Activity context
Manager JVM+lib
Service
etc.
launch
JVM+lib

open
read App files

Linux kernel

No exec needed: all Android contexts run the same

Linux program: the JVM. Fork is just right!
Binder: object RPC channels
Services
register to
Activity advertise for
Manager JVM+lib clients.
Service
etc.
Bindings are
reference-counted. A client binds
JVM+lib
to a service.

Android binder
an add-on kernel driver
for binder RPC Linux kernel
Android services and libraries communicate by sending
messages through shared-memory channels set up by binder.
Android environment server

Activity
Manager JVM+lib
Service
etc.

JVM+lib

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.
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
If a service has no
bound clients, the
Activity system may
deactivate it.
Manager
Service
etc.
JVM+lib
X
JVM+lib

The Activity Manager decides when to deactivate

components and tear down app contexts.
Deactivating components and apps
If an app has no
active components,
Activity the system may
Manager JVM+lib deactivate it.
Service
etc.
X JVM+lib

The Activity Manager decides when to deactivate

components and tear down app contexts.
Deactivating components and apps
If an app has no
active components,
Activity the system may
Manager JVM+lib deactivate it.

X
Service
etc.

JVM+lib

The Activity Manager decides when to deactivate

components and tear down app contexts.
Deactivating components and apps

The user navigates with

Activity the screen and buttons,
Manager JVM+lib activating components
Service and moving on.
etc.
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 manipulates contexts.

• With no special kernel support! It
uses same syscalls as anyone else. Android
• Unix provides no syscalls for AMS
managing another context (just kill). subsystem JVM+lib

• AMS controls user contexts by Linux

forking them with a trusted lib, and kernel binder
issuing RPC commands to that lib.