Menu

Menus offer a way to expose application functions without sacrificing valuable screen space. Each Activity can specify its own menu that’s displayed when the device’s menu button is pressed. Android also supports context menus that can be assigned to any View. Context menus are normally triggered when a user holds the middle D-pad button, depresses the trackball, or long-presses the touchscreen for around three seconds when the View has focus.

Activity and context menus support submenus, checkboxes, radio buttons, shortcut keys, and icons.

To improve the usability of application menus, Android features a three-stage menu system optimized
for small screens:

-The icon menu appears along the bottom of the screen when the menu button is pressed. It displays the icons and text for a limited number of Menu Items (typically six). This icon menu does not display checkboxes, radio buttons, or the shortcut keys for MenuItems.

If the Activity menu contains more than the maximum number of visible Menu Items, a More Menu Item is displayed. When selected, it displays the expanded menu. Pressing the back button closes the icon menu.

-The expanded menu The expanded menu is triggered when a user selects the More Menu Item from the icon menu. It displays a scrollable list of only theMenu Items that weren’t visible in the icon menu. This menu displays full text, shortcut keys, and checkboxes/radio buttons. It does not, however, display icons. Pressing back from the expanded menu returns you to the icon menu.

Submenus The traditional expanding hierarchical tree can be awkward to navigate using a mouse, so it’s no surprise that this metaphor is particularly ill-suited for use on mobile devices. The Android
alternative is to display each submenu in a floating window.

Since Android does not support nested submenus, you can’t add a submenu to a submenu. As with the extended menu, icons are not displayed in the submenu.

Defining a menu in XML
<menu xmlns:android="http://schemas.android.com/apk/res/android" android:name="Context Menu">
<item android:id="@+id/item01" android:icon="@drawable/menu_item" android:title="Item 1">
</item>
<item android:id="@+id/item02" android:checkable="true" android:title="Item 2">
</item>
<item android:id="@+id/item03" android:numericShortcut="3" android:alphabeticShortcut="3"
android:title="Item 3">
</item>
<item android:id="@+id/item04" android:title="Submenu">
<menu>
<item android:id="@+id/item05" android:title="Submenu Item">
</item>
</menu>
</item>
</menu>

To use your Menu resource, use the MenuInflator class within your onCreateOptionsMenu or onCreateContextMenu event handlers. Inflating an XML menu resource:

public void onCreateContextMenu(ContextMenu menu, View v, ContextMenu.ContextMenuInfo menuInfo) {
super.onCreateContextMenu(menu, v, menuInfo);
MenuInflater inflater = getMenuInflater();
inflater.inflate(R.menu.my_menu, menu);
menu.setHeaderTitle("Context Menu");
}

Drawable Resources

There are several new types of Drawables resources — including shapes and transformative and composite Drawables — and be shown how to use these resources to create user interfaces that are independent of screen size and resolution.

Drawables: Color,Shape,Gradient, Composite, Transformative, Layer, State List, LevelList, NinePatch

Color Drawable:
A ColorDrawable, the simplest of the XML-defined Drawables, lets you specify an image asset based on a single solid color. Color Drawables are defined as XML files using the <color> tag in the Drawable resources folder.
<color xmlns:android="http://schemas.android.com/apk/res/android" android:color="#FF0000"/>

Shape Drawable:
Shape Drawable resources let you define simple primitive shapes by defining their dimensions, background, and stroke/outline using the <shape> tag.

Each shape consists of a type (specified via the shape attribute), attributes that define the dimensions of
that shape, and subnodes to specify padding, stroke (or outline), and background color values.
Android currently supports the following shape types as values for the shape attribute:
oval A simple oval shape.
 rectangle Also supports a <corners> subnode that uses a radius attribute to create a rounded rectangle.
ring Supports the innerRadius and thickness attributes to let you specify, respectively, the inner radius of the ring shape and its thickness. Alternatively, you can use innerRadiusRatio and/or thicknessRatio to define the ring’s inner radius and thickness as a proportion of its width.

