Understanding Android Architecture: Open Source Mobile Toolkit

1. Android Kathy Wienhold CS-502, June 8, 2010 Android Logo: Portions of this page are reproduced from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.

2. Goals of Android • Open source software stack for mobile devices • Provide developers with a toolkit for building new types of experiences • Component-based architecture: Provide open & extensible architecture to allow pieces to be combined & recombined in innovative ways • Includes run-time binding of services, to allow upgrade/replacement at user desire

3. Android Architecture Android Architecture Image: Portions of this page are reproduced from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.

4. Android Architecture: Linux Kernel Binder (IPC) Driver: Replaces standard SysV IPC Includes wakelocks Linux: 2.6 Kernel Hardware Abstraction Layer: Driver Model (& Drivers); Memory Management; Security Model; Process Management; Networking Android Architecture Image: Portions of this page are reproduced from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.

5. Android Architecture: Libraries Web Browser Data Storage Media Codecs Composing different visual elements on the screen Core of graphics library 3D 2D Libraries implemented in C/C++ Fonts SQLite: Data storage FreeType: Font rendering Media Framework: Contains common codecs (video & audio (MPG-4, H.264, MP3, AAC, etc.)); Provided by Packet Video (part of Open Handset Alliance) Graphics Libraries (OpenGL | ES; SGL): 3D & 2D graphics packages (3D is software implementation that is HW-accelerable, if supported); 3D & 2D can be used in same application Surface Manager: Composes drawing surfaces (from different processes) onto the screen. WebKit: Open source browser engine (also powers Safari); adapted to render well on small screens used by mobile devices Android Architecture Image: Portions of this page are reproduced from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.

6. Android Architecture: Android Runtime Core Libraries Dalvik VM Dalvik VM: Adapted from Java (modified for efficient memory/power/CPU usage (data structures can be shared across processes, where possible, optimized)); runs .dex file (byte codes built at compile-time); multiple instances of VM can run at same time Core Libraries: Written in java (all boxes in blue are java); collection classes; utilities; I/O Android Architecture Image: Portions of this page are reproduced from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.

7. Android Architecture: Application Framework Window Manager View System Content Providers Notification Manager Activity Manager XMPP Service Telephony Manager Resource Manager Location Manager Package Manager Activity Manager: Manages life cycle of applications; maintains a common “back” stack (smooth navigation experience) Package Manager: Keeps track of which applications are installed on device, and what their capabilities are Window Manager: Manages windows; builds on Surface Manager; Location Manager: Applications can register with LM to be notified when sufficiently close to a location, person, etc. View System: Buttons, lists, etc. (building blocks of the UI); handles even dispatching, layout, drawing Content Providers: Used to share data among applications (example: Contacts) XMPP Service: Applications can send device-to-device data messages to other Android devices (includes permission & security control) Notification Manager: Applications can be put into the status bar – alert users to interesting events Telephony Manager: Contains API for phone application Resource Manager: Stores localized strings; bitmaps; layout file descriptions (external parts of an application that aren’t code) Android Architecture Image: Portions of this page are reproduced from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.

8. Android Architecture: Applications Applications Applications: For any particular product, may be built-in or user-added Android Architecture Image: Portions of this page are reproduced from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.

9. Android: Application Architecture Basics: All applications run in their own processes. Android system itself starts and shuts down processes (resource management), transparently, including saving process state so it can be restored later. An application is typically one or more activities, plus a Linux process to contain them. Intents: Formal class in Android system. Uses the Binder IPC functionality (to be discussed later).

10. Android: Activity Lifecycle So very good “code hygiene” to make sure this is implemented correctly, even if process is destroyed without going through the onStop() or onDestroy() calls. If resources are really tight, this might be the last thing called before your application’s process is killed. Image from “Hello, Android”, by Ed Burnett, 3rd edition, Figure 2-3.

11. Android: Intents • “An intent is an abstract description of an operation to be performed.”1 • This allows run-time binding of services and functionalities • Parameters: • action: flag for type of action • Examples: ACTION_VIEW, ACTION_EDIT, ACTION_MAIN (for the application’s “main”), … • data: data to perform the action on, specified as a URI (uniform resource indicated) • Examples: http://www.google.com, tel:123, content://contacts/people 1 Android Developers website, Reference, Intents

12. Android: Services • An application which performs a long-running operation while not interacting with the user or supplies functionality for other applications to use.1 • May be part of a stand-alone application, or bundled with other components. • Pretty much what you would expect a service to be. 1 Android Developers website, Reference, Service

13. Android: Content Providers • Store and retrieve data that is accessible to all applications – example: Contacts: • import android.provider.Contacts.People; • Interface provided is the database table model – each row is a record, each column is a particular type of data with a particular meaning • Content providers are added to an application’s manifest file, telling the Android system of their presence – enabling use by other applications.

14. Android: Principal Abstractions & Services (PA&S) • Processes and concurrency • Synchronization and interprocess communication • Memory management, virtual memory, etc. • File systems and/or persistent storage • I/O and (possibly) graphics • Program loading & unloading • Networking and communication • Security • Multiprocessor Support We’ll look at each subject area in a separate slide, to make sure the bases are covered.

15. PA&S #1: Processes & Concurrency • Applications are a stack, starting with the “Home” application • One “foreground” application • The Activity Manager keeps track of things, killing and restoring processes “behind the scenes”, as needed. • Java threads available, but preferred development model has them subsumed under higher-level abstractions, such as the java.util.concurrent package. • See also the later discussion of Binder

16. PA&S #2: Synchronization and Interprocess Communication • For synchronization, developer preference is to use the inherent event framework (onXXX(…) methods). However, if exclusionary mechanisms are required, there are supporting java classes: • java.util.concurrent.locks.Lock • java.util.concurrent.locks.Condition • java.util.concurrent.Semaphore • For interprocess communication, see the later discussion on “Binder”.

