Application Fundamentals

1. Qin LIU 2010.5.26 Application Fundamentals

2. Agenda • Android architecture • Android application • Application component • Activity; • Service; • Broadcast Receiver; • Content Provider; • Intent • The manifest file • Intent filters • Life cycle for Application Component

3. Android Architecture

4. Linux Kernel

5. Linux Kernel • Android is built on the Linux kernel, but Android is not Linux • Provide core system services such as process, memory, power management, network stack, driver model and security • Does not include the full set of standard Linux utilities • The Android kernel source is available today • http://git.android.com

6. Drivers in Android • Android Unique Drivers • Ashmem • Logger • Binder • Android Power Management • Low Memory Killer • Android PMEM • Hardware Equipment Drivers • Framebuffer • Event • V4l2 • OSS • ALSA • MTD • Bluetooth • Wlan

7. Ashmem • The ashmem subsystem is a new shared memory allocator • /dev/ashmem • Major Number:10 (Misc Driver)

8. Binder • corba-like IPC • /dev/binder • Major Number:10 (Misc Driver)

9. Framebuffer • Driver for Display Equipment • /dev/fbX • Major Number: 29

10. Libraries

11. Native Libraries • Bionic Libc • Function Libraries • Native Servers • Hardware Abstraction Libraries

12. Bionic Libc • C/C++ library • Custom libc implementation, optimized for embedded use. • Pros (compare with glibc) • BSD License • Small size and fast code paths • Very fast and small custom pthread implementation • Not compatible with Gnu Libc (glibc)

13. Function Libraries • WebKit • Based on open source WebKit browser • Full CSS, Javascript, DOM, AJAX support • Media Framework • Based on PacketVideoOpenCORE platform • Supports standard video, audio, still-frame formats • SQLite • Light-weight transactional data store • Back end for most platform data storage

14. Native Servers-Surface Flinger • Provides system-wide surface “composer”, handling all surface rendering to frame buffer device • Can combine 2D and 3D surfaces and surfaces from multiple applications

15. Native Servers- Audio Flinger • Manages all audio output devices • Handles audio routing to various outputs

16. Hardware Abstraction Libraries

17. Hardware Abstraction Libraries • User space C/C++ library layer • Defines the interface that Android requires hardware “drivers” to implement • Separates the Android platform logic from the hardware interface • Why do we need a user-space HAL? • Not all components have standardized kernel driver interfaces • Kernel drivers are GPL which exposes any proprietary IP • Android has specific requirements for hardware drivers

18. Libraries

19. Android Runtime • Application Developed language : Java • Dalvik Virtual Machine • Instruvtion set : DalvikExcutable • Java Standard Library • Compile java code to DalvikExcutable (dex format)

20. Dalvik Virtual Machine • Android custom implementation virtual machine • Provides application portability and runtime consistency • Runs optimized file format (.dex) and Dalvikbytecode • Java .class / .jar files converted to .dex at build time • Designed for embedded environment • Supports multiple virtual machine processes per device • Highly CPU-optimized bytecode interpreter • Efficiently Using runtime memory • Core Libraries • Core APIs for Java language provide a powerful, yet simple and familiar development platform

21. DVM vs JVM • DVM • Google • Dalvikexcutable • JVM • Sun • Java bytecode • What else ?

22. Application Framework

23. Application Framework • Activity manager • Manage the life cycle of applications • Content Provider • Share data between applications • Resource Manager • Manager non-code resource • Notification Manager • Display custom alerts in the status bar • Views System • A rich and extensible set, which can construct UI

24. Application Framework

25. Applications • Use the powerful and flexible application framework to develop your application • Written by JAVA programming language

26. Why use Linux for a phone? • Linux kernel is a proven core platform. • Reliability is more important than performance when it comes to a mobile phone, because voice communication is the primary use of a phone. • Linux can help meet this requirement. • Linux provides a hardware abstraction layer, letting the upper levels remain unchanged despite changes in the underlying hardware. • As new accessories appear on the market, drivers can bewritten at the Linux level to provide support, just as on other Linux platforms.

27. Dalvik Virtual Machine • User applications, as well as core Android applications, are written in the Java programming language and are compiled into byte codes. • Android byte codes are interpreted at runtime by an interpreter known as the Dalvik virtual machine.

28. Why another JavaVirtual Machine? • Android bytecode files are logically equivalent to Java bytecodes, but they permit Android to • – run its applications in its own virtual environment • – is free from Sun’s licensing restrictions and • – an open platform upon which Google, and potentially the open source community, can improve as necessary.

29. Android Application • Java • Code; Data; Resource files->by appt tool -> .apk file ->distributing and installing Android Asset Packaging Tool Code Data Resource files .apk file