<?xml version="1.0" encoding="utf-8"?>
<shape xmlns:android="http://schemas.android.com/apk/res/android" android:shape="rectangle">
<solid android:color="#f0600000"/>
<stroke android:width="10dp" android:color="#00FF00"/>
<corners android:radius="15dp" />
<padding android:left="10dp" android:top="10dp" android:right="10dp" android:bottom="10dp"/>
</shape>

Gradient Drawable:
A GradientDrawable lets you design complex gradient fills. Each gradient defines a smooth transition
between two or three colors in a linear, radial, or sweep pattern.

Gradient Drawables are defined using the <gradient> tag as a subnode within a Shape Drawable definition. Each Gradient Drawable requires at least a startColor and endColor attribute and supports an optional middleColor.

Using the type attribute you can define your gradient as one of the following:
linear The default gradient type, it displays a straight color transition from startColor to endColor at an angle defined by the angle attribute.
radial Draws a circular gradient from startColor to endColor from the outer edge of the shape to the center. It requires a gradientRadius attribute that specifies the radius of the gradient transition in pixels. It also optionally supports centerX and centerY to offset the location of the center of the gradient. Because the gradient radius is defined in pixels it will not be dynamically scaled for different pixel densities. To minimize banding, you may need to specify different gradient radius values for different screen resolutions.
sweep Draws a sweep gradient that transitions from startColor to endColor along the outer edge of the parent shape (typically a ring).


Composite Drawables:
Use composite Drawables to combine and manipulate other Drawable resources. Any Drawable  resource can be used within the following composite resource definitions, including bitmaps, shapes, and colors. Similarly, these new Drawables can be used within each other and assigned to Views in the same way as all other Drawable assets.


Transformative Drawables:
You can scale and rotate existing Drawable resources using the aptly named ScaleDrawable and RotateDrawable classes. These transformative Drawables are particularly useful for creating progress bars or animating Views.

ScaleDrawable Within the <scale> tag, use the scaleHeight and scaleWidth attributes to define the target height and width relative to the bounding box of the original Drawable. Use the scaleGravity attribute to control the anchor point for the scaled image.
RotateDrawable Within the <rotate> tag, use fromDegrees and toDegrees to define the start and end rotation angle around a pivot point. Define the pivot using the pivotX and pivotY attributes,

<!-- Rotation Drawable Resource -->
<?xml version="1.0" encoding="utf-8"?>
<rotate xmlns:android="http://schemas.android.com/apk/res/android" android:drawable="@drawable/icon" android:fromDegrees="0" android:toDegrees="90"
android:pivotX="50%" android:pivotY="50%" />

<!-- Scale Drawable Resource -->
<?xml version="1.0" encoding="utf-8"?>
<rotate xmlns:android="http://schemas.android.com/apk/res/android" android:drawable="@drawable/icon" android:scaleHeight="100%" android:scaleWidth="100%"/>

Applying rotation and scale Drawable transformations in code
ImageView rotatingImage = (ImageView)findViewById(R.id.RotatingImageView);
ImageView scalingImage = (ImageView)findViewById(R.id.ScalingImageView);
// Rotate the image 50% of the way to its final orientation.
rotatingImage.setImageLevel(5000);
// Scale the image to 50% of its final size.
scalingImage.setImageLevel(5000);

Layer Drawable:
A LayerDrawable lets you composite several Drawable resources on top of one another. If you define an array of partially transparent Drawables you can stack them on top of one another to create complex
combinations of dynamic shapes and transformations.

Similarly, you can use Layer Drawables as the source for the transformative Drawable resources
described in the preceding section, or the State List and Level List Drawables that follow.

<?xml version="1.0" encoding="utf-8"?>
<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
<item android:drawable="@drawable/bottomimage"/>
<item android:drawable="@drawable/image2"/>
<item android:drawable="@drawable/image3"/>
<item android:drawable="@drawable/topimage"/>
</layer-list>