17. PA&S #3: Memory Management, Virtual Memory, Etc. • ashmem (Android Shared Memory): See later discussion on ashmem. • Applications use the Dalvik VM, and the memory management inherent in it. • The Android Activity Manager manages system resources at a higher level, killing and restoring processes as needed.

18. PA&S #4: File Systems and/or Persistent Storage • The Android kernel patches include YAFFS2 (Yet Another Flash File System 2), which is a file system optimized for flash memory. It hooks into the Linux kernel through the standard interfaces for file system drivers. • PMEM: This driver manages large (1-16+MB), physically contiguous regions of memory shared between user space and kernel drivers (dsp, gpu, etc). • It was written specifically to deal with hardware limitations of the MSM7201A, but could be used for other chipsets as well.1 1 Embedded Linux Wiki, PMEM

19. PA&S #5: I/O and Graphics • The android team (in conjunction with the Open Handset Alliance) has added some drivers to support specific hardware, but made no other major changes. • Note that the X Window system is not present – it has been replaced by the Surface Manager and the Window Manager.

20. PA&S #6: Program Loading & Unloading • Each application instance runs as its own process (on top of its own VM). • A process are merely the current container for an application – see “PA&S #1: Processes & Concurrency”.

21. PA&S #7: Networking and Communication • Added “paranoid networking” option – restricts some networking features, depending upon the group ID of the calling process. • In the IPv4, IPv6 and bluetooth drivers. • [It is not precisely clear what these additional networking options are supposed do.]

22. PA&S #8: Security • Begins by relying on the Linux process-level independence. Each application is given its own UID and GID. • Interaction between applications is via Binder, and is specified in the application’s manifest. • Permissions (in application manifest) are evaluated at installation-time, and either granted or denied based on checks with trusted authorities and user feedback.

23. PA&S #9: Multiprocessor Support • No changes from standard Linux kernel.

24. Linux Kernel Differences • Added: Generic, standalone Android-related drivers • ashmem (Android shared memory implementation) • Low memory killer (resource management) • Binder: Interprocess communication (IPC) • Logger • Modifications: wakelocks We’ll look at each these individually • Added: Hardware-specific additions • Support for new SoCs (System on a Chip) • Added: Miscellaneous smaller changes – not significant from the perspective of system architecture & functionality • Political Side-Note on Linux Kernel Kerfuffle: 1, 2

25. ashmem • Android Shared Memory • Fairly standard shared memory implementation, • Optimized for low-memory devices • Reference-counted objects – kernel can free shared memory no longer in use • Lives in virtual memory

26. Low Memory Killer • Used when memory is running low • Selects a process to be killed, using hints from user-space • Algorithm looks for each process’s “importance”, and kills the one that scores lowest (examples: the process holding the foreground is the most important; process next back in the stack is likely to be more important than one deeper back in the stack) • Used by the Activity Manager

27. Binder (Part 1 of 4) • Originally from BeOS, corba-like IPC (very like Microsoft COM) • Used for interprocess communication instead of standard (SysV) IPC • Component, object-oriented interface • Developer uses Intents to invoke Binder, specifying action & data source • System determines service to bind to via permissions/ manifests • aidl tool (Android IDL) used to auto-generate a Binder subclass (with default marshallers/demarshallers)

28. Binder (Part 2 of 4) • Finding out about the implementation (as opposed to the concepts, interfaces, APIs, etc.) of this [short of just slogging through the kernel code] is difficult. It is based on (and simplified from) OpenBinder, which uses: • A file descriptor in the calling thread • An ioctl call on that file descriptor, with an associated data structure struct binder_write_read { ssize_t write_size; const void* write_buffer; ssize_t read_size; void* read_buffer; }; Upon call, contains commands to execute Upon return, contains responses

29. Binder (Part 3 of 4) • Implementation (cont’d): • Commands can increment/decrement object references (& other “bookkeeping” commands) • Execution occurs in a thread, with the Binder infrastructure maintaining a pool of available threads • Object references: • All references in a process to objects local to that process are in the form of an address in the process’s memory space. • All references to objects in another process are always in the form of an (abstract, 32-bit) handle

30. Binder (Part 4 of 4) • Used to share information across processes (file descriptors to shared memory regions, etc.) • Provides thread management for the system, so no threading support in system libraries • Security model – application manifest files indicate whether components are accessible to others, and to what degree • Seems to be the largest point-of-contention for the Linux developer community

31. Logger • Enables logging functionality built-in to Android

32. wakelocks • Used for power management, to prevent the system from going into a low-power state • Types of wakelocks: • WAKE_LOCK_IDLE: When a wakelock of this type is held, the system will not go into idle (low power) state • WAKE_LOCK_SUSPEND: When a wakelock of this type is held, the system will not suspend • Seems to be the other serious point-of-contention for the Linux developer community: 1

33. Android: Summary • Component-based architecture for mobile device development. • Any questions, discussion, etc.? Questions? Etc.

34. Background & Reference Materials

35. Resources Used • Burnett, Ed, “Hello, Android”, 3rd edition, 2010. • Meier, Reto, “Professional Android 2 Application Development” • Main Android Developer Site (both for application creators and for device manufacturers who want to run Android) • Android Modifications to Linux Kernel • Short Summary, Android Kernel Features • Porting Android: 1, 2

36. Security • http://developer.android.com/guide/topics/security/security.html • https://www.isecpartners.com/files/iSEC_Android_Exploratory_Blackhat_2009.pdf • http://siis.cse.psu.edu/slides/android-sec-tutorial.pdf