From e04c4543027df129cd7c004c1b21b01a7f4928ad Mon Sep 17 00:00:00 2001
From: Scott Main
Action buttons on the action bar surface your app's most important activities. Think about which
buttons will get used most often, and order them accordingly. Depending on available screen real
estate, the system shows your most important actions as action buttons and moves the rest to the
diff --git a/docs/html/design/patterns/navigation.jd b/docs/html/design/patterns/navigation.jd
index 4da87b9..6f2215a 100644
--- a/docs/html/design/patterns/navigation.jd
+++ b/docs/html/design/patterns/navigation.jd
@@ -1,5 +1,5 @@
page.title=Navigation with Back and Up
-page.tags="navigation","activity","task"
+page.tags="navigation","activity","task","up navigation","back navigation"
@jd:body
diff --git a/docs/html/guide/topics/manifest/activity-element.jd b/docs/html/guide/topics/manifest/activity-element.jd
index adc795d..8df1fdf 100644
--- a/docs/html/guide/topics/manifest/activity-element.jd
+++ b/docs/html/guide/topics/manifest/activity-element.jd
@@ -54,85 +54,85 @@ parent.link=manifest-intro.html
-If this attribute is not set, the value set by the corresponding
+If this attribute is not set, the value set by the corresponding
-Normally when an activity is started, it's associated with the task of
-the activity that started it and it stays there for its entire lifetime.
-You can use this attribute to force it to be re-parented to the task it
-has an affinity for when its current task is no longer displayed.
-Typically, it's used to cause the activities of an application to move
+Normally when an activity is started, it's associated with the task of
+the activity that started it and it stays there for its entire lifetime.
+You can use this attribute to force it to be re-parented to the task it
+has an affinity for when its current task is no longer displayed.
+Typically, it's used to cause the activities of an application to move
to the main task associated with that application.
-For example, if an e-mail message contains a link to a web page, clicking
-the link brings up an activity that can display the page. That activity
-is defined by the browser application, but is launched as part of the e-mail
-task. If it's reparented to the browser task, it will be shown when the
-browser next comes to the front, and will be absent when the e-mail task
+For example, if an e-mail message contains a link to a web page, clicking
+the link brings up an activity that can display the page. That activity
+is defined by the browser application, but is launched as part of the e-mail
+task. If it's reparented to the browser task, it will be shown when the
+browser next comes to the front, and will be absent when the e-mail task
again comes forward.
-The affinity of an activity is defined by the
-
-Normally, the system clears a task (removes all activities from the stack
-above the root activity) in certain situations when the user re-selects that
-task from the home screen. Typically, this is done if the user hasn't visited
+Normally, the system clears a task (removes all activities from the stack
+above the root activity) in certain situations when the user re-selects that
+task from the home screen. Typically, this is done if the user hasn't visited
the task for a certain amount of time, such as 30 minutes.
-However, when this attribute is "{@code true}", users will always return
-to the task in its last state, regardless of how they get there. This is
-useful, for example, in an application like the web browser where there is
+However, when this attribute is "{@code true}", users will always return
+to the task in its last state, regardless of how they get there. This is
+useful, for example, in an application like the web browser where there is
a lot of state (such as multiple open tabs) that users would not like to lose.
@@ -140,24 +140,24 @@ When the value is "{@code true}", every time users start the task again, they
are brought to its root activity regardless of what they were last doing in
the task and regardless of whether they used the Back or Home button to
leave it. When the value is "{@code false}", the task may be cleared of activities in
-some situations (see the
-
-Suppose, for example, that someone launches activity P from the home screen,
-and from there goes to activity Q. The user next presses Home, and then returns
-to activity P. Normally, the user would see activity Q, since that is what they
-were last doing in P's task. However, if P set this flag to "{@code true}", all
-of the activities on top of it (Q in this case) were removed when the user pressed
-Home and the task went to the background. So the user sees only P when returning
+Suppose, for example, that someone launches activity P from the home screen,
+and from there goes to activity Q. The user next presses Home, and then returns
+to activity P. Normally, the user would see activity Q, since that is what they
+were last doing in P's task. However, if P set this flag to "{@code true}", all
+of the activities on top of it (Q in this case) were removed when the user pressed
+Home and the task went to the background. So the user sees only P when returning
to the task.
-If this attribute and Note: Using this attribute should be
-avoided and used only as a last-resort. Please read Handling Runtime Changes for more
information about how to properly handle a restart due to a configuration change. Note: If your application targets API level 13 or higher (as
declared by the {@code
minSdkVersion} and {@code
@@ -258,70 +258,70 @@ restart your activity, even when running on an Android 3.2 or higher device).
-All of these configuration changes can impact the resource values seen by the
-application. Therefore, when
-The
-The default value depends on whether the activity contains intent filters. The
-absence of any filters means that the activity can be invoked only by specifying
-its exact class name. This implies that the activity is intended only for
-application-internal use (since others would not know the class name). So in
+The default value depends on whether the activity contains intent filters. The
+absence of any filters means that the activity can be invoked only by specifying
+its exact class name. This implies that the activity is intended only for
+application-internal use (since others would not know the class name). So in
this case, the default value is "{@code false}".
-On the other hand, the presence of at least one filter implies that the activity
+On the other hand, the presence of at least one filter implies that the activity
is intended for external use, so the default value is "{@code true}".
This attribute is not the only way to limit an activity's exposure to other
-applications. You can also use a permission to limit the external entities that
-can invoke the activity (see the
-
-If this attribute and
-
-This attribute must be set as a reference to a drawable resource containing
-the image definition. If it is not set, the icon specified for the application
-as a whole is used instead (see the
-
-The activity's icon — whether set here or by the
-
-If this attribute is not set, the label set for the application as a whole is
-used instead (see the
-The activity's label — whether set here or by the
-
The label should be set as a reference to a string resource, so that
-it can be localized like other strings in the user interface.
-However, as a convenience while you're developing the application,
+it can be localized like other strings in the user interface.
+However, as a convenience while you're developing the application,
it can also be set as a raw string.
-The "{@code standard}" and "{@code singleTop}" modes differ from each other
+The "{@code standard}" and "{@code singleTop}" modes differ from each other
in just one respect: Every time there's a new intent for a "{@code standard}"
activity, a new instance of the class is created to respond to that intent.
Each instance handles a single intent.
@@ -509,41 +509,41 @@ common and useful launch mode for many types of activities. The other modes
— Regardless of the launch mode that you choose, make sure to test the usability
of the activity during launch and when navigating back to it from
other activities and tasks using the Back button. For more information on launch modes and their interaction with Intent
-flags, see the
+flags, see the
Tasks and Back Stack
document.
-Normally, a new instance of an activity is launched into the process of the
-application that defined it, so all instances of the activity run in the same
-process. However, if this flag is set to "{@code true}", instances of the
-activity can run in multiple processes, allowing the system to create instances
-wherever they are used (provided permissions allow it), something that is almost
+Normally, a new instance of an activity is launched into the process of the
+application that defined it, so all instances of the activity run in the same
+process. However, if this flag is set to "{@code true}", instances of the
+activity can run in multiple processes, allowing the system to create instances
+wherever they are used (provided permissions allow it), something that is almost
never necessary or desirable.
Once you publish your application, you should not
@@ -557,9 +557,9 @@ There is no default. The name must be specified.
@@ -575,14 +575,33 @@ This attribute was introduced in API Level 3.
The system reads this attribute to determine which activity should be started when
the use presses the Up button in the action bar. The system can also use this information to
synthesize a back stack of activities with {@link android.app.TaskStackBuilder}. To support API levels 4 - 16, you can also declare the parent activity with a {@code
+<meta-data>} element that specifies a value for {@code "android.support.PARENT_ACTIVITY"}.
+For example: For more information about declaring the parent activity to support Up navigation,
+read Providing Up
+Navigation.
This attribute was introduced in API Level 16.
-If this attribute is not set, the permission set by the
-
-For more information on permissions, see the
-Permissions
-section in the introduction and another document,
+For more information on permissions, see the
+Permissions
+section in the introduction and another document,
Security and
Permissions.
-If the name assigned to this attribute begins with a colon (':'), a new
-process, private to the application, is created when it's needed and
+If the name assigned to this attribute begins with a colon (':'), a new
+process, private to the application, is created when it's needed and
the activity runs in that process.
-If the process name begins with a lowercase character, the activity will run
+If the process name begins with a lowercase character, the activity will run
in a global process of that name, provided that it has permission to do so.
-This allows components in different applications to share a process, reducing
+This allows components in different applications to share a process, reducing
resource usage.
- The The value can be any one of the following strings:
-Normally, before an activity is temporarily shut down to save resources, its
-
-A "{@code true}" setting ensures that the activity can be restarted in the
-absence of retained state. For example, the activity that displays the
-home screen uses this setting to make sure that it does not get removed if it
+A "{@code true}" setting ensures that the activity can be restarted in the
+absence of retained state. For example, the activity that displays the
+home screen uses this setting to make sure that it does not get removed if it
crashes for some reason.
-The affinity determines two things — the task that the activity is re-parented
-to (see the
By default, all activities in an application have the same affinity. You
can set this attribute to group them differently, and even place
-activities defined in different applications within the same task. To
+activities defined in different applications within the same task. To
specify that the activity does not have an affinity for any task, set
it to an empty string.
-If this attribute is not set, the activity inherits the affinity set
-for the application (see the
-
-If this attribute is not set, the activity inherits the theme set for the
-application as a whole — from the
-
-The setting must be one of the values listed in the following table, or a
-combination of one "{@code state...}" value plus one "{@code adjust...}"
-value. Setting multiple values in either group — multiple
-"{@code state...}" values, for example — has undefined results.
+The setting must be one of the values listed in the following table, or a
+combination of one "{@code state...}" value plus one "{@code adjust...}"
+value. Setting multiple values in either group — multiple
+"{@code state...}" values, for example — has undefined results.
Individual values are separated by a vertical bar ({@code |}). For example:
-Values set here (other than "{@code stateUnspecified}" and
+Values set here (other than "{@code stateUnspecified}" and
"{@code adjustUnspecified}") override values set in the theme.
This is the default setting for the behavior of the soft keyboard.
@@ -885,32 +908,32 @@ Values set here (other than "{@code stateUnspecified}" and
whether visible or hidden, when the activity comes to the fore.
@@ -918,14 +941,14 @@ Values set here (other than "{@code stateUnspecified}" and
Action Bar The action bar is a window feature that identifies the application and user location, and
-provides user actions and navigation modes. You should use the action bar in most activities that
-need to prominently present user actions or global navigation, because the action bar offers users a
-consistent interface across applications and the system gracefully adapts the action bar's
-appearance for different screen configurations. You can control the behaviors and visibility of the
-action bar with the {@link android.app.ActionBar} APIs, which were added in Android 3.0 (API level
-11). The action bar is a window feature that identifies the user location, and
+provides user actions and navigation modes. Using the action bar offers your users a
+familiar interface across applications that the system gracefully adapts
+for different screen configurations. The primary goals of the action bar are to: This is accomplished with the app icon or logo on the left side and the activity title.
-You might choose to remove the activity title, however, if the current view is identified by a
-navigation label, such as the currently selected tab. The action bar provides built-in tab navigation for switching between fragments. It also offers a drop-down
-list you can use as an alternative navigation mode or to refine the current view (such as to sort
-a list by different criteria). The action bar provides several key functions: You can provide instant access to key user actions by placing items from the options menu directly in the action bar,
-as "action items." Action items can also provide an "action view," which provides an embedded
-widget for even more immediate action behaviors. Menu items that are not promoted
-to an action item are available in the overflow menu, revealed by either the device Menu
-button
-(when available) or by an "overflow menu" button in the action bar (when the device does not
-include a Menu button). For more information about the action bar's interaction patterns and design guidelines,
+see the Action Bar
+design guide. Note: If you're looking for information about the contextual
-action bar for displaying contextual action items, see the Menu guide. The {@link android.app.ActionBar} APIs were first added in Android 3.0 (API level 11) but they
+are also available in the Support Library
+for compatibility with Android 2.2 (API level 7) and above. This guide focuses on how to use the
+support library's action bar, but if your app supports only Android 3.0 or higher, you
+should use the {@link android.app.ActionBar} APIs in the framework. Most of the APIs are
+the same—but reside in a different package namespace—with a few exceptions to method
+names or signatures that are noted in the sections below. Action Bar Design For design guidelines, read Android Design's Action Bar guide. Caution: Be certain you import
+the {@code ActionBar} class (and related APIs) from the appropriate package: Note: If you're looking for information about the contextual
+action bar for displaying contextual action items, see the Menu guide. If you want to provide an action bar in your application and remain compatible with
-versions of Android older than 3.0, you need to create the action bar in your
-activity's layout (because the {@link android.app.ActionBar} class is not available on older
-versions). To help you, the Action Bar Compatibility sample
-app provides an API layer and action bar layout that allows your app to use some of the {@link
-android.app.ActionBar} APIs and also support older versions of Android by replacing the traditional
-title bar with a custom action bar layout. Beginning with Android 3.0 (API level 11), the action bar is included in all
-activities that use the {@link android.R.style#Theme_Holo Theme.Holo} theme (or one of its
-descendants), which is the default theme when either the {@code targetSdkVersion} or
-{@code minSdkVersion}
-attribute is set to {@code "11"} or greater. For example: As mentioned above, this guide focuses on how to use the {@link
+android.support.v7.app.ActionBar} APIs in the support library. So before you can add the action
+bar, you must set up your project with the appcompat v7 support library by
+following the instructions in the Support
+Library Setup. Once your project is set up with the support library, here's how to add the action bar: In this example, the application requires a minimum version of API Level 4 (Android 1.6), but it
-also targets API level 11 (Android 3.0). This way, when the application runs on Android 3.0 or
-greater, the system applies the holographic theme to each activity, and thus, each activity includes
-the action bar. Now your activity includes the action bar when running on Android 2.2 (API level 7) or higher.
+ If you want to use {@link android.app.ActionBar} APIs, such as to add navigation modes and modify
-action bar styles, you should set the {@code minSdkVersion} to {@code
-"11"} or greater. If you want your app
-to support older versions of Android, there are ways to use a limited set of {@link
-android.app.ActionBar} APIs on devices that support API level 11 or higher, while still running
-on older versions. See the sidebox for information about remaining backward-compatible. On API level 11 or higher The action bar is included in all activities that use the
+{@link android.R.style#Theme_Holo Theme.Holo} theme (or one of its
+descendants), which is the default theme when either the {@code targetSdkVersion} or
+{@code minSdkVersion}
+attribute is set to {@code "11"} or higher. If you don't want the action bar for an
+activity, set the activity theme to {@link android.R.style#Theme_Holo_NoActionBar
+Theme.Holo.NoActionBar}. If you don't want the action bar for a particular activity, set the activity theme to
-{@link android.R.style#Theme_Holo_NoActionBar Theme.Holo.NoActionBar}. For example: You can also hide the action bar at runtime by calling {@link android.app.ActionBar#hide}. For
-example: You can hide the action bar at runtime by calling {@link android.support.v7.app.ActionBar#hide}.
+For example: When the action bar hides, the system adjusts your activity layout to fill all the
-screen space now available. You can bring the action bar back with {@link
-android.app.ActionBar#show()}. On API level 11 or higher Get the {@link android.app.ActionBar} with the {@link android.app.Activity#getActionBar}
+method. When the action bar hides, the system adjusts your layout to fill the
+screen space now available. You can bring the action bar back by calling {@link
+android.support.v7.app.ActionBar#show()}. Beware that hiding and removing the action bar causes your activity to re-layout in order to
-account for the space consumed by the action bar. If your activity regularly hides and shows the
-action bar (such as in the Android Gallery app), you might want to use overlay mode. Overlay mode
-draws the action bar on top of your activity layout rather than in its own area of the screen. This
+account for the space consumed by the action bar. If your activity often hides and shows the
+action bar, you might want to enable overlay mode. Overlay mode
+draws the action bar in front of your activity layout, obscuring the top portion. This
way, your layout remains fixed when the action bar hides and re-appears. To enable overlay mode,
-create a theme for your activity and set {@link android.R.attr#windowActionBarOverlay
-android:windowActionBarOverlay} to {@code true}. For more information, see the section about Styling the Action Bar. Tip: If you have a custom activity theme in which you'd like to
-remove the action bar, set the {@link android.R.styleable#Theme_windowActionBar
-android:windowActionBar} style property to {@code false}. However, if you remove the action bar
-using a theme, then the window will not allow the action bar at all, so you cannot add it
-later—calling {@link android.app.Activity#getActionBar()} will return null. By default, the system uses your application icon in the action bar, as specified by the {@code icon}
+attribute in the {@code
+<application>} or {@code
+<activity>} element. However, if you also specify the {@code logo}
+attribute, then the action bar uses the logo image instead of the icon. A logo should usually be wider than the icon, but should not include unnecessary text. You
+should generally use a logo only when it represents your brand in a traditional format that users
+recognize. A good example is the YouTube app's logo—the logo represents the expected user
+brand, whereas the app's icon is a modified version that conforms to the square requirement
+for the launcher icon. Sometimes you might want to give users immediate access to an item from the options menu. To do this, you can
-declare that the menu item should appear in the action bar as an "action item." An action item can
-include an icon and/or a text title. If a menu item does not appear as an action item, then the
-system places it in the overflow menu. The overflow menu is revealed either by the device
-Menu
-button (if provided by the device) or an additional button in the action bar (if the device does not
-provide the Menu button). When the activity first starts, the system populates the action bar and overflow menu by calling
-{@link android.app.Activity#onCreateOptionsMenu onCreateOptionsMenu()} for your activity. As
-discussed in the Menus developer guide, it's in
-this callback method that you should inflate an XML menu resource that defines the
-menu items. For example: The action bar provides users access to the most important action
+items relating to the app's current
+context. Those that appear directly in the action bar with an icon and/or text are known
+as action buttons. Actions that can't fit in the action bar or aren't
+important enough are hidden in the action overflow.
+The user can reveal a list of the other actions by pressing the overflow button
+on the right side (or the device Menu button, if available). When your activity starts, the system populates the action items by calling your activity's
+{@link android.app.Activity#onCreateOptionsMenu onCreateOptionsMenu()} method. Use this
+method to inflate a menu resource that defines all the
+action items. For example, here's a menu resource defining a couple of menu items: Then in your activity's {@link android.app.Activity#onCreateOptionsMenu onCreateOptionsMenu()}
+method, inflate the menu resource into the given {@link android.view.Menu}
+to add each item to the action bar: In the XML file, you can request a menu item to appear as an action item by declaring {@code
-android:showAsAction="ifRoom"} for the {@code <item>} element. This way, the menu item appears
-in the action bar for quick access only if there is room available. If there's not
-enough room, the item appears in the overflow menu. To request that an item appear directly in the action bar
+as an action button, include {@code
+showAsAction="ifRoom"} in the {@code <item>} tag. For example: If your menu item supplies both a title and an icon—with the {@code android:title} and
-{@code android:icon} attributes—then the action item shows only the icon by default. If you
-want to display the text title, add {@code "withText"} to the {@code android:showAsAction}
+ If there's not enough room for the item in the action bar, it will appear in the action
+overflow. Using XML attributes from the support library If your menu item supplies both a title and an icon—with the {@code title} and
+{@code icon} attributes—then the action item shows only the icon by default. If you
+want to display the text title, add {@code "withText"} to the {@code showAsAction}
attribute. For example: Note: The {@code "withText"} value is a hint to the
action bar that the text title should appear. The action bar will show the title when possible, but
might not if an icon is available and the action bar is constrained for space. When the user selects an action item, your activity receives a call to
-{@link android.app.Activity#onOptionsItemSelected(MenuItem)
-onOptionsItemSelected()}, passing the ID supplied by the {@code android:id} attribute—the same
-callback received for all items in the options menu. It's important that you always define {@code android:title} for each menu item—even if you
-don't declare that the title appear with the action item—for three reasons: You should always define the {@code title} for each item even if you don't declare that
+the title appear with the action item, for the following reasons: The {@code android:icon} is always optional, but recommended. For icon design recommendations,
-see the Action Bar
-Icon design guidelines. Note: If you added the menu item from a fragment, via the {@link
-android.app.Fragment} class's {@link android.app.Fragment#onCreateOptionsMenu onCreateOptionsMenu}
-callback, then the system calls the respective {@link
-android.app.Fragment#onOptionsItemSelected(MenuItem) onOptionsItemSelected()} method for that
-fragment when the user selects one of the fragment's items. However the activity gets a chance to
-handle the event first, so the system calls {@link
-android.app.Activity#onOptionsItemSelected(MenuItem) onOptionsItemSelected()} on the activity before
-calling the same callback for the fragment. You can also declare an item to "always" appear as an action item, instead of being
-placed in the overflow menu when space is limited. In most cases, you should not
-force an item to appear in the action bar by using the {@code "always"} value. However, you might
-need an item to always appear when it provides an action view that does
-not offer a default action for the overflow menu. Beware that too
-many action items can create a cluttered UI and cause layout problems on devices with a narrow
-screen. It's best to instead use {@code "ifRoom"} to request that an item appear in the action
-bar, but allow the system to move it into the overflow menu when there's not enough room. For more information about creating the options menu that defines your action items, see the Menus developer guide. As a general rule, all items in the options menu (let alone action items)
-should have a global impact on the app, rather than affect only a small portion of the interface.
-For example, if you have a multi-pane layout and one pane shows a video while another lists all
-videos, the video player controls should appear within the pane containing the video (not in the
-action bar), while the action bar might provide action items to share the video or save the video to
-a favorites list. So, even before deciding whether a menu item should appear as an action item, be sure that
-the item has a global scope for the current activity. If it doesn't, then you should place it
-as a button in the appropriate context of the activity layout. The {@code icon} is optional, but recommended. For icon design recommendations,
+see the Iconography design
+guide. You can also download a set of standard action bar icons (such as for Search or Discard)
+from the Downloads page. You should carefully choose which items from your options menu should appear as action items by
-assessing a few key traits. In general, each action item should be at least one
-of the following: You can also use {@code "always"} to declare that an item always appear as an action button.
+However, you should not force an item to appear in the action bar this
+way. Doing so can create layout problems on devices with a narrow screen. It's best to instead
+use {@code "ifRoom"} to request that an item appear in the action bar, but allow the system to move
+it into the overflow when there's not enough room. However, it might be necessary to use this value
+if the item includes an action view that cannot be collapsed and
+must always be visible to provide access to a critical feature. Example frequent actions: "New message" in the Messaging app and
-"Search" on Google Play. Example important actions: "Add network" in Wi-Fi settings and "Switch to camera" in the
-Gallery app. Example typical actions: "Refresh" in an email or social app, and "New contact" in the
-People app. If you believe that more than four of your menu items can be justified as action items, then you
-should carefully consider their relative level of importance and try to set no more than four as
-action items (and do so using the {@code "ifRoom"} value to allow the system to put some back in the
-overflow menu when space is limited on smaller screens). Even if space is available on a wide
-screen, you should not create a long stream of action items that clutter the UI and appear like a
-desktop toolbar, so keep the number of action items to a minimum. Additionally, the following actions should never appear as action items: Settings, Help,
-Feedback, or similar. Always keep them in the overflow menu. Note: Remember that not all devices provide a dedicated hardware
-button for Search, so if it's an important feature in your app, it should always appear as an
-action item (and usually as the first item, especially if you offer it with an action view). When the user presses an action, the system calls your activity's {@link
+android.app.Activity#onOptionsItemSelected(MenuItem) onOptionsItemSelected()} method. Using the
+{@link android.view.MenuItem} passed to this method, you can identify the action by calling {@link
+android.view.MenuItem#getItemId()}. This returns the unique ID provided by the {@code <item>}
+tag's {@code id} attribute so you can perform the appropriate action. For example: Note: If you inflate menu items from a fragment, via the {@link
+android.app.Fragment} class's {@link android.app.Fragment#onCreateOptionsMenu onCreateOptionsMenu()}
+callback, the system calls {@link
+android.app.Fragment#onOptionsItemSelected(MenuItem) onOptionsItemSelected()} for that
+fragment when the user selects one of those items. However, the activity gets a chance to
+handle the event first, so the system first calls {@link
+android.app.Activity#onOptionsItemSelected(MenuItem) onOptionsItemSelected()} on the activity,
+before calling the same callback for the fragment. To ensure that any fragments in the
+activity also have a chance to handle the callback, always pass the call to the superclass
+as the default behavior instead of returning {@code false} when you do not handle the item. When your application is running on Android 4.0 (API level 14) and higher, there's an extra mode
-available for the action bar called "split action bar." When you enable split action bar, a separate
-bar appears at the bottom of the screen to display all action items when the activity is running on
-a narrow screen (such as a portrait-oriented handset). Splitting the action bar to separate
-the action items ensures that a reasonable amount of space is available to display all your action
+ Split action bar provides a separate
+bar at the bottom of the screen to display all action items when the activity is running on
+a narrow screen (such as a portrait-oriented handset). Separating the action items this way
+ensures that a reasonable amount of space is available to display all your action
items on a narrow screen, while leaving room for navigation and title elements at the top. To enable split action bar, simply add {@code uiOptions="splitActionBarWhenNarrow"} to your
+ To enable split action bar when using the support library, you must do two things: Be aware that Android adjusts the action bar's appearance in a variety of ways, based on the
-current screen size. Using split action bar is just one option that you can enable to allow the
-action bar to further optimize the user experience for different screen sizes. In doing so, you
-may also allow the action bar to collapse navigation tabs into the main action bar. That is, if you
-use navigation tabs in your action bar, once the action items are
-separated on a narrow screen, the navigation tabs may be able to fit into the main action bar rather
-than be separated into the "stacked action bar." Specifically, if you've disabled the action bar
-icon and title (with {@link android.app.ActionBar#setDisplayShowHomeEnabled
-setDisplayShowHomeEnabled(false)} and {@link android.app.ActionBar#setDisplayShowTitleEnabled
-setDisplayShowTitleEnabled(false)}), then the navigation tabs collapse into the main action bar, as
-shown by the second device in figure 3. Then set this as your activity theme: Note: Although the {@link android.R.attr#uiOptions
-android:uiOptions} attribute was added in Android 4.0 (API level 14), you can safely include it in
-your application even if your {@code minSdkVersion} is set to
-a value lower than {@code "14"} to remain compatible with older versions of Android. When running on
-older versions, the system simply ignores the XML attribute because it doesn't understand it. The
-only condition to including it in your manifest is that you must compile your application against a
-platform version that supports API level 14 or higher. Just be sure that you don't openly use other
-APIs in your application code that aren't supported by the version declared by your {@code minSdkVersion}
-attribute—only XML attributes are safely ignored by older platforms. Using split action bar also allows navigation tabs to collapse into the
+main action bar if you remove the icon and title (as shown on the right in figure 3).
+To create this effect, disable the action bar
+icon and title with {@link android.support.v7.app.ActionBar#setDisplayShowHomeEnabled
+setDisplayShowHomeEnabled(false)} and {@link
+android.support.v7.app.ActionBar#setDisplayShowTitleEnabled setDisplayShowTitleEnabled(false)}. Navigation with Back and Up By default, the system uses your application icon in the action bar, as specified by the {@code android:icon}
-attribute in the {@code
-<application>} or {@code
-<activity>} element. However, if you also specify the {@code android:logo}
-attribute, then the action bar uses the logo image instead of the icon. A logo should usually be wider than the icon, but should not include unnecessary text. You
-should generally use a logo only when it represents your brand in a traditional format that users
-recognize. A good example is the YouTube app's logo—the logo represents the expected user
-brand, whereas the app's icon is a modified version that conforms to the square requirement. Enabling the app icon as an Up button allows the user to navigate your app based
+on the hierarchical relationships between screens. For instance, if screen A displays a list of
+items, and selecting an item leads to screen B, then
+screen B should include the Up button, which returns to screen A. By default, your application icon appears in the action bar on the left side. If you'd like,
-you can enable the icon to behave as an action item. In response to user action on the icon, your
-application should do one of two things: When the user touches the icon, the system calls your activity's {@link
-android.app.Activity#onOptionsItemSelected onOptionsItemSelected()} method with the {@code
-android.R.id.home} ID. In response, you should either start the home activity or
-take the user one step up in your application's structural hierarchy. If you respond to the application icon by returning to the home activity, you should include
-the {@link android.content.Intent#FLAG_ACTIVITY_CLEAR_TOP} flag in the {@link
-android.content.Intent}. With this flag, if the activity you're starting already exists in the
-current task, then all activities on top of it are destroyed and it is brought to the front.
-Adding this flag is often important because going "home" is an action that's equivalent to "going
-back" and you should usually not create a new instance of the home activity. Otherwise, you
-might end up with a long stack of activities in the current task with multiple instances of the
-home activity. Note: Up navigation is distinct from the back navigation provided
+by the system Back button. The Back button is used to navigate in reverse
+chronological order through the history of screens the user has recently worked with. It is
+generally based on the temporal relationships between screens, rather than the app's hierarchy
+structure (which is the basis for up navigation). For example, here's an implementation of {@link android.app.Activity#onOptionsItemSelected
-onOptionsItemSelected()} that returns to the application's "home" activity: To enable the app icon as an Up button, call {@link
+android.support.v7.app.ActionBar#setDisplayHomeAsUpEnabled setDisplayHomeAsUpEnabled()}.
+For example: In case the user can enter the current activity from another application, you might also want to
-add the {@link android.content.Intent#FLAG_ACTIVITY_NEW_TASK} flag. This flag ensures that, when the
-user navigates either "home" or "up", the new activity is not added to the current
-task, but instead started in a task that belongs to your application. For example, if the user
-starts an activity in your application through an intent invoked by another application, then
-selects the action bar icon to navigate home or up, the {@link
-android.content.Intent#FLAG_ACTIVITY_CLEAR_TOP} flag starts the activity in a task that belongs to
-your application (not the current task). The system either starts a new task with your new activity
-as the root activity or, if an existing task exists in the background with an instance of that
-activity, then that task is brought forward and the target activity receives {@link
-android.app.Activity#onNewIntent onNewIntent()}. So if your activity accepts intents from other
-applications (it declares any generic intent filters), you should usually add the {@link
-android.content.Intent#FLAG_ACTIVITY_NEW_TASK} flag to the intent: Now the icon in the action bar appears with the Up caret (as shown in figure 4).
+However, it won't do anything by default. To specify the activity to open when the
+user presses Up button, you have two options: This is the best option when the parent activity is always the same. By
+declaring in the manifest which activity is the parent, the action bar automatically performs the
+correct action when the user presses the Up button. Beginning in Android 4.1 (API level 16), you can declare the parent with the {@code parentActivityName}
+attribute in the {@code
+<activity>} element. To support older devices with the support library, also
+include a {@code
+<meta-data>} element that specifies
+the parent activity as the value for {@code android.support.PARENT_ACTIVITY}. For example: For more information about these flags and other back stack behaviors, read the Tasks and Back Stack
-developer guide. Note: If you're using the icon to navigate to the home
-activity, beware that beginning with Android 4.0 (API level 14), you must explicitly enable the
-icon as an action item by calling {@link android.app.ActionBar#setHomeButtonEnabled
-setHomeButtonEnabled(true)} (in previous versions, the icon was enabled as an action item by
-default). As a supplement to traditional "back" navigation—which takes the user to the previous
-screen in the task history—you can enable the action bar icon to offer "up"
-navigation, which should take the user one step up in your application's structural hierarchy. For
-instance, if the current screen is somewhere deep in the hierarchy of the application, touching the
-app icon should navigate upward one level, to the parent of the current screen. For example, figure 5 illustrates how the BACK button behaves when the user navigates from one
-application to an activity belonging to a different application (specifically, when composing an
-email to a person selected from the People app). However, if the user wants to stay within the email application after composing the email,
-up navigation allows the user to navigate upward in the email application, rather than go back
-to the previous activity. Figure 6 illustrates this scenario, in which the user again comes into
-the email application, but presses the action bar icon to navigate up, rather than back. Navigation Design For more about how Up and Back navigation differ, read Android Design's Navigation guide. Once the parent activity is specified in the manifest like this and you enable the Up
+ button with {@link
+android.support.v7.app.ActionBar#setDisplayHomeAsUpEnabled setDisplayHomeAsUpEnabled()}, your work
+is done and the action bar properly navigates up. To enable the icon for up navigation (which displays the "up" indicator next to the icon), call
-{@link android.app.ActionBar#setDisplayHomeAsUpEnabled setDisplayHomeAsUpEnabled(true)} on your
-{@link android.app.ActionBar}: This is appropriate when the parent activity may be different depending
+ on how the user arrived at the current screen. That is, if there are many paths that the user
+ could have taken to reach the current screen, the Up button should navigate
+ backward along the path the user actually followed to get there. The system calls {@link
+android.support.v7.app.ActionBarActivity#getSupportParentActivityIntent()} when the user presses
+the Up button while navigating your app (within your app's own task). If the activity that
+should open upon up navigation differs depending on how the user arrived at the current location,
+then you should override this method to return the {@link
+android.content.Intent} that starts the appropriate parent activity. The system calls {@link
+android.support.v7.app.ActionBarActivity#onCreateSupportNavigateUpTaskStack
+onCreateSupportNavigateUpTaskStack()} for your activity when the user presses the Up
+button while your activity is running in a task that does not belong to your app. Thus,
+you must use the {@link android.support.v4.app.TaskStackBuilder} passed to this method to construct
+the appropriate back stack that should be synthesized when the user navigates up. Even if you override {@link
+android.support.v7.app.ActionBarActivity#getSupportParentActivityIntent()} to specify up navigation
+as the user navigates your app, you can avoid the need to implement {@link
+android.support.v7.app.ActionBarActivity#onCreateSupportNavigateUpTaskStack
+onCreateSupportNavigateUpTaskStack()} by declaring "default" parent activities in the manifest file
+as shown above. Then the default implementation of {@link
+android.support.v7.app.ActionBarActivity#onCreateSupportNavigateUpTaskStack
+onCreateSupportNavigateUpTaskStack()} will synthesize a back stack based on the parent activities
+declared in the manifest. When the user touches the icon, the system calls your activity's {@link
-android.app.Activity#onOptionsItemSelected onOptionsItemSelected()} method with the {@code
-android.R.id.home} ID, as shown in the above section about Using the App Icon
-for Navigation. Remember to use the {@link android.content.Intent#FLAG_ACTIVITY_CLEAR_TOP} flag in the {@link
-android.content.Intent}, so that you don't create a new instance of the parent activity if one
-already exists. For instance, if you don't use the {@link
-android.content.Intent#FLAG_ACTIVITY_CLEAR_TOP} flag, then after navigating up, the BACK button will
-actually take the user "forward", with respect to the application structure, which would be
-strange. Note: If there are many paths that the user could have taken to
-reach the current activity within your application, the up icon should navigate backward along the
-path the user actually followed to get to the current activity. Note:
+If you've built your app hierarchy using a series of fragments instead of multiple
+activities, then neither of the above options will work. Instead, to navigate up through your
+fragments, override {@link android.support.v7.app.ActionBarActivity#onSupportNavigateUp()}
+to perform the appropriate fragment transaction—usually by popping
+the current fragment from the back stack by calling {@link
+android.support.v4.app.FragmentManager#popBackStack()}. For more information about implementing Up navigation, read
+Providing Up Navigation. An action view is a widget that appears in the action bar as a substitute for an action item's
-button. For example, if you have an item in the options menu for "Search," you can add an action
-view that replaces the button with a {@link android.widget.SearchView} widget, as shown in figure
-7. An action view is a widget that appears in the action bar as a substitute for an action
+button. An action view provides fast access to rich actions without changing activities or
+fragments, and without replacing the action bar. For example, if you have an action for Search, you
+can add an action view to
+embeds a {@link android.support.v7.widget.SearchView} widget in the action bar, as shown in figure
+5. To declare an action view for an item in your menu resource, use either the {@code
-android:actionLayout} or {@code android:actionViewClass} attribute to specify either a layout
-resource or widget class to use, respectively. For example: To declare an action view, use either the {@code
+actionLayout} or {@code actionViewClass} attribute to specify either a layout
+resource or widget class to use, respectively. For example, here's how to add
+the {@link android.support.v7.widget.SearchView} widget: Notice that the {@code android:showAsAction} attribute also includes {@code
-"collapseActionView"}. This is optional and declares that the action view should be collapsed into a
-button. When the user selects the button, the action view expands. Otherwise, the action view is
-visible by default and might consume valuable action bar space even when the user is not using it.
-For more information, see the next section about Handling
-collapsible action views. Notice that the {@code showAsAction} attribute also includes the {@code "collapseActionView"}
+value. This is optional and declares that the action view should be collapsed into a
+button. (This behavior is explained further in the following section about
+Handling collapsible action views.) If you need to configure the action view (such as to add event listeners), you can do so during
+the {@link android.app.Activity#onCreateOptionsMenu onCreateOptionsMenu()} callback. You can
+acquire the action view object by calling the static method {@link
+android.support.v4.view.MenuItemCompat#getActionView MenuItemCompat.getActionView()} and passing it
+the corresponding {@link android.view.MenuItem}. For example, the search widget from the above
+sample is acquired like this: If you need to add some event hooks to your action view, you can do so during the {@link
-android.app.Activity#onCreateOptionsMenu onCreateOptionsMenu()} callback. You can acquire elements
-in an action view by calling {@link android.view.Menu#findItem findItem()} with the ID of the menu
-item, then call {@link android.view.MenuItem#getActionView}. For
-example, the search widget from the above sample is acquired like this: On API level 11 or higher Get the action view by calling {@link android.view.MenuItem#getActionView} on the
+corresponding {@link android.view.MenuItem}: For more information about using the search widget, see Creating a Search Interface. The {@code "collapseActionView"} option was added with Android 4.0 (API level 14). However, if
-your application supports older versions, you should
-still declare {@code "collapseActionView"} in order to better support smaller screens.
-Devices running Android 4.0 and higher will show the action view collapsed, while older versions
-work as designed otherwise. Adding this value requires that you set your build target to Android 4.0 or higher in order to
-compile. Older versions of Android ignore the {@code "collapseActionView"} value because they don't
-understand it. Just be sure not to use other APIs in your source code that are not supported in the
-version declared by your {@code
-minSdkVersion}, unless you add the appropriate version check at runtime. Action views allow you to provide fast access to rich actions without changing activities or
-fragments, or replacing the action bar. However, it might not be appropriate to make an action view
-visible by default. To preserve the action bar space (especially when running on smaller screens),
-you can collapse your action view into an action item button. When the user selects the
-button, the action view appears in the action bar. When collapsed, the system might place the item
-into the overflow menu if you've defined {@code android:showAsAction} with {@code "ifRoom"}, but the
-action view still appears in the action bar when the user selects the item. You can make your action
-view collapsible by adding {@code "collapseActionView"} to the {@code android:showAsAction}
+ To preserve the action bar space, you can collapse your action view into an action button.
+When collapsed, the system might place the action
+into the action overflow, but the
+action view still appears in the action bar when the user selects it. You can make your action
+view collapsible by adding {@code "collapseActionView"} to the {@code showAsAction}
attribute, as shown in the XML above. Because the system will expand the action view when the user selects the item, you
+ Because the system expands the action view when the user selects the action, you
do not need to respond to the item in the {@link
-android.app.Activity#onOptionsItemSelected onOptionsItemSelected} callback. The system still calls
-{@link android.app.Activity#onOptionsItemSelected onOptionsItemSelected()} when the user selects it,
-but the system will always expand the action view unless you return {@code true} (indicating
-you've handled the event instead). The system also collapses your action view when the user selects the "up" icon in the action
-bar or presses the BACK button. If necessary, you can expand or collapse the action view in your own code by calling {@link
-android.view.MenuItem#expandActionView()} and {@link android.view.MenuItem#collapseActionView()} on
-the {@link android.view.MenuItem}. Note: Although collapsing your action view is optional, we
-recommend that you always collapse your action view if it includes {@link
-android.widget.SearchView}. Also be aware that some devices provide a dedicated SEARCH button and
-you should expand your search action view if the user presses the SEARCH button. Simply override
-your activity's {@link android.app.Activity#onKeyUp onKeyUp()} callback method, listen for the
-{@link android.view.KeyEvent#KEYCODE_SEARCH} event, then call {@link
-android.view.MenuItem#expandActionView()}. The system also collapses your action view when the user presses the Up button
+or Back button. If you need to update your activity based on the visibility of your action view, you can receive
-callbacks when it's expanded and collapsed by defining an {@link
-android.view.MenuItem.OnActionExpandListener OnActionExpandListener} and registering it with {@link
-android.view.MenuItem#setOnActionExpandListener setOnActionExpandListener()}. For example: Similar to an action view, an action provider (defined by the {@link
-android.view.ActionProvider} class) replaces an action item with a customized layout, but it also
-takes control of all the item's behaviors. When you declare an action provider for a menu
-item in the action bar, it not only controls the appearance of the item in the action bar with a
-custom layout, but also handles the default event for the menu item when it appears in the overflow
-menu. It can also provide a submenu from either the action bar or the overflow menu. For example, the {@link android.widget.ShareActionProvider} is an extension of {@link
-android.view.ActionProvider} that facilitates a “share" action by showing a list of available share
-targets from the action bar. Instead of using a
-traditional action item that invokes the {@link android.content.Intent#ACTION_SEND} intent, you can
-declare an instance of {@link android.widget.ShareActionProvider} to handle an action item. This
-action provider presents an action view with a drop-down list of applications that handle
-the {@link android.content.Intent#ACTION_SEND} intent, even when the menu item appears in the
-overflow menu. Hence, when you use an action provider such as this one, you don't
-have to handle user events on the menu item. To declare an action provider for an action item, define the {@code android:actionProviderClass}
-attribute for the appropriate the {@code <item>} element in your menu resource, using the
-fully-qualified class name of the action provider. For example: Similar to an action view, an action provider
+replaces an action button with a customized layout. However,
+unlike an action view, an action provider takes control of all the action's behaviors
+and an action provider can display a submenu when pressed. To declare an action provider, supply the {@code actionViewClass} attribute in the
+menu {@code <item>} tag with a fully-qualified class name for an
+{@link android.support.v4.view.ActionProvider}. In this example, the {@link android.widget.ShareActionProvider} is used as the action provider.
-At this point, the action provider officially takes control of the menu item and handles both
-its appearance and behavior in the action bar and its behavior in the overflow menu. You must
-still provide a text title for the item to be used in the overflow menu. You can build your own action provider by extending the {@link
+android.support.v4.view.ActionProvider} class, but Android provides some pre-built action providers
+such as {@link android.support.v7.widget.ShareActionProvider}, which facilitates a "share" action
+by showing a list of possible apps for sharing directly in the action bar (as shown in figure
+6). Although the action provider can perform the default action for the menu item when it appears in
-the overflow menu, your activity (or fragment) can override that behavior by
-also handling the click event from the {@link android.app.Activity#onOptionsItemSelected
-onOptionsItemSelected()} callback method. If you do not handle the event in that callback, then
-the action provider receives the {@link android.view.ActionProvider#onPerformDefaultAction()}
-callback to handle the event. However, if the action provider provides a submenu, then your
-activity will not receive the {@link android.app.Activity#onOptionsItemSelected
-onOptionsItemSelected()} callback, because the submenu is shown instead of invoking the default
-menu item behavior when selected. Because each {@link android.support.v4.view.ActionProvider} class defines its own action
+behaviors, you don't need to listen for the action in the {@link
+android.app.Activity#onOptionsItemSelected onOptionsItemSelected()} method. If necessary though,
+you can still listen for the click event in the {@link android.app.Activity#onOptionsItemSelected
+onOptionsItemSelected()} method in case you need to simultaneously perform another action. But be
+sure to return {@code false} so that the the action provider still receives the {@link
+android.support.v4.view.ActionProvider#onPerformDefaultAction()} callback to perform its intended
+action. However, if the action provider provides a submenu of actions, then your
+activity does not receive a call to {@link android.app.Activity#onOptionsItemSelected
+onOptionsItemSelected()} when the user opens the list or selects one of the submenu items. If you want to provide a "share" action in your action bar by leveraging other applications
-installed on the device (for example, to share a photo using a messaging or social app), then using
-{@link android.widget.ShareActionProvider} is an effective way to do so, rather than adding an
-action item that invokes the {@link android.content.Intent#ACTION_SEND} intent. When
-you use {@link android.widget.ShareActionProvider} for an action item, it presents an action view
-with a drop-down list of applications that handle the {@link android.content.Intent#ACTION_SEND}
-intent (as shown in figure 8). To add a "share" action with {@link android.support.v7.widget.ShareActionProvider},
+define the {@code actionProviderClass} for an {@code <item>} tag with
+the {@link android.support.v7.widget.ShareActionProvider} class. For example: All the logic for creating the submenu, populating it with share targets, and handling click
-events (including when the item appears in the overflow menu) is implemented by the {@link
-android.widget.ShareActionProvider}—the only code you need to write is to declare the action
-provider for the menu item and specify the share intent. By default, the {@link android.widget.ShareActionProvider} retains a ranking for each
-share target based on how often the user selects each one. The share targets used more frequently
-appear at the top of the drop-down list and the target used most often appears directly in the
-action bar as the default share target. By default, the ranking information is
-saved in a private file with a name specified by {@link
-android.widget.ShareActionProvider#DEFAULT_SHARE_HISTORY_FILE_NAME}. If you use the {@link
-android.widget.ShareActionProvider} or an extension of it for only one type of action, then you
-should continue to use this default history file and there's nothing you need to do. However, if you
-use {@link android.widget.ShareActionProvider} or an extension of it for multiple actions with
-semantically different meanings, then each {@link android.widget.ShareActionProvider} should specify
-its own history file in order to maintain its own history. To specify a
-different history file for the {@link android.widget.ShareActionProvider}, call {@link
-android.widget.ShareActionProvider#setShareHistoryFileName setShareHistoryFileName()} and provide
-an XML file name (for example, {@code "custom_share_history.xml"}). Note: Although the {@link android.widget.ShareActionProvider} ranks
-share targets based on frequency of use, the behavior is extensible and extensions of {@link
-android.widget.ShareActionProvider} can perform different behaviors and ranking based on the history
-file (if appropriate). To add {@link android.widget.ShareActionProvider}, simply define the {@code
-android:actionProviderClass} attribute with {@code "android.widget.ShareActionProvider"}, as shown
-in the XML example above. The only thing left to do is define
-the {@link android.content.Intent} you want to use for sharing. To do so, you must call {@link
-android.view.MenuItem#getActionProvider} to retrieve the {@link android.widget.ShareActionProvider}
-that's associated with a {@link android.view.MenuItem}, then call {@link
-android.widget.ShareActionProvider#setShareIntent setShareIntent()}. If the format for the share intent depends on the selected item or other variables that change
-during the activity lifecycle, you should save the {@link android.widget.ShareActionProvider} in a
-member field and update it by calling {@link android.widget.ShareActionProvider#setShareIntent
-setShareIntent()} as necessary. For example: Now the action provider takes control of the action item and handles both
+its appearance and behavior. But you must
+still provide a title for the item to be used when it appears in the action overflow. The only thing left to do is define
+the {@link android.content.Intent} you want to use for sharing. To do so, edit
+your {@link
+android.app.Activity#onCreateOptionsMenu onCreateOptionsMenu()} method to call {@link
+android.support.v4.view.MenuItemCompat#getActionProvider MenuItemCompat.getActionProvider()}
+and pass it the {@link android.view.MenuItem} holding the action provider. Then call {@link
+android.support.v7.widget.ShareActionProvider#setShareIntent setShareIntent()} on the
+returned {@link android.support.v7.widget.ShareActionProvider} and pass it an
+{@link android.content.Intent#ACTION_SEND} intent with the appropriate content attached. You should call {@link
+android.support.v7.widget.ShareActionProvider#setShareIntent setShareIntent()} once during {@link
+android.app.Activity#onCreateOptionsMenu onCreateOptionsMenu()} to initialize the share action,
+but because the user context might change, you must update the intent any time the shareable
+content changes by again calling {@link
+android.support.v7.widget.ShareActionProvider#setShareIntent setShareIntent()}. For example: The {@link android.widget.ShareActionProvider} now handles all user interaction with the item and
-you do not need to handle click events from the {@link
+ The {@link android.support.v7.widget.ShareActionProvider} now handles all user interaction with
+the item and you do not need to handle click events from the {@link
android.app.Activity#onOptionsItemSelected onOptionsItemSelected()} callback method. For a sample using the share action provider, see
-ActionBarShareActionProviderActivity.
+
+ By default, the {@link android.support.v7.widget.ShareActionProvider} retains a ranking for each
+share target based on how often the user selects each one. The share targets used more frequently
+appear at the top of the drop-down list and the target used most often appears directly in the
+action bar as the default share target. By default, the ranking information is saved in a private
+file with a name specified by {@link
+android.support.v7.widget.ShareActionProvider#DEFAULT_SHARE_HISTORY_FILE_NAME}. If you use the
+{@link android.support.v7.widget.ShareActionProvider} or an extension of it for only one type of
+action, then you should continue to use this default history file and there's nothing you need to
+do. However, if you use {@link android.support.v7.widget.ShareActionProvider} or an extension of it
+for multiple actions with semantically different meanings, then each {@link
+android.support.v7.widget.ShareActionProvider} should specify its own history file in order to
+maintain its own history. To specify a different history file for the {@link
+android.support.v7.widget.ShareActionProvider}, call {@link
+android.support.v7.widget.ShareActionProvider#setShareHistoryFileName setShareHistoryFileName()}
+and provide an XML file name (for example, {@code "custom_share_history.xml"}). Note: Although the {@link
+android.support.v7.widget.ShareActionProvider} ranks share targets based on frequency of use, the
+behavior is extensible and extensions of {@link android.support.v7.widget.ShareActionProvider} can
+perform different behaviors and ranking based on the history file (if appropriate). When you want to create an action view that has dynamic behaviors and a default action in the
-overflow menu, extending {@link android.view.ActionProvider} to define those behaviors is a good
-solution. Creating your own action provider offers you an organized and reusable component, rather
-than handling the various action item transformations and behaviors in your fragment or activity
-code. As shown in the previous section, Android provides one implementation of {@link
-android.view.ActionProvider} for share actions: the {@link android.widget.ShareActionProvider}. Creating your own action provider allows you to re-use and manage dynamic action item
+behaviors in a self-contained module, rather than handle action item transformations and
+behaviors in your fragment or activity
+code. As shown in the previous section, Android already provides an implementation of {@link
+android.support.v4.view.ActionProvider} for share actions: the {@link
+android.support.v7.widget.ShareActionProvider}. To create your own, simply extend the {@link android.view.ActionProvider} class and implement
+ To create your own action provider for a different action, simply extend the
+{@link android.support.v4.view.ActionProvider} class and implement
its callback methods as appropriate. Most importantly, you should implement the following: However, if your action provider provides a submenu, through the {@link
-android.view.ActionProvider#onPrepareSubMenu onPrepareSubMenu()} callback, then the submenu
-appears even when the menu item is in the overflow menu. Thus, {@link
-android.view.ActionProvider#onPerformDefaultAction()} is never called when there is a
+android.support.v4.view.ActionProvider#onPrepareSubMenu onPrepareSubMenu()} callback, then the
+submenu appears even when the action provider is placed in the action overflow. Thus, {@link
+android.support.v4.view.ActionProvider#onPerformDefaultAction()} is never called when there is a
submenu. Note: An activity or a fragment that implements {@link
android.app.Activity#onOptionsItemSelected onOptionsItemSelected()} can override the action
-provider's default behavior by handling the item-selected event (and returning true), in which
-case, the system does not call {@link android.view.ActionProvider#onPerformDefaultAction()}. Tabs Creating Swipe Views with Tabs When you want to provide navigation tabs in an activity, using the action bar's
-tabs is a great option (instead of using {@link android.widget.TabWidget}), because the
-system adapts the action bar tabs for different screen sizes—placing them in the main action
-bar when the screen is sufficiently wide, or in a separate bar (known as the "stacked action bar")
-when the screen is too narrow, as shown in figures 9 and 10. To switch between fragments using the tabs, you must perform a fragment
-transaction each time a tab is selected. If you're not familiar with how to change fragments
-using {@link android.app.FragmentTransaction}, first read the Fragments developer guide. To get started, your layout must include a {@link android.view.ViewGroup} in which you place each
-{@link android.app.Fragment} associated with a tab. Be sure the {@link android.view.ViewGroup} has a
-resource ID so you can reference it from your tab-swapping code. Alternatively, if the tab content
-will fill the activity layout (excluding the action bar), then your activity doesn't need a layout
-at all (you don't even need to call {@link android.app.Activity#setContentView
-setContentView()}). Instead, you can place each fragment in the default root {@link
-android.view.ViewGroup}, which you can refer to with the {@code android.R.id.content} ID (you can
-see this ID used in the sample code below, during fragment transactions). Tabs in the action bar make it easy for users to explore and switch between different views in
+your app. The tabs provided by the {@link android.support.v7.app.ActionBar} are ideal because they
+adapt to different screen sizes. For example, when the screen is wide enough the tabs appear in the
+action bar alongside the action buttons (such as when on a tablet, shown in figure 7), while when
+on a narrow screen they appear in a separate bar (known as the "stacked action bar", shown in
+figure 8). In some cases, the Android system will instead show your tab items as a drop-down list
+to ensure the best fit in the action bar. To get started, your layout must include a {@link android.view.ViewGroup} in which you place
+each {@link android.app.Fragment} associated with a tab. Be sure the {@link android.view.ViewGroup}
+has a resource ID so you can reference it from your code and swap the tabs within it.
+Alternatively, if the tab content will fill the activity layout, then your activity doesn't need a
+layout at all (you don't even need to call {@link android.app.Activity#setContentView
+setContentView()}). Instead, you can place each fragment in the default root view, which you can
+refer to with the {@code android.R.id.content} ID. Once you determine where the fragments appear in the layout, the basic procedure to add tabs
is: When looking at the {@link android.app.ActionBar.TabListener} interface, notice that the
-callback methods provide only the {@link android.app.ActionBar.Tab} that was selected and a {@link
-android.app.FragmentTransaction} for you to perform fragment transactions—it doesn't say
-anything about what fragment you should swap in or out. Thus, you must define your own association
+ Notice that the {@link android.support.v7.app.ActionBar.TabListener}
+callback methods don't specify which fragment is associated with the tab, but merely which
+{@link android.support.v7.app.ActionBar.Tab} was selected.
+You must define your own association
between each {@link android.app.ActionBar.Tab} and the appropriate {@link android.app.Fragment} that
-it represents (in order to perform the appropriate fragment transaction). There are several ways you
-can define the association, depending on your design. In the example below, the {@link
-android.app.ActionBar.TabListener} implementation provides a constructor such that each new tab uses
-its own instance of the listener. Each instance of the listener defines several fields that are
-necessary to later perform a transaction on the appropriate fragment. For example, here's how you might implement the {@link android.app.ActionBar.TabListener}
such that each tab uses its own instance of the listener: The {@link android.app.ActionBar.TabListener} implementation is the bulk of the work. All that
-remains is to create each {@link android.app.ActionBar.Tab} and add it to the {@link
+ All that remains is to create each {@link android.app.ActionBar.Tab} and add it to the {@link
android.app.ActionBar}. Additionally, you must call {@link
android.app.ActionBar#setNavigationMode(int) setNavigationMode(NAVIGATION_MODE_TABS)} to make the
-tabs visible. You might also want to disable the activity title by calling {@link
-android.app.ActionBar#setDisplayShowTitleEnabled setDisplayShowTitleEnabled(false)} if the tab
-titles actually indicate the current view. For example, the following code adds two tabs using the listener defined above: Note: The above implementation for {@link
-android.app.ActionBar.TabListener} is one of several possible techniques. You can see more of
-this style in the API Demos app. If your activity stops, you should retain the currently selected tab with the saved instance state so you
+can open the appropriate tab when the user returns. When it's time to save the state, you can query
+the currently selected tab with {@link
+android.support.v7.app.ActionBar#getSelectedNavigationIndex()}. This returns the index position of
+the selected tab. If your activity stops, you should retain the currently selected tab with the saved instance
-state so you can open the appropriate tab when the user returns. When it's time to save the
-state, you can query the currently selected tab with {@link
-android.app.ActionBar#getSelectedNavigationIndex()}. This returns the index position of the selected
-tab. Caution: It's important that you save the state of each fragment
-as necessary, so that when users switch fragments with the tabs and then return to a previous
-fragment, it looks the way it did when they left. For information about saving the state of your
+so when users switch fragments with the tabs and then return to a previous
+fragment, it looks the way it did when they left. Some of the state is saved by default, but you
+may need to manually save state for customized views. For information about saving the state of your
fragment, see the Fragments
-developer guide. Note: The above implementation for {@link
+android.support.v7.app.ActionBar.TabListener} is one of several possible techniques. Another popular
+option is to use {@link android.support.v4.view.ViewPager} to manage the fragments so users
+can also use a swipe gesture to switch tabs. In this case, you simply tell the
+{@link android.support.v4.view.ViewPager} the current tab position in the
+{@link android.support.v7.app.ActionBar.TabListener#onTabSelected onTabSelected()} callback.
+For more information, read
+Creating Swipe Views with Tabs. Note: In some cases, the Android system will show your action
-bar tabs as a drop-down list in order to ensure the best fit in the action bar. As another mode of navigation (or filtering) within your activity, the action bar offers a
-built in drop-down list. For example, the drop-down list can offer different modes by which content
-in the activity is sorted. As another mode of navigation (or filtering) for your activity, the action bar offers a built
+in drop-down list (also known as a "spinner"). For example, the drop-down list can offer different
+modes by which content in the activity is sorted. Using the drop-down list is useful when changing the content is important but not necessarily a
+frequent occurrence. In cases where switching the content is more frequent,
+you should use navigation tabs instead. The basic procedure to enable drop-down navigation is: Note: You should perform this during your activity's {@link
-android.app.Activity#onCreate
-onCreate()} method. This method takes your {@link android.widget.SpinnerAdapter} and {@link
-android.app.ActionBar.OnNavigationListener}. That's the basic setup. However, implementing the {@link android.widget.SpinnerAdapter} and
-{@link android.app.ActionBar.OnNavigationListener} is where most of the work is done. There are many
-ways you can implement these to define the functionality for your drop-down navigation and
+ This procedure is relatively short, but implementing the {@link android.widget.SpinnerAdapter}
+and {@link android.app.ActionBar.OnNavigationListener} is where most of the work is done. There are
+many ways you can implement these to define the functionality for your drop-down navigation and
implementing various types of {@link android.widget.SpinnerAdapter} is beyond the scope of this
document (you should refer to the {@link android.widget.SpinnerAdapter} class reference for more
-information). However, below is a simple example for a {@link android.widget.SpinnerAdapter} and
-{@link android.app.ActionBar.OnNavigationListener} to get you started (click the title to
-reveal the sample). If you've implemented a custom design for the widgets in your application, you might
-also want to redesign some of the action bar to match your app design. To do so, you need to use
-Android's style and theme framework to restyle the action
-bar using special style properties. If you want to implement a visual design that represents your app's brand, the action bar allows
+you to customize each detail of its appearance, including the action bar color, text colors, button
+styles, and more. To do so, you need to use Android's style and theme framework to restyle the action bar
+using special style properties. Note: In order for background images to change appearance
-depending on the current button state (selected, pressed, unselected), the drawable resource you use
-must be a state
-list drawable. Caution: For all background drawables you provide, be sure to
+use Nine-Patch drawables
+to allow stretching. The nine-patch image should be smaller than 40dp tall and 30dp
+wide. Caution: For all background drawables you provide, be sure to use Nine-Patch drawables to allow
-stretching. The Nine-Patch image should be smaller than 40px tall and 30px wide (for the mdpi asset). The default for this style for this
+ is {@link android.support.v7.appcompat.R.style#Widget_AppCompat_ActionBar
+ Widget.AppCompat.ActionBar}, which is what you should use as the parent style. Supported styles include: The default for this style for this
+ is {@link android.support.v7.appcompat.R.style#Widget_AppCompat_ActionButton
+ Widget.AppCompat.ActionButton}, which is what you should use as the parent style. The default for this style for this
+ is {@link android.support.v7.appcompat.R.style#Widget_AppCompat_ActionButton_Overflow
+ Widget.AppCompat.ActionButton.Overflow}, which is what you should use as the parent style. The default for this style for this
+ is {@link android.support.v7.appcompat.R.style#TextAppearance_AppCompat_Widget_ActionBar_Title
+ TextAppearance.AppCompat.Widget.ActionBar.Title}, which is what you should use as the parent
+ style. When overlay mode is enabled, your activity layout has no awareness of the action bar laying on
+ When overlay mode is enabled, your activity layout has no awareness of the action bar lying on
top of it. So, you must be careful not to place any important information or UI components in the
-area overlayed by the action bar. If appropriate, you can refer to the platform's value for {@link
+area overlaid by the action bar. If appropriate, you can refer to the platform's value for {@link
android.R.attr#actionBarSize} to determine the height of the action bar, by referencing it
in your XML layout. For example: You can also retrieve the action bar height at runtime with {@link
android.app.ActionBar#getHeight()}. This reflects the height of the action bar at the time it's
-called, which might not include the stacked action bar (due to navigation tabs) if called during early
-activity lifecycle methods. To see how you can determine the total height at runtime, including the
-stacked action bar, see the {@code TitlesFragment} class in the Honeycomb Gallery sample app. The default for this style for this
+ is {@link android.support.v7.appcompat.R.style#Widget_AppCompat_ActionButton
+ Widget.AppCompat.ActionButton}, which is what you should use as the parent style. The default for this style for this
+ is {@link android.support.v7.appcompat.R.style#Widget_AppCompat_ActionBar_TabView
+ Widget.AppCompat.ActionBar.TabView}, which is what you should use as the parent style. The default for this style for this
+ is {@link android.support.v7.appcompat.R.style#Widget_AppCompat_ActionBar_TabBar
+ Widget.AppCompat.ActionBar.TabBar}, which is what you should use as the parent style. The default for this style for this
+ is {@link android.support.v7.appcompat.R.style#Widget_AppCompat_ActionBar_TabText
+ Widget.AppCompat.ActionBar.TabText}, which is what you should use as the parent style. The default for this style for this
+ is {@link android.support.v7.appcompat.R.style#Widget_AppCompat_Spinner_DropDown_ActionBar
+ Widget.AppCompat.Spinner.DropDown.ActionBar}, which is what you should use as the parent
+ style. Here's an example that defines a custom theme for an activity, {@code CustomActivityTheme},
+that includes several styles to customize the action bar. For example, here's a file that defines a few custom styles for the action bar: Notice that there are two version for each action bar style property. The first one
+includes the {@code android:} prefix on the property name to support API levels 11 and higher
+that include these properties in the framework. The second version does not
+include the {@code android:} prefix and is for older versions of the platform, on which
+the system uses the style property from the support library. The effect for each is the same. Note: Be certain that your theme declares a parent theme in the
-{@code <style>} tag, from which it inherits all styles not explicitly declared by your theme.
-When modifying the action bar, using a parent theme is important so that you can simply override the
-action bar styles you want to change without re-implementing the styles you want to leave alone
-(such as text appearance or padding in action items). You can apply your custom theme to the entire application or to individual activities in your
-manifest file like this: For more information about using style and theme resources in your application, read Styles and Themes. In your manifest file, you can apply the theme to your entire app: If you need more advanced styling for the action bar than is available with the
-properties above, you can include {@link android.R.attr#actionBarStyle android:actionBarStyle} and
-{@link android.R.attr#actionBarSplitStyle android:actionBarSplitStyle} in your activity's theme.
-Each of these specifies another style that can define various properties for the action bar,
-including different backgrounds with {@link android.R.attr#background android:background}, {@link
-android.R.attr#backgroundSplit android:backgroundSplit}, and {@link android.R.attr#backgroundStacked
-android:backgroundStacked}. If you override these action bar styles, be sure that you define a
-parent action bar style such as {@link android.R.style#Widget_Holo_ActionBar
-Widget.Holo.ActionBar}. For example, if you want to change the action bar's background, you can use the following
-styles: Or to individual activities: Caution: Be certain that each theme and style declares a parent
+theme in the {@code <style>} tag, from which it inherits all styles not explicitly declared
+by your theme. When modifying the action bar, using a parent theme is important so that you can
+simply override the action bar styles you want to change without re-implementing the styles you
+want to leave alone (such as text size or padding in action items). For more information about using style and theme resources in your application, read Styles and Themes.<meta-data>
allowTaskReparenting
-attribute of the <application>
element
+attribute of the <application>
element
applies to the activity. The default value is "{@code false}".
taskAffinity
attribute. The affinity
+The affinity of an activity is defined by the
+taskAffinity
attribute. The affinity
of a task is determined by reading the affinity of its root activity.
Therefore, by definition, a root activity is always in a task with the
-same affinity. Since activities with "{@code singleTask}" or
+same affinity. Since activities with "{@code singleTask}" or
"{@code singleInstance}" launch modes can only be at the root of a task,
-re-parenting is limited to the "{@code standard}" and "{@code singleTop}"
-modes. (See also the launchMode
+re-parenting is limited to the "{@code standard}" and "{@code singleTop}"
+modes. (See also the launchMode
attribute.)
alwaysRetainTaskState
attribute), but not always.
+some situations (see the
+alwaysRetainTaskState
attribute), but not always.
allowTaskReparenting
-are both "{@code true}", any activities that can be re-parented are moved to
-the task they share an affinity with; the remaining activities are then dropped,
+If this attribute and allowTaskReparenting
+are both "{@code true}", any activities that can be re-parented are moved to
+the task they share an affinity with; the remaining activities are then dropped,
as described above.
{@link android.app.Activity#onConfigurati
onConfigurationChanged()}
method is called.
"{@code uiMode}"
The user interface mode has changed — this can be caused when the user places the
device into a desk/car dock or when the night mode changes. See {@link
-android.app.UiModeManager}.
+android.app.UiModeManager}.
Added in API level 8.
"{@code orientation}"
- The screen orientation has changed — the user has rotated the device.
+ The screen orientation has changed — the user has rotated the device.
{@link android.app.Activity#onConfigurationChanged
-onConfigurationChanged()}
is called, it will generally be necessary to again
-retrieve all resources (including view layouts, drawables, and so on) to correctly
-handle the change.
+All of these configuration changes can impact the resource values seen by the
+application. Therefore, when {@link android.app.Activity#onConfigurationChanged
+onConfigurationChanged()}
is called, it will generally be necessary to again
+retrieve all resources (including view layouts, drawables, and so on) to correctly
+handle the change.
<application>
element has its own
-enabled
-attribute that applies to all application components, including activities. The
-<application>
-and {@code <activity>} attributes must both be "{@code true}" (as they both
-are by default) for the system to be able to instantiate the activity. If either
+The <application>
element has its own
+enabled
+attribute that applies to all application components, including activities. The
+<application>
+and {@code <activity>} attributes must both be "{@code true}" (as they both
+are by default) for the system to be able to instantiate the activity. If either
is "{@code false}", it cannot be instantiated.
permission
+applications. You can also use a permission to limit the external entities that
+can invoke the activity (see the
+permission
attribute).
allowTaskReparenting
-are both "{@code true}", this attribute trumps the other. The affinity of the
+If this attribute and
+allowTaskReparenting
+are both "{@code true}", this attribute trumps the other. The affinity of the
activity is ignored. The activity is not re-parented, but destroyed.
<application>
+This attribute must be set as a reference to a drawable resource containing
+the image definition. If it is not set, the icon specified for the application
+as a whole is used instead (see the
+<application>
element's icon
attribute).
<application>
-element — is also the default icon for all the activity's intent filters (see the
-<intent-filter>
element's
-icon
attribute).
+The activity's icon — whether set here or by the
+<application>
+element — is also the default icon for all the activity's intent filters (see the
+<intent-filter>
element's
+icon
attribute).
<application>
element's
+If this attribute is not set, the label set for the application as a whole is
+used instead (see the <application>
element's
label
attribute).
<application>
element — is also the
-default label for all the activity's intent filters (see the
-<intent-filter>
element's
-label
attribute).
+The activity's label — whether set here or by the
+<application>
element — is also the
+default label for all the activity's intent filters (see the
+<intent-filter>
element's
+label
attribute).
{@link android.content.Context#startActivity startActivity()}
(unless the Intent object contains a
{@link android.content.Intent#FLAG_ACTIVITY_NEW_TASK}
@@ -433,7 +433,7 @@ Moreover, the device can hold only one instance of the activity at a time
singleTask
and singleInstance
— are
not appropriate for most applications,
since they result in an interaction model that is likely to be unfamiliar to
-users and is very different from most other applications.
+users and is very different from most other applications.
<manifest>
+<manifest>
element.
{@link android.app.Activity#finish finish()}
-method called) when the user navigates away from it and it's no longer
-visible on screen — "{@code true}" if it should be finished, and
+finished (its {@link android.app.Activity#finish finish()}
+method called) when the user navigates away from it and it's no longer
+visible on screen — "{@code true}" if it should be finished, and
"{@code false}" if not. The default value is "{@code false}".
android:name
attribute.
+
+<activity
+ android:name="com.example.app.ChildActivity"
+ android:label="@string/title_child_activity"
+ android:parentActivityName="com.example.myfirstapp.MainActivity" >
+ <!-- Parent activity meta-data to support API level 4+ -->
+ <meta-data
+ android:name="android.support.PARENT_ACTIVITY"
+ android:value="com.example.app.MainActivity" />
+</activity>
+
+
+{@link android.content.Context#startActivity startActivity()}
or
{@link android.app.Activity#startActivityForResult startActivityForResult()}
-has not been granted the specified permission, its intent will not be
+has not been granted the specified permission, its intent will not be
delivered to the activity.
<application>
+If this attribute is not set, the permission set by the
+<application>
element's
-permission
+permission
attribute applies to the activity. If neither attribute is set, the activity is
not protected by a permission.
<application>
element's
-process
-attribute can set a different default for all components. But each component
-can override the default, allowing you to spread your application across
+<application>
element's
+process
+attribute can set a different default process name for all components.
+
"{@code unspecified}"
The default value. The system chooses the orientation. The policy it
- uses, and therefore the choices made in specific contexts, may differ
+ uses, and therefore the choices made in specific contexts, may differ
from device to device.
"{@code behind}"
- The same orientation as the activity that's immediately beneath it in
+ The same orientation as the activity that's immediately beneath it in
the activity stack.
"{@code landscape}"
@@ -736,76 +759,76 @@ control whether your app can be installed when a device supports only certain or
{@link android.app.Activity#onSaveInstanceState onSaveInstanceState()}
-method is called. This method stores the current state of the activity in a
-{@link android.os.Bundle} object, which is then passed to
-{@link android.app.Activity#onCreate onCreate()}
when the activity
-is restarted. If this attribute is set to "{@code true}",
-{@code onSaveInstanceState()} may not be called and {@code onCreate()} will
-be passed {@code null} instead of the Bundle — just as it was when the
+Normally, before an activity is temporarily shut down to save resources, its
+{@link android.app.Activity#onSaveInstanceState onSaveInstanceState()}
+method is called. This method stores the current state of the activity in a
+{@link android.os.Bundle} object, which is then passed to
+{@link android.app.Activity#onCreate onCreate()}
when the activity
+is restarted. If this attribute is set to "{@code true}",
+{@code onSaveInstanceState()} may not be called and {@code onCreate()} will
+be passed {@code null} instead of the Bundle — just as it was when the
activity started for the first time.
allowTaskReparenting
-attribute) and the task that will house the activity when it is launched
-with the {@link android.content.Intent#FLAG_ACTIVITY_NEW_TASK}
+The affinity determines two things — the task that the activity is re-parented
+to (see the allowTaskReparenting
+attribute) and the task that will house the activity when it is launched
+with the {@link android.content.Intent#FLAG_ACTIVITY_NEW_TASK}
flag.
<application>
-element's
+If this attribute is not set, the activity inherits the affinity set
+for the application (see the
+<application>
+element's
taskAffinity
-attribute). The name of the default affinity for an application is
-the package name set by the
-<manifest>
+attribute). The name of the default affinity for an application is
+the package name set by the
+<manifest>
element.
{@link android.content.Context#setTheme setTheme()}
, and may also
-cause "starting" animations prior to the activity being launched (to better
+{@link android.content.Context#setTheme setTheme()}
, and may also
+cause "starting" animations prior to the activity being launched (to better
match what the activity actually looks like).
<application>
-element's
-theme
+If this attribute is not set, the activity inherits the theme set for the
+application as a whole — from the
+<application>
+element's
+theme
attribute. If that attribute is also not set, the default system theme is used. For more
information, see the Styles and Themes developer guide.
@@ -837,32 +860,32 @@ href="{@docRoot}guide/topics/ui/actionbar.html">Action Bar developer guide.<
-
+
<activity android:windowSoftInputMode="stateVisible|adjustResize" . . . >
Description
"{@code stateUnspecified}"
- The state of the soft keyboard (whether it is hidden or visible)
+ The state of the soft keyboard (whether it is hidden or visible)
is not specified. The system will choose an appropriate state or
- rely on the setting in the theme.
+ rely on the setting in the theme.
"{@code stateHidden}"
- The soft keyboard is hidden when the user chooses the activity
- — that is, when the user affirmatively navigates forward to the
+ The soft keyboard is hidden when the user chooses the activity
+ — that is, when the user affirmatively navigates forward to the
activity, rather than backs into it because of leaving another activity.
"{@code stateAlwaysHidden}"
- The soft keyboard is always hidden when the activity's main window
+ The soft keyboard is always hidden when the activity's main window
has input focus.
"{@code stateVisible}"
- The soft keyboard is visible when that's normally appropriate
+ The soft keyboard is visible when that's normally appropriate
(when the user is navigating forward to the activity's main window).
"{@code stateAlwaysVisible}"
- The soft keyboard is made visible when the user chooses the
- activity — that is, when the user affirmatively navigates forward
- to the activity, rather than backs into it because of leaving another
+ The soft keyboard is made visible when the user chooses the
+ activity — that is, when the user affirmatively navigates forward
+ to the activity, rather than backs into it because of leaving another
activity.
"{@code adjustUnspecified}"
- It is unspecified whether the activity's main window resizes
- to make room for the soft keyboard, or whether the contents
- of the window pan to make the currentfocus visible on-screen.
+ It is unspecified whether the activity's main window resizes
+ to make room for the soft keyboard, or whether the contents
+ of the window pan to make the current focus visible on-screen.
The system will automatically select one of these modes depending
- on whether the content of the window has any layout views that
- can scroll their contents. If there is such a view, the window
- will be resized, on the assumption that scrolling can make all
+ on whether the content of the window has any layout views that
+ can scroll their contents. If there is such a view, the window
+ will be resized, on the assumption that scrolling can make all
of the window's contents visible within a smaller area.
"{@code adjustResize}"
- The activity's main window is always resized to make room for
+ The activity's main window is always resized to make room for
the soft keyboard on screen.
"{@code adjustPan}"
The activity's main window is not resized to make room for the soft
- keyboard. Rather, the contents of the window are automatically
+ keyboard. Rather, the contents of the window are automatically
panned so that the current focus is never obscured by the keyboard
- and users can always see what they are typing. This is generally less
+ and users can always see what they are typing. This is generally less
desirable than resizing, because the user may need to close the soft
keyboard to get at and interact with obscured parts of the window.
@@ -938,12 +961,12 @@ This attribute was introduced in API Level 3.
noHistory
and
-windowSoftInputMode
, which were added in API
+windowSoftInputMode
, which were added in API
Level 3.<application>
+<application>
<activity-alias>
Design Guide
+
-
-
@@ -44,662 +49,600 @@ parent.link=index.html
Key classes
-
- Related samples
-
-
- See also
-
-
+
-
-
+
+
+{@code import android.support.v7.app.ActionBar}
+{@code import android.app.ActionBar}Remaining backward-compatible
-Adding the Action Bar
-
-<manifest ... >
- <uses-sdk android:minSdkVersion="4"
- android:targetSdkVersion="11" />
- ...
-</manifest>
-
+
+
-<activity android:theme="@style/Theme.AppCompat.Light" ... >
+ Removing the action bar
-
-<activity android:theme="@android:style/Theme.Holo.NoActionBar">
-
-
-
-ActionBar actionBar = {@link android.app.Activity#getActionBar()};
+ActionBar actionBar = {@link android.support.v7.app.ActionBarActivity#getSupportActionBar()};
actionBar.hide();
-Using a logo instead of an icon
+
+Adding Action Items
-
+<menu xmlns:android="http://schemas.android.com/apk/res/android" >
+ <item android:id="@+id/action_search"
+ android:icon="@drawable/ic_action_search"
+ android:title="@string/action_search"/>
+ <item android:id="@+id/action_compose"
+ android:icon="@drawable/ic_action_compose"
+ android:title="@string/action_compose" />
+</menu>
+
+
+
@Override
public boolean onCreateOptionsMenu(Menu menu) {
+ // Inflate the menu items for use in the action bar
MenuInflater inflater = getMenuInflater();
- inflater.inflate(R.menu.main_activity, menu);
- return true;
+ inflater.inflate(R.menu.main_activity_actions, menu);
+ return super.onCreateOptionsMenu(menu);
}
-
+<menu xmlns:android="http://schemas.android.com/apk/res/android"
+ xmlns:example.app="http://schemas.android.com/apk/res-auto" >
+ <item android:id="@+id/action_search"
+ android:icon="@drawable/ic_action_search"
+ android:title="@string/action_search"
+ example.app:showAsAction="ifRoom" />
+ ...
+</menu>
+
+
+
-<?xml version="1.0" encoding="utf-8"?>
-<menu xmlns:android="http://schemas.android.com/apk/res/android">
- <item android:id="@+id/menu_save"
- android:icon="@drawable/ic_menu_save"
- android:title="@string/menu_save"
- android:showAsAction="ifRoom|withText" />
-</menu>
+<item example.app:showAsAction="ifRoom|withText" ... />
-Choosing your action items
-
-Menu items vs. other app controls
-
-
-Handling clicks on action items
-
+@Override
+public boolean onOptionsItemSelected(MenuItem item) {
+ // Handle presses on the action bar items
+ switch (item.getItemId()) {
+ case R.id.action_search:
+ openSearch();
+ return true;
+ case R.id.action_compose:
+ composeMessage();
+ return true;
+ default:
+ return super.onOptionsItemSelected(item);
+ }
+}
+
+Using split action bar
-
+
-
+<style name="MyAppTheme" parent="Theme.AppCompat.Light">
+ <item name="windowSplitActionBar">true<item>
+</style>
+
-
+<manifest ...>
+ <activity android:theme="@style/MyAppTheme" ...>
+ ...
+</manifest ...>
+
+ Using the App Icon for Navigation
+Navigating Up with the App Icon
+
+ Design Guide
+ Using a logo instead of icon
-
-
-
-
@Override
-public boolean onOptionsItemSelected(MenuItem item) {
- switch (item.getItemId()) {
- case android.R.id.home:
- // app icon in action bar clicked; go home
- Intent intent = new Intent(this, HomeActivity.class);
- intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
- startActivity(intent);
- return true;
- default:
- return super.onOptionsItemSelected(item);
- }
+protected void onCreate(Bundle savedInstanceState) {
+ super.onCreate(savedInstanceState);
+ setContentView(R.layout.activity_details);
+
+ ActionBar actionBar = getSupportActionBar();
+ actionBar.setDisplayHomeAsUpEnabled(true);
+ ...
}
-
+
-intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_NEW_TASK);
+<application ... >
+ ...
+ <!-- The main/home activity (has no parent activity) -->
+ <activity
+ android:name="com.example.myfirstapp.MainActivity" ...>
+ ...
+ </activity>
+ <!-- A child of the main activity -->
+ <activity
+ android:name="com.example.myfirstapp.DisplayMessageActivity"
+ android:label="@string/title_activity_display_message"
+ android:parentActivityName="com.example.myfirstapp.MainActivity" >
+ <!-- Parent activity meta-data to support API level 7+ -->
+ <meta-data
+ android:name="android.support.PARENT_ACTIVITY"
+ android:value="com.example.myfirstapp.MainActivity" />
+ </activity>
+</application>
-Navigating up
-
-
-protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
+
Adding an Action View
-
<?xml version="1.0" encoding="utf-8"?>
-<menu xmlns:android="http://schemas.android.com/apk/res/android">
- <item android:id="@+id/menu_search"
- android:title="@string/menu_search"
- android:icon="@drawable/ic_menu_search"
- android:showAsAction="ifRoom|collapseActionView"
- android:actionViewClass="android.widget.SearchView" />
+<menu xmlns:android="http://schemas.android.com/apk/res/android"
+ xmlns:example.app="http://schemas.android.com/apk/res-auto" >
+ <item android:id="@+id/action_search"
+ android:title="@string/action_search"
+ android:icon="@drawable/ic_action_search"
+ example.app:showAsAction="ifRoom|collapseActionView"
+ example.app:actionViewClass="android.support.v7.widget.SearchView" />
</menu>
-
@Override
public boolean onCreateOptionsMenu(Menu menu) {
- getMenuInflater().inflate(R.menu.options, menu);
- SearchView searchView = (SearchView) menu.findItem(R.id.menu_search).getActionView();
+ getMenuInflater().inflate(R.menu.main_activity_actions, menu);
+ MenuItem searchItem = menu.findItem(R.id.action_search);
+ SearchView searchView = (SearchView) MenuItemCompat.getActionView(searchItem);
// Configure the search info and add any event listeners
...
return super.onCreateOptionsMenu(menu);
}
+menu.findItem(R.id.action_search).getActionView()
+Handling collapsible action views
-
-Supporting Android 3.0 with an action view
- Handling collapsible action views
-
@Override
@@ -708,7 +651,9 @@ public boolean onCreateOptionsMenu(Menu menu) {
MenuItem menuItem = menu.findItem(R.id.actionItem);
...
- menuItem.setOnActionExpandListener(new OnActionExpandListener() {
+ // When using the support library, the setOnActionExpandListener() method is
+ // static and accepts the MenuItem object as an argument
+ MenuItemCompat.setOnActionExpandListener(menuItem, new OnActionExpandListener() {
@Override
public boolean onMenuItemActionCollapse(MenuItem item) {
// Do something when collapsed
@@ -729,165 +674,169 @@ public boolean onCreateOptionsMenu(Menu menu) {
Adding an Action Provider
-
-<?xml version="1.0" encoding="utf-8"?>
-<menu xmlns:android="http://schemas.android.com/apk/res/android">
- <item android:id="@+id/menu_share"
- android:title="@string/share"
- android:showAsAction="ifRoom"
- android:actionProviderClass="android.widget.ShareActionProvider" />
- ...
-</menu>
-
+Using the ShareActionProvider
-
+<?xml version="1.0" encoding="utf-8"?>
+<menu xmlns:android="http://schemas.android.com/apk/res/android"
+ xmlns:example.app="http://schemas.android.com/apk/res-auto" >
+ <item android:id="@+id/action_share"
+ android:title="@string/share"
+ example.app:showAsAction="ifRoom"
+ example.app:actionProviderClass="android.support.v7.widget.ShareActionProvider"
+ />
+ ...
+</menu>
+
-
private ShareActionProvider mShareActionProvider;
-...
@Override
public boolean onCreateOptionsMenu(Menu menu) {
- mShareActionProvider = (ShareActionProvider) menu.findItem(R.id.menu_share).getActionProvider();
+ getMenuInflater().inflate(R.menu.main_activity_actions, menu);
- // If you use more than one ShareActionProvider, each for a different action,
- // use the following line to specify a unique history file for each one.
- // mShareActionProvider.setShareHistoryFileName("custom_share_history.xml");
+ // Set up ShareActionProvider's default share intent
+ MenuItem shareItem = menu.findItem(R.id.action_share);
+ mShareActionProvider = (ShareActionProvider)
+ MenuItemCompat.getActionProvider(shareItem);
+ mShareActionProvider.setShareIntent(getDefaultIntent());
- // Set the default share intent
- mShareActionProvider.setShareIntent(getDefaultShareIntent());
+ return super.onCreateOptionsMenu(menu);
+}
- return true;
+/** Defines a default (dummy) share intent to initialize the action provider.
+ * However, as soon as the actual content to be used in the intent
+ * is known or changes, you must update the share intent by again calling
+ * mShareActionProvider.{@link
+ * android.support.v7.widget.ShareActionProvider#setShareIntent setShareIntent()}
+ */
+private Intent getDefaultIntent() {
+ Intent intent = new Intent(Intent.ACTION_SEND);
+ intent.setType("image/*");
+ return intent;
}
-// When you need to update the share intent somewhere else in the app, call
-// mShareActionProvider.{@link android.widget.ShareActionProvider#setShareIntent setShareIntent()}
-Creating a custom action provider
-
-
@@ -927,62 +879,68 @@ href="{@docRoot}resources/samples/ApiDemos/src/com/example/android/apis/app/Acti
-public View onCreateActionView() {
+public View onCreateActionView(MenuItem forItem) {
// Inflate the action view to be shown on the action bar.
LayoutInflater layoutInflater = LayoutInflater.from(mContext);
View view = layoutInflater.inflate(R.layout.action_provider, null);
@@ -903,18 +852,21 @@ public View onCreateActionView() {
true
), in which case, the system does not call {@link
+android.support.v4.view.ActionProvider#onPerformDefaultAction()}.
+
Adding Navigation Tabs
+
+
-Design Guide
+ Also read
+
-
-Adding Drop-down Navigation
-Adding Drop-down Navigation
-
+
+
-ActionBar actionBar = getActionBar();
-actionBar.setNavigationMode(ActionBar.NAVIGATION_MODE_LIST);
-
-
actionBar.setListNavigationCallbacks(mSpinnerAdapter, mNavigationCallback);
Styling the Action Bar
-Styling the Action Bar
+
+General appearance
+
@@ -1350,34 +1348,40 @@ href="{@docRoot}resources/samples/HoneycombGallery/index.html"
+
+
@@ -1334,13 +1332,13 @@ in your XML layout. For example:
@@ -1385,16 +1389,25 @@ href="#ActionView">action views. (Added in API level 14.)
@@ -1402,82 +1415,93 @@ href="#ActionView">action views. (Added in API level 14.)
+Example theme
+
+
<?xml version="1.0" encoding="utf-8"?>
<resources>
<!-- the theme applied to the application or activity -->
- <style name="CustomActivityTheme" parent="@android:style/Theme.Holo">
- <item name="android:actionBarTabTextStyle">@style/CustomTabTextStyle</item>
- <item name="android:actionBarDivider">@drawable/ab_divider</item>
- <item name="android:actionBarItemBackground">@drawable/ab_item_background</item>
+ <style name="CustomActionBarTheme"
+ parent="@style/Theme.AppCompat.Light">
+ <item name="android:actionBarStyle">@style/MyActionBar</item>
+ <item name="android:actionBarTabTextStyle">@style/TabTextStyle</item>
+ <item name="android:actionMenuTextColor">@color/actionbar_text</item>
+
+ <!-- Support library compatibility -->
+ <item name="actionBarStyle">@style/MyActionBar</item>
+ <item name="actionBarTabTextStyle">@style/TabTextStyle</item>
+ <item name="actionMenuTextColor">@color/actionbar_text</item>
</style>
- <!-- style for the action bar tab text -->
- <style name="CustomTabTextStyle" parent="@android:style/TextAppearance.Holo">
- <item name="android:textColor">#2456c2</item>
+ <!-- general styles for the action bar -->
+ <style name="MyActionBar"
+ parent="@style/Widget.AppCompat.ActionBar">
+ <item name="android:titleTextStyle">@style/TitleTextStyle</item>
+ <item name="android:background">@drawable/actionbar_background</item>
+ <item name="android:backgroundStacked">@drawable/actionbar_background</item>
+ <item name="android:backgroundSplit">@drawable/actionbar_background</item>
+
+ <!-- Support library compatibility -->
+ <item name="titleTextStyle">@style/TitleTextStyle</item>
+ <item name="background">@drawable/actionbar_background</item>
+ <item name="backgroundStacked">@drawable/actionbar_background</item>
+ <item name="backgroundSplit">@drawable/actionbar_background</item>
</style>
-</resources>
-
-
-<application android:theme="@style/CustomActivityTheme" ... />
-Advanced styling
+
+<application android:theme="@style/CustomActionBarTheme" ... />
+
-
-<?xml version="1.0" encoding="utf-8"?>
-<resources>
- <!-- the theme applied to the application or activity -->
- <style name="CustomActivityTheme" parent="@android:style/Theme.Holo">
- <item name="android:actionBarStyle">@style/MyActionBar</item>
- <!-- other activity and action bar styles here -->
- </style>
-
- <!-- style for the action bar backgrounds -->
- <style name="MyActionBar" parent="@android:style/Widget.Holo.ActionBar">
- <item name="android:background">@drawable/ab_background</item>
- <item name="android:backgroundStacked">@drawable/ab_background</item>
- <item name="android:backgroundSplit">@drawable/ab_split_background</item>
- </style>
-</resources>
+<activity android:theme="@style/CustomActionBarTheme" ... />
+