State List Drawables:
A State List Drawable is a composite resource that enables you to specify a different Drawable to display based on the state of the View to which it has been assigned. Most native Android Views use State List Drawables, including the image used on Buttons and the background used for standard List View items.

<selector xmlns:android="http://schemas.android.com/apk/res/android">
<item android:state_window_focused="false" android:drawable="@drawable/widget_bg_normal"/>
<item android:state_pressed="true" android:drawable="@drawable/widget_bg_pressed"/>
<item android:state_focused="true" android:drawable="@drawable/widget_bg_selected"/>
<item android:drawable="@drawable/widget_bg_normal"/>
</selector>

Level List Drawables:
Using a Level List Drawable you can effectively overlay several Drawable resources, specifying an
integer index value for each layer.

To select which image to display in code call setImageLevel on the View displaying the Level List
Drawable resource, passing in the index of the Drawable you wish to display.
imageView.setImageLevel(5);

The View will display the image corresponding to the index with an equal or greater value to the one
specified. Level List Drawables are particularly useful when creating Widget layouts.

NinePatch Drawable:
NinePatch (or stretchable) images are PNG files that mark the parts of an image that can be stretched.
NinePatch images must be properly defined PNG files that end in .9.png. The resource identifier for
NinePatches is the file name without the trailing .9.png.

A NinePatch is a variation of a PNG image that uses a one-pixel border to define the area of the image
that can be stretched if the image is enlarged. To create a NinePatch, draw single-pixel black lines that
represent stretchable areas along the left and top borders of your image. The unmarked sections won’t
be resized, and the relative size of each of the marked sections will remain the same as the image size
changes.

Layouts

Layout managers are extensions of the ViewGroup class used to position child controls for your UI. Layouts can be nested, letting you create arbitrarily complex interfaces using a combination of layouts.

-FrameLayout: The simplest of the Layout Managers, the Frame Layout simply pins each child view to the top left corner. Adding multiple children stacks each new child on top of the one before, with each new View obscuring the last.

-LinearLayout: A Linear Layout aligns each child View in either a vertical or a horizontal line. A vertical layout has a column of Views, while a horizontal layout has a row of Views. The Linear Layout manager enables you to specify a ‘‘weight’’ for each child View that controls the relative size of each within the available space.

- RelativeLayout: The most flexible of the native layouts, the Relative Layout lets you define the positions of each child View relative to the others and to the screen boundaries.

-TableLayout: The Table Layout lets you lay out Views using a grid of rows and columns. Tables can span multiple rows and columns, and columns can be set to shrink or grow.

- Gallery: A Gallery Layout displays a single row of items in a horizontally scrolling list.

The Android Widget Toolbox (view)

Android supplies a toolbox of standard Views to help you create simple interfaces. By using these controls (and modifying or extending them as necessary), you can simplify your development and provide consistency between applications.

The following list highlights some of the more familiar toolbox controls:
-TextView: A standard read-only text label. It supports multiline display, string formatting, and automatic word wrapping.
 
-EditText: An editable text entry box. It accepts multiline entry, word-wrapping, and hint text.
 
-ListView: A View Group that creates and manages a vertical list of Views, displaying them as rows within the list. The simplest List View displays the toString value of each object in an array, using a Text View for each item.
 
- Spinner: A composite control that displays a Text View and an associated List View that lets you select an item from a list to display in the textbox. It’s made from a Text View displaying the current selection, combined with a button that displays a selection dialog when pressed.

- Button: A standard push-button.
-CheckBox: A two-state button represented by a checked or unchecked box.
-RadioButton: A two-state grouped button. A group of these presents the user with a number of binary options of which only one can be enabled at a time.

-ViewFlipper: A View Group that lets you define a collection of Views as a horizontal row in which only one View is visible at a time, and in which transitions between visible views are animated.

-QuickContactBadge: Displays a badge showing the image icon assigned to a contact you specify using a phone number, name, e-mail address, or URI. Clicking the image will display the quick contact bar, which provides shortcuts for contacting the selected contact—including calling, sending an SMS, e-mail, and IM.

Android also supports several more advanced View implementations, including date-time pickers, auto-complete input boxes, maps, galleries, and tab sheets.

The Activity Life Cycle

A good understanding of the Activity life cycle is vital to ensure that your application provides a seamless user experience and properly manages its resources.

Android applications do not control their own process lifetimes; the Android run time manages the process of each application, and by extension that of each Activity within it. While the run time handles the termination and management of an Activity’s process, the Activity’s state helps determine the priority of its parent application. The application priority, in turn, influences the likelihood that the run time will terminate it and the Activities running within it.

The state of each Activity is determined by its position on the Activity stack, a last-in–first-out collection of all the currently running Activities. When a new Activity starts, the current foreground screen is moved to the top of the stack. If the user navigates back using the Back button, or the foreground Activity is closed, the next Activity on the stack moves up and becomes active.

Activity States:
As Activities are created and destroyed they move in and out of the stack. As they do so, they transition through four possible states:

-Active When an Activity is at the top of the stack it is the visible, focused, foreground Activity that is receiving user input. Android will attempt to keep it alive at all costs, killing Activities further down the stack as needed, to ensure that it has the resources it needs. When another Activity becomes active, this one will be paused.

-Paused In some cases your Activity will be visible but will not have focus; at this point it’s paused. This state is reached if a transparent or non-full-screen Activity is active in front of it. When paused, an Activity is treated as if it were active; however, it doesn’t receive user input events. In extreme cases Android will kill a paused Activity to recover resources for the active Activity.When an Activity becomes totally obscured, it is stopped.

-Stopped When an Activity isn’t visible, it ‘‘stops.’’ The Activity will remain in memory,retaining all state information; however, it is now a candidate for termination when the system requires memory elsewhere. When an Activity is stopped it’s important to save data and the current UI state. Once an Activity has exited or closed, it becomes inactive.

-Inactive After an Activity has been killed, and before it’s been launched, it’s inactive. Inactive Activities have been removed from the Activity stack and need to be restarted before they can be displayed and used.

Resources in Android

Application resources are stored under the res/ folder of your project hierarchy. In this folder, each of the available resource types can have a subfolder containing its resources.

There are seven primary resource types that have different folders: simple values, drawables, layouts, animations, XML, styles, and raw resources.

This process also creates an R class file that contains references to each of the resources you include in your project. This lets you reference the resources in your code, with the advantage of design time syntax checking.

In all cases, the resource file-names should contain only lowercase letters, numbers, and the period (.) and underscore (_) symbols.

1) Simple Values:
Supported simple values include strings, colors, dimensions, and string or integer arrays. All simple values are stored within XML files in the res/values folder.

<?xml version="1.0" encoding="utf-8"?>
<resources>
<string name="app_name">To Do List</string>
<color name="app_background">#FF0000FF</color>
<dimen name="default_border">5px</dimen>
<array name="string_array">
<item>Item 1</item>
<item>Item 2</item>
<item>Item 3</item>
</array>
<array name="integer_array">
<item>3</item>
<item>2</item>
<item>1</item>
</array>
</resources>


Dimensions are most commonly referenced within style and layout resources. They’re useful for creating layout constants such as borders and font heights. To specify a dimension resource use the <dimen> tag, specifying the dimension value, followed by an identifier describing the scale of your dimension:

px (screen pixels), in (physical inches), pt (physical points), mm (physical millimeters), dp (density-independent pixels relative to a 160-dpi screen), sp (scale-independent pixels)

Styles and Themes:
Style resources let your applications maintain a consistent look and feel by enabling you to specify the
attribute values used by Views. The most common use of themes and styles is to store the colors and
fonts for an application.

