The Google Android Stack Open Handset Alliance Content • Operators - Open Handset Alliance [05.11.07] – T-Mobile, Telecom Italia, Telefonica, NTT DoCoMo, KDDI, Sprint, China - Android Mobile Phone Software Stack Mobile [12.11.07] • Handset Manufacturers - Android Application Model – HTC, LG, Motorola, Samsung - Dalvik • Semiconductor Companies – Audience, Broadcom, Intel, Marvell, NVIDIA, Qualcomm, SiRF, Synaptics, Texas Instruments • Software Companies [Applications] – Ascender, eBay, Esmertec, Google, LivingImage, NMS Communications, Dominik Gruntz & Carlo Nicola, IMVS Nuance Communications, PacketVideo, SkyPop, SONiVOX, [email protected] • Commercialization Companies [email protected] – Aplix, TAT, Wind River, Noser (C) Hochschule für Technik (C) Hochschule für Technik 18 December 2007 Fachhochschule Nordwestschweiz 1 18 December 2007 Fachhochschule Nordwestschweiz 2 Android Software Stack (1/5) Android Software Stack (2/5) • Java • Kernel – Linux 2.6 Kernel – Hardware Abstraction Layer Proven driver model Provides Memory Management / Process Management / Networking Security Model – Unix C APIs are available • C/C++ • Kernel (C) Hochschule für Technik (C) Hochschule für Technik 18 December 2007 Fachhochschule Nordwestschweiz 3 18 December 2007 Fachhochschule Nordwestschweiz 4 Android Software Stack (3/5) Android Software Stack (4/5) • Open-Source Libraries [C/C++] • Runtime – Surface Manager composing windows on the screen – Dalvik VM [Dan Bornstein] – SGL 2D Graphics Register-based VM – OpenGL|ES 3D Library (HW acceleration possible) Optimized for low memory requirements – Media FW (PacketVideo) Audio/Video Codecs (mp3, AAC, mpg4, …) Designed to allow multiple VM instances to run at once • Every program runs in its own process / own VM instance – FreeType Font rendering Relies on the underlying OS for process isolation, memory management and – WebKit Browser Engine threading support – libc (System C libraries) Operates on DEX files – SQLite – Core Libraries – OpenSSL (C) Hochschule für Technik (C) Hochschule für Technik 18 December 2007 Fachhochschule Nordwestschweiz 5 18 December 2007 Fachhochschule Nordwestschweiz 6 Android Software Stack (5/5) Android SDK • Application Layer • SDK [Windows / Mac OS X intel / Linux i386] – Browser, Contacts, Maps, … – http://code.google.com/android/ • Application Framework • Content – All Applications are equal – android.jar android application framworkd (classes only) – Applications are written in Java – docs 100MB documentation – Android Application Model: Activities & Intents – samples 5 sample apps (+ skeleton app) – tools various tools like adb (android debugger), dx, … • Demo (C) Hochschule für Technik (C) Hochschule für Technik 18 December 2007 Fachhochschule Nordwestschweiz 7 18 December 2007 Fachhochschule Nordwestschweiz 8 Android Applications Android Applications: Life Cycle • Activity [Midlet] • Android Applications (Activities) – UI component typically corresponding to one screen – Runs in its own process E.g. Contacts: 3 activities: View contacts, Send message, Edit contact – Processes are started & stopped as needed • Intent Receiver [Push Registry] – Processes may be killed to reclaim resources – Responds to external events, can wake up your process – Upon Invocation of another activity, the view state is saved (icicle) Phone rings, network activity established, time controlled • Service Home Inbox Details Browse Maps – Task that runs in the background (e.g. mp3 player) without UI – Messages can be sent to a service • Content Provider – Comparable with EJBs stateful session beans (SFSB) – Enables applications to share data E.g. Contacts are provided to all applications (C) Hochschule für Technik (C) Hochschule für Technik 18 December 2007 Fachhochschule Nordwestschweiz 9 18 December 2007 Fachhochschule Nordwestschweiz 10 Android Applications: Intents as Components Android Applications: Content Providers • Intents • Android Application – Allows to invoke other activities from own activity – Every Android Application has access to its own database – Data is provided to other applications via content providers startActivity(new Intent(Intent.VIEW_ACTION, new ContentURI("http://www.fhnw.ch")); abstract class ContentProvider { public Cursor query(ContentURI uri, startActivity(new Intent(Intent.VIEW_ACTION, String[] projection, String selection, new ContentURI("geo:47.480843,8.211293")); String[] selectionArgs, String groupBy, String having, String sortOrder); public ContentURI insert(ContentURI uri, ContentValues values) public int delete(ContentURI uri, String selection, – Own Intent Handlers can be registered String[] selectionArgs); public int update(ContentURI uri, => Component Model on Activity Level ContentValues values, String selection, String[] selectionArgs) } (C) Hochschule für Technik (C) Hochschule für Technik 18 December 2007 Fachhochschule Nordwestschweiz 11 18 December 2007 Fachhochschule Nordwestschweiz 12 Android Applications: Content Providers Android Applications: Other Aspects • Access to Data Providers • Security Model – Comparable to a DB Access (Cursor) – Each application runs in its own process and has a unique Linux User ID – Identification via URI Created files have same User ID content://contacts/phones – Permissions for specific operations Declared in Manifest and checked at installation time String[] projections = new String[]{ "number", "name", "_id", "photo"}; • User Interface – Declarative Layouts (XUL) Cursor cur = managedQuery( new ContentURI("content://contacts/phones"), • APIs projections, null, "name ASC"); – Location API – Notification Manager – XMPP Service allows to send device-to-device data to other android users (multiplyer game, geo information, …) (C) Hochschule für Technik (C) Hochschule für Technik 18 December 2007 Fachhochschule Nordwestschweiz 13 18 December 2007 Fachhochschule Nordwestschweiz 14 Dalvik: Android Under the Hood The complexity of the Java VM "down under" • Dalvik Your program – Small fishing village in Eyjafjörður in Iceland – Home of one of the ancestor of Dan Bornstein objects = instantiation Info from parsing of classes the class file: java byte code of the class. Program counters for the different threads Each thread has a separate Java stack Profiler + JIT (C) Hochschule für Technik (C) Hochschule für Technik 18 December 2007 Fachhochschule Nordwestschweiz 15 18 December 2007 Fachhochschule Nordwestschweiz 16 Google's 10 Design Principles How the Dalvik VM manages this complexity 1. Focus on the user and all else will follow. 1. Run transparently normal Java .class/.jar files. 2. It's best to do one thing really, really well. 2. Use runtime memory very efficiently. 3. Fast is better than slow. 3. Run code with an highly cpu-optimized interpreter. 4. Democracy on the web works. 4. Support multiple virtual machine processes per device. 5. You don't need to be at your desk to need an answer. 5. Provide class/namespace hiding mechanism for multiple 6. You can make money without doing evil. JSR/spec compliance. 7. There's always more information out there. 6. Seamless integration with an underlying system that includes a 8. The need for information crosses all borders. large amount of native code. 9. You can be serious without a suit. 10. Great just isn't good enough. Amdahl's law: Make the common case fast (C) Hochschule für Technik (C) Hochschule für Technik 18 December 2007 Fachhochschule Nordwestschweiz 17 18 December 2007 Fachhochschule Nordwestschweiz 18 Some other less essential characteristics Interpreter's Efficiency and Performance • Include low-effort/lightweight JIT. 1. New file format (.dex) is designed for runtime efficiency: • Host other dynamic languages as efficiently as Java: a) shared constant pool across classes (reduces memory) – without altering the semantic of original language and without adding a b) maximize read-only structures (improves the sharing in cross-address- runtime "impedance-matching" layer space) – The likeliest candidates are: JavaScript, Python c) structures made as concise and fixed-width as possible (reduces parse • Do exact garbage collection of thread stacks. time) 2. Byte codes are engineered for speed of interpretation. a) register-based instructions instead of stack-based (higher semantic => These goals are as yet not fully implemented. density, reduced memory I/O overhead, reduced instruction dispatch overhead) b) only fixed-width instructions (simplifies parsing) c) 16 bit code units (minimizes instruction stream reads) (C) Hochschule für Technik (C) Hochschule für Technik 18 December 2007 Fachhochschule Nordwestschweiz 19 18 December 2007 Fachhochschule Nordwestschweiz 20 How Android runs Java How to play efficiently with native code • Working hypothesis about the most likely environment on which 1. Provide efficient and lightweight native linkage Android runs: a) Goal: zero-overhead native method calling – Normally all preinstalled apps come with a .dex file. b) Implication: Java and native code in the same thread use a shared stack – Subsequently-encountered code gets translated on-the-fly. 2. Use underlying OS facilities wherever possible – Really new Java code is a relative rarity. a) native threads and mutexes – Not so fast flash memory is abundant. b) isolation through process separation 3. Share heap with native non-Java-oriented code so it make sense to: native graphics, UI, etc. – cache the translated .dex files liberally for both user-installed apps and 4. Self-host to a reasonable extent transiently-used applets (or similar