30. Android application’s world • By default, every application runs in its own Linux process. • Each process has its own virtual machine (VM), so application code runs in isolation from the code of all other applications. • By default, each application is assigned a unique Linux user ID.

31. Application Components • A central feature of Android is that one application can make use of elements of other applications (provided those applications permit it). • Application Components • Activities • Services • Broadcast receivers • Content providers

32. Application Building Blocks

33. Activities • An activity presents a visual user interface for one focused endeavor the user can undertake. • Each one is implemented as a subclass of the Activity base class. • An application might consist of just one activity or, like the text messaging application just mentioned, it may contain several. • Each activity is given a default window to draw in. • The visual content of the window is provided by a hierarchy of views — objects derived from the base View class. • A view hierarchy is placed within an activity's window by the Activity.setContentView()method.

34. Services • A service doesn't have a visual user interface, but rather runs in the background for an indefinite period of time. • Each service extends the Service base class. • It's possible to connect to (bind to) an ongoing service (and start the service if it's not already running). • Like activities and the other components, services run in the main thread of the application process.

35. Broadcast receivers • A broadcast receiver is a component that does nothing but receive and react to broadcast announcements. • All receivers extend the BroadcastReceiver base class. • Broadcast receivers do not display a user interface. However, they may start an activity in response to the information they receive, or they may use the NotificationManager to alert the user.

36. Content providers • A content provider makes a specific set of the application's data available to other • The content provider extends the ContentProvider base class to implement a standard set of methods that enable other applications to retrieve and store data of the type it controls. • However, applications do not call these methods directly. Rather they use a ContentResolver object and call its methods instead.

37. Activating components: intents • Content providers are activated when they're targeted by a request from a ContentResolver. The other three components — activities, services, and broadcast receivers — are activated by asynchronous messages called intents. • An intent is an Intent object that holds the content of the message. • For activities and services, it names the action being requested and specifies the URI of the data to act on, among other things.

38. Activating an activity • An activity is launched (or given something new to do) by passing an Intent object to Context.startActivity() or Activity.startActivityForResult(). • One activity often starts the next one. If it expects a result back from the activity it's starting, it calls startActivityForResult() instead of startActivity(). • The responding activity can look at the initial intent that caused it to be launched by calling its getIntent() method. Android calls the activity's onNewIntent() method to pass it any subsequent intents.

39. Activating a service • A service is started (or new instructions are given to an ongoing service) by passing an Intent object to Context.startService(). • Android calls the service's onStart() method and passes it the Intent object. • Similarly, an intent can be passed to Context.bindService() to establish an ongoing connection between the calling component and a target service. • The service receives the Intent object in an onBind() call.

40. Activating a broadcast • An application can initiate a broadcast by passing an Intent object to methods like Context.sendBroadcast(), Context.sendOrderedBroadcast(), and Context.sendStickyBroadcast() in any of their variations. • Android delivers the intent to all interested broadcast receivers by calling their onReceive() methods.

41. Shutting down components • A content provider is active only while it's responding to a request from a ContentResolver. • And a broadcast receiver is active only while it's responding to a broadcast message. • An activity can be shut down by calling its finish() method. One activity can shut down another activity (one it started with startActivityForResult()) by calling finishActivity(). • A service can be stopped by calling its stopSelf() method, or by calling Context.stopService().

42. The manifest file • Before Android can start an application component, it must learn that the component exists. Therefore, applications declare their components in a manifest file that's bundled into the Android package, the .apk file • The manifest is a structured XML file and is always named AndroidManifest.xml for all applications. • Activities, services, and content providers that are not declared in the manifest are not visible to the system and are consequently never run. However, broadcast receivers can either be declared in the manifest, or they can be created dynamically in code (as BroadcastReceiver objects) and registered with the system by calling Context.registerReceiver().

43. Declare the activity

44. Intent filters • An Intent object can explicitly name a target component. • If it does, Android finds that component (based on the declarations in the manifest file) and activates it. • But if a target is not explicitly named, Android must locate the best component to respond to the intent. • It does so by comparing the Intent object to the intent filters of potential targets.

45. Intent filters

46. Activities and Tasks • A task is a stack of activities, not a class or an element in the manifest file.

47. Processes and Threads • When the first of an application's components needs to be run, Android starts a Linux process for it with a single thread of execution. • The process where a component runs is controlled by the manifest file. • All components are instantiated in the main thread of the specified process, and system calls to the component are dispatched from that thread. • Android may decide to shut down a process at some point, when memory is low and required by other processes that are more immediately serving the user. • When deciding which processes to terminate, Android weighs their relative importance to the user. • Even though you may confine your application to a single process, there will likely be times when you will need to spawn a thread to do some background work.