Android (Simplified)

(1)

D u k e S y s t e m s

Android (Simplified)

Jeff Chase

Duke University

(2)

Part 1: Background

(3)

(4)

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…

(5)

(6)

Back to previous page

Why new MacBook Airs crash when running Google’s Chrome

By VentureBeat.com, Published: J une 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 identiﬁed 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 ﬁx 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?

Google Chrome blamed for new MacBook Air crashes - The W... http://www.washingtonpost.com/business/technology/google-c...

1 of 1 7/1/12 8:47 AM

“Conspiracy theory”?

(7)

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.

(8)

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

(9)

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 )

(10)

X Windows (1985)

Big change: GUI.

1.Windows

2.Window server

3.App events

4.Widget toolkit

(11)

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

(12)

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?

(13)

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.

(14)

(15)

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

(16)

[http://www.android.com]

Virtual Machine

(JVM)

C/C++

(17)

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.

(18)

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

(19)

Components run in contexts

• Components 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)

(20)

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

(21)

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  component type: the

component class descends from a system base class.

– 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.

(22)

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.

(23)

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

(24)

(25)

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

(26)

Android environment server

JVM+lib

Activity Manager

Service etc.

The Activity Manager maintains a binding to every app context.

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.

(33)

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.

(34)

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.

(35)

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.

(36)

Saving/restoring activity state

(37)

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.

(38)

Service

(39)

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.

(40)

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.