<?xml version="1.0" encoding="utf-8"?>
<resources>
<style name="BaseText">
<item name="android:textSize">14sp</item>
<item name="android:textColor">#111</item>
</style>
<style name="SmallText" parent="BaseText">
<item name="android:textSize">8sp</item>
</style>
</resources>

Drawables:
Drawable resources include bitmaps and NinePatch (stretchable PNG) images. They also include complex composite Drawables, such as LevelListDrawables and StateListDrawables that can be defined in XML. 


Layouts:
Layout resources let you decouple your presentation layer by designing user interface layouts in XML rather than constructing them in code. The most common use of a layout is for defining the user interface for an Activity. Once defined in XML, the layout is ‘‘inflated’’ within an Activity using setContentView, usually within the onCreate method.


<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent">
<TextView android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text="Hello World!"/>
</LinearLayout>


Animations:
Android supports two types of animation. Tweened animations can be used to rotate, move, stretch and fade a View; or you can create frame-by-frame animations to display a sequence of Drawable images.

Tweened animation is stored in a separate XML file in the project’s res/anim folder. An animation can be defined for changes in alpha (fading), scale (scaling), translate (movement), or rotate (rotation).

Frame-by-frame animations let you create a sequence of Drawables, each of which will be displayed for a specified duration, on the background of a View.

Menus:
Create menu resources to further decouple your presentation layer by designing your menu layouts in XML rather than constructing them in code. Menu resources can be used to define both Activity and context menus within your applications, and provide the same options you would have when constructing your menus in code. Once defined in XML, a menu is ‘‘inflated’’ within your application via the inflate method of the MenuInflator Service, usually within the onCreateOptionsMenu method.

The Android Application Life Cycle

Unlike most traditional environments, Android applications have no control over their own life cycles.Instead, application components must listen for changes in the application state and react accordingly,taking particular care to be prepared for untimely termination.

The order in which processes are killed to reclaim resources is determined by the priority of the hosted applications. An application’s priority is equal to its highest-priority component.Where two applications have the same priority, the process that has been at a lower priority longest will be killed first. Process priority is also affected by interprocess dependencies; if an application has a dependency on a Service or Content Provider supplied by a second application, the secondary application will have at least as high a priority as the application it supports.

All Android applications will remain running and in memory until the system needs its resources for other applications.

Active Processes: Active (foreground) processes are those hosting applications with components currently interacting with the user. These are the processes Android is trying to keep responsive by reclaiming resources. There are generally very few of these processes, and they will be killed only as a last resort.

Active processes include:
- Activities in an “active” state; that is, they are in the foreground and responding to user events.
- Activities, Services, or Broadcast Receivers that are currently executing an onReceive event handler.
- Services that are executing an onStart, onCreate, or onDestroy event handler.

-Visible Processes: Visible, but inactive processes are those hosting “visible” Activities. As the name suggests, visible Activities are visible, but they aren’t in the foreground or responding to user events. This happens when an Activity is only partially obscured (by a non-full-screen or transparent Activity). There are generally very few visible processes, and they’ll only be killed in extreme circumstances to allow active processes to continue.

- Started Service Processes: Processes hosting Services that have been started. Services support ongoing processing that should continue without a visible interface. Because Services don’t interact directly with the user, they receive a slightly lower priority than visible Activities. They are still considered to be foreground processes and won’t be killed unless resources are needed for active or visible processes.

- Background Processes: Processes hosting Activities that aren’t visible and that don’t have any Services that have been started are considered background processes. There will generally be a large number of background processes that Android will kill using a last-seen-first-killed pattern to obtain resources for foreground processes.

-Empty Processes: To improve overall system performance, Android often retains applications in memory after they have reached the end of their lifetimes. Android maintains this cache to improve the start-up time of applications when they’re re-launched. These processes are routinely killed as required.

 ------------------------------------------------------------------------------------------------

The Application class also provides event handlers for application creation and termination, low available memory, and configuration changes. By overriding these methods you can implement your own application-specific behavior for each of these circumstances:
 
