High-level classes encapsulating the overall Android application model. The central class is Activity, with other top-level application components being defined by Service and, from the android.content package, BroadcastReceiver and ContentProvider. It also includes application tools, such as dialogs and notifications.
This package builds on top of the lower-level Android packages android.widget, android.view, android.content, android.text, android.graphics, android.os, and android.util.
An Activity is a specific operation the user can perform, generally corresponding to one screen in the user interface. It is the basic building block of an Android application. Examples of activities are "view the list of people," "view the details of a person," "edit information about a person," "view an image," etc. Switching from one activity to another generally implies adding a new entry on the navigation history; that is, going "back" means moving to the previous activity you were doing.
A set of related activities can be grouped together as a "task". Until a new task is explicitly specified, all activites you start are considered to be part of the current task. While the only way to navigate between individual activities is by going "back" in the history stack, the group of activities in a task can be moved in relation to other tasks: for example to the front or the back of the history stack. This mechanism can be used to present to the user a list of things they have been doing, moving between them without disrupting previous work.
A complete "application" is a set of activities that allow the user to do a cohesive group of operations -- such as working with contacts, working with a calendar, messaging, etc. Though there can be a custom application object associated with a set of activities, in many cases this is not needed -- each activity provides a particular path into one of the various kinds of functionality inside of the application, serving as its on self-contained "mini application".
This approach allows an application to be broken into pieces, which can be reused and replaced in a variety of ways. Consider, for example, a "camera application." There are a number of things this application must do, each of which is provided by a separate activity: take a picture (creating a new image), browse through the existing images, display a specific image, etc. If the "contacts application" then wants to let the user associate an image with a person, it can simply launch the existing "take a picture" or "select an image" activity that is part of the camera application and attach the picture it gets back.
Note that there is no hard relationship between tasks the user sees and applications the developer writes. A task can be composed of activities from multiple applications (such as the contact application using an activity in the camera application to get a picture for a person), and multiple active tasks may be running for the same application (such as editing e-mail messages to two different people). The way tasks are organized is purely a UI policy decided by the system; for example, typically a new task is started when the user goes to the application launcher and selects an application.