- onCreate Called when the application is created. Override this method to initialize your application singleton and create and initialize any application state variables or shared resources.

- onTerminate: Can be called when the application object is terminated. Note that there is no guarantee of this method handler’s being called. If the application is terminated by the kernel in order to free resources for other applications, the process will be terminated without warning and without a call to the application object’s onTerminate handler.

- onLowMemory: Provides an opportunity for well-behaved applications to free additional memory when the system is running low on resources. This will generally only be called when background processes have already been terminated and the current foreground applications are still low on memory. Override this handler to clear caches or release unnecessary resources.

- onConfigurationChanged: Unlike with Activities, your application object is not killed and restarted for configuration changes. Override this handler if it is necessary to handle configuration changes at an application level.

Android Application components

Android applications consist of loosely coupled components, bound using a project manifest that describes each component and how they interact.

There are six components that provide the building blocks for your applications:

- Activities: Your application’s presentation layer. Every screen in your application will be an extension of the Activity class. Activities use Views to form graphical user interfaces that display information and respond to user actions. In terms of desktop development, an Activity is equivalent to a Form.
 
-Services: The invisible workers of your application. Service components run invisibly, updating your data sources and visible Activities and triggering Notifi cations. They’re used to perform regular processing that needs to continue even when your application’s Activities aren’t active or visible.

- Content Providers: A shareable data store. Content Providers are used to manage and share application databases. Content Providers are the preferred way of sharing data across application boundaries. This means that you can confi gure your own Content Providers to permit access from other applications and use Content Providers exposed by others to access their stored data. Android devices include several native Content Providers that expose useful databases like contact information.

- Intents: A simple message-passing framework. Using Intents, you can broadcast messages system-wide or to a target Activity or Service, stating your intention to have an action performed. The system will then determine the target(s) that will perform any actions as appropriate.

- Broadcast Receivers: Intent broadcast consumers. By creating and registering a Broadcast Receiver, your application can listen for broadcast Intents that match specifi c fi lter criteria. Broadcast Receivers will automatically start your application to respond to an incoming Intent, making them ideal for event-driven applications.

- Notifications: A user notifi cation framework. Notifi cations let you signal users without stealing focus or interrupting their current Activities. They’re the preferred technique for getting a user’s attention from within a Service or Broadcast Receiver. For example, when a device receives a text message or an incoming call, it alerts you by fl ashing lights, making sounds, displaying icons, or showing dialog messages. You can trigger these same events from your own applications using Notifications.

By decoupling the dependencies between application components, you can share and interchange
individual pieces, such as Content Providers or Services, with other applications — both your own and
those of third parties.

Hardware-Imposed Design Restrictions

Compared to desktop or notebook computers, mobile devices have relatively:
- Low processing power
- Limited RAM
- Limited permanent storage capacity
- Small screens with low resolution
- Higher costs associated with data transfer
- Slower data transfer rates with higher latency
- Less reliable data connections
- Limited battery life

It’s important to keep these restrictions in mind when creating new applications.

Types of Android Applications

Most of the applications you create in Android will fall into one of the following categories:

- Foreground Activity: An application that’s only useful when it’s in the foreground and is effectively suspended when it’s not visible. Games and map mashups are common examples.

- Background Service: An application with limited interaction that, apart from when being configured, spends most of its lifetime hidden. Examples of this include call screening applications or SMS auto-responders.

- Intermittent Activity: Expects some interactivity but does most of its work in the background. Often these applications will be set up and then run silently, notifying users when appropriate. A common example would be a media player.

Complex applications are difficult to put into a single category and can include elements of all three. When creating your application, you need to consider how it’s likely to be used and then design it accordingly.

The ADT Plug-in

The ADT plug-in for Eclipse simplifies your Android development by integrating the developer tools, including the emulator and .class-to-.dex converter, directly into the IDE. While you don’t have to use the ADT plug-in, it does make creating, testing, and debugging your applications faster and easier.

The ADT plug-in integrates the following into Eclipse:
-An Android Project Wizard that simplifies creating new projects and includes a basic application template.
-Forms-based manifest, layout, and resource editors to help create, edit, and validate your XML resources.
-Automated building of Android projects, conversion to Android executables (.dex), packaging to package fi les (.apk), and installation of packages onto Dalvik virtual machines.
- The Android Emulator, including control of the emulator’s appearance, network connection settings, and the ability to simulate incoming calls and SMS messages.
 - The Dalvik Debug Monitoring Service (DDMS), which includes port forwarding; stack, heap, and thread viewing; process details; and screen capture facilities.
- Access to the device or emulator’s filesystem, allowing you to navigate the folder tree and transfer files
- Runtime debugging, so you can set breakpoints and view call stacks
- All Android/Dalvik log and console outputs

If you’re using the ADT plug-in, running or debugging your application:
- Compiles the current project and converts it to an Android executable (.dex).
- Packages the executable and external resources into an Android package (.apk).
- Starts the emulator (if it’s not already running).
- Installs your application onto the emulator.
- Starts your application.

If you’re debugging, the Eclipse debugger will then be attached, allowing you to set breakpoints and debug your code.

ADT Tools from DDMS perspective:

-The Android Emulator: An implementation of the Android virtual machine designed to run on your development computer. You can use the emulator to test and debug your android applications.
- Dalvik Debug Monitoring Service (DDMS): Use the DDMS perspective to monitor and control the Dalvik virtual machines on which you’re debugging your applications.
- Android Asset Packaging Tool (AAPT): Constructs the distributable Android package files (.apk).
- Android Debug Bridge (ADB): The ADB is a client-server application that provides a link to a running emulator. It lets you copy files, install compiled application packages (.apk), and run shell commands.

-SQLite3: A database tool that you can use to access the SQLite database fi les created and used by Android.
-Traceview: Graphical analysis tool for viewing the trace logs from your Android application
-MkSDCard: Creates an SDCard disk image that can be used by the emulator to simulate an external storage card.
 dx Converts Java .class bytecode into Android .dex bytecode.
- activityCreator: Script that builds Ant build fi les that you can then use to compile your Android applications without the ADT plug-in.

The Android Application Architecture

Android’s architecture encourages the concept of component reuse, allowing you to publish and share activities, services, and data with other applications with access managed by the security restrictions you put in place.

The same mechanism that lets you produce a replacement contact manager or phone dialer can let you expose your application components to let other developers create new UI front ends and functionality extensions, or otherwise build on them.

The following application services are the architectural cornerstones of all Android applications, providing the framework you’ll be using for your own software:

- Activity Manager: Controls the life cycle of your activities, including management of the activity stack.

-Views Are used to construct the user interfaces for your activities.

- Notification Manager: Provides a consistent and non-intrusive mechanism for signaling your users.

- Content Providers: Lets your applications share data between applications.

- Resource Manager: Supports non-code resources like strings and graphics to be externalized.

The Android Software Stack

The Android software stack is composed of the elements shown in the figure . Put simply, a Linux kernel and a collection of C/C++ libraries are exposed through an application framework that provides services for, and management of, the run time and applications.

Linux Kernel: Core services (including hardware drivers, process and memory management, security, network, and power management) are handled by a Linux 2.6 kernel. The kernel also provides an abstraction layer between the hardware and the remainder of the stack.

Libraries: Running on top of the kernel, Android includes various C/C++ core libraries such
as libc and SSL, as well as:
-❑ A media library for playback of audio and video media
-❑ A Surface manager to provide display management
-❑ Graphics libraries that include SGL and OpenGL for 2D and 3D graphics
-❑ SQLite for native database support
-❑ SSL and WebKit for integrated web browser and Internet security

Android Run Time: What makes an Android phone an Android phone rather than a mobile is the Linux implementation is the Android run time. Including the core libraries and the Dalvik virtual machine, the Android run time is the engine that powers your applications and, along with the libraries, forms the basis for the application framework.

-Core Libraries: While Android development is done in Java, Dalvik is not a Java VM.
The core Android libraries provide most of the functionality available in the core Java
libraries as well as the Android-specifi c libraries.

Dalvik Virtual Machine: Dalvik is a register-based virtual machine that’s been optimized to ensure that a device can run multiple instances efficiently. It relies on the Linux kernel for threading and low-level memory management.

 Application Framework: The application framework provides the classes used to create Android applications. It also provides a generic abstraction for hardware access and manages the user interface and application resources.

Application Layer: All applications, both native and third party, are built on the application layer using the same API libraries. The application layer runs within the Android run time using the classes and services made available from the application framework.

What Does Android Have That Others Don’t?

Here are some of the unique features that set Android apart:

- Google Map Applications: Google Maps for Mobile has been hugely popular, and Android offers a Google Map as an atomic, reusable control for use in your applications. The MapView widget lets you display, manipulate, and annotate a Google Map within your Activities to build map-based applications using the familiar Google Maps interface

- Background Services and Applications: Background services let you create applications that use an event-driven model, working silently while other applications are being used or while your mobile sits ignored until it rings, flashes, or vibrates to get your attention. Maybe it’s an application that tracks the stock market, alerting you to significant changes in your portfolio, or a service that changes your ring tone or volume depending on your current location, the time of day, and the identity of the caller.

- Shared Data and Interprocess Communication: Using Intents and Content Providers, Android lets your applications exchange messages, perform processing, and share data. You can also use these mechanisms to leverage the data and functionality provided by the native Android applications. To mitigate the risks of such an open strategy, each application’s process, data storage, and files are private unless explicitly shared with other applications using a full permission-based security mechanism.

- All Applications Are Created Equal: Android doesn’t differentiate between native applications and those developed by third parties. This gives consumers unprecedented power to change the look and feel of their devices by letting them completely replace every native application with a third-party alternative that has access to the same underlying data and hardware.Every rule needs an exception and this one has two. The “unlock” and “in-call experience”screens can not be replaced in the initial SDK release.

- P2P Interdevice Application Messaging: Android offers peer-to-peer messaging that supports presence, instant messaging, and interdevice/interapplication communication.

Native Android Applications

Android is a software stack for mobile devices that includes an operating system, middleware and key applications.Google Inc. purchased the initial developer of the software, Android Inc., in 2005.Android's mobile operating system is based on the Linux kernel. Google and other members of the Open Handset Alliance collaborated on Android's development and release.

The names of the first Android operating system since its launch from the Cupcake (Android 1.5),Donut (Android 1.6), Eclair (Android 2.1), Froyo (Android 2.2), Gingerbread (Android 2.3), and special tablets OS, Honeycomb (Android 3.0.) & Ice Cream Sandwich(Android 4.0), Jelly Bean (Android 4.1) , Kitkat (Android 4.4), Lollipop (Android 5.X), Marshmallow (Android 6.X), Nougat (Android 7.X) and Oreo (Android 8).

Native Android Applications:
Android phones will normally come with a suite of preinstalled applications including, but not limited to:
-❑ An e-mail client compatible with Gmail but not limited to it
-❑ An SMS management application
-❑ A full PIM (personal information management) suite including a calendar and contacts list, both
tightly integrated with Google’s online services
-A fully featured mobile Google Maps application including StreetView, business finder, driving
directions, satellite view, and traffic conditions
-❑ A WebKit-based web browser
-❑ An Instant Messaging Client
-❑ A music player and picture viewer
-❑ The Android Marketplace client for downloading third-party Android applications.
-❑ The Amazon MP3 store client for purchasing DRM free music.

All the native applications are written in Java using the Android SDK and are run on Dalvik. The data stored and used by the native applications — like contact details — are also available to third party applications. Similarly, your applications can handle events such as an incoming call or a new SMS message.