diff options
Diffstat (limited to 'docs/html/guide/practices')
22 files changed, 343 insertions, 653 deletions
diff --git a/docs/html/guide/practices/compatibility.jd b/docs/html/guide/practices/compatibility.jd index bb7a72e..5e514c4 100644 --- a/docs/html/guide/practices/compatibility.jd +++ b/docs/html/guide/practices/compatibility.jd @@ -7,7 +7,7 @@ page.title=Android Compatibility <h2>See also</h2> <ol> <li><a -href="{@docRoot}guide/appendix/market-filters.html">Market Filters</a></li> +href="{@docRoot}guide/appendix/market-filters.html">Filtering on Google Play</a></li> <li><a href="{@docRoot}guide/topics/resources/providing-resources.html#AlternativeResources">Providing Alternative Resources</a></li> <li><a @@ -39,7 +39,7 @@ variety of hardware.</p> your apps to do that, while at the same time letting you maintain control of what types of devices your app is available to. With a bit of forethought and some minor changes in your app's manifest file, you can ensure that users -whose devices can’t run your app will never see it in the Android Market, and +whose devices can’t run your app will never see it on Google Play, and will not get in trouble by downloading it. This page explains how you can control which devices have access to your apps, and how to prepare your apps to make sure they reach the right audience.</p> @@ -64,7 +64,7 @@ every class and every API for that API level.</p> corresponding hardware or feature. But that’s not a problem: we also designed Android to prevent apps from being visible to devices which don’t have features the apps require. We’ve built support for this right into the SDK tools, and -it’s part of the Android platform itself, as well as Android Market.</p> +it’s part of the Android platform itself, as well as part of Google Play.</p> <p>As a developer, you have complete control of how and where your apps are available. Android provides tools as a first-class part of the platform that let @@ -79,9 +79,9 @@ only the devices capable of running them.</p> <li>You state the features your app requires by declaring <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><code><uses-feature></code></a> elements its manifest file.</li> -<li>Devices are required to declare the features they include to Android -Market.</li> -<li>Android Market uses your app’s stated requirements to filter it from devices +<li>Devices are required to declare the features they include to Google +Play.</li> +<li>Google Play uses your app’s stated requirements to filter it from devices that don’t meet those requirements.</li> </ol> @@ -103,24 +103,24 @@ instead use the fine-grained controls Android provides.</p> <div class="sidebox-wrapper"> <img id="rule" src="{@docRoot}assets/images/grad-rule-qv.png"> <div id="qv-sub-rule"> - <img src="{@docRoot}assets/images/icon_market.jpg" style="float:left;margin:0;padding:0;"> - <p style="color:#669999;">Filtering on Android Market</p> + <img src="{@docRoot}assets/images/icon_play.png" style="float:left;margin:0;padding:0;"> + <p style="color:#669999;">Filtering on Google Play</p> - <p>Android Market filters the applications that are visible to users, so + <p>Google Play filters the applications that are visible to users, so that users can see and download only those applications that are compatible with their devices.</p> - <p style="margin-top:1em;">One of the ways Market filters applications is by -feature compatibility. To do this, Market checks the + <p style="margin-top:1em;">One of the ways Google Play filters applications is by +feature compatibility. To do this, Google Play checks the <code><uses-feature></code> elements in each application's manifest, to -establish the app's feature needs. Market then shows or hides the application to +establish the app's feature needs. Google Play then shows or hides the application to each user, based on a comparison with the features available on the user's device. <p style="margin-top:1em;">For information about other filters that you can use to control the availability of your apps, see the -<a href="{@docRoot}guide/appendix/market-filters.html">Market -Filters</a> document.</p> +<a href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a> +document.</p> </div> </div> @@ -142,8 +142,8 @@ future versions, new feature IDs will be added as well.</p> <p>When you write your application, you specify which features your app requires by listing their feature IDs in <code><uses-feature></code> elements in -the <code>AndroidManifest.xml</code> file. This is the information that Android -Market uses to match your app to devices that can run it. For instance, if you +the <code>AndroidManifest.xml</code> file. This is the information that Google +Play uses to match your app to devices that can run it. For instance, if you state that your app requires android.software.live_wallpapers, it won’t be shown to devices that don’t support Live Wallpapers.</p> @@ -170,12 +170,12 @@ audience size and minimizing development costs.</p> business or legal reasons. For instance, an app that displays train schedules for the London Underground is unlikely to be useful to users outside the United Kingdom. Other apps might not be permitted in certain countries for business or -legal reasons. For cases such as these, Android Market itself provides +legal reasons. For cases such as these, Google Play itself provides developers with filtering options that allow them control their app’s availability for non-technical reasons.</p> -<p>The help information for Android Market provides full details, but in a -nutshell, developers can use the Market publisher UI to:</p> +<p>The help information for Google Play provides full details, but in a +nutshell, developers can use the Google Play publisher UI to:</p> <ul> <li>List the countries an app is available in.</li> @@ -185,7 +185,7 @@ nutshell, developers can use the Market publisher UI to:</p> <p>Filtering for technical compatibility (such as required hardware components) is always based on information contained within your <code>.apk</code> file. But filtering for non-technical reasons (such as geographic restrictions) is always -handled in the Market user interface.</p> +handled in the Google Play user interface.</p> <h3 id="futureproofing">Future-proofing</h3> @@ -206,7 +206,7 @@ capability, though a (fixed-focus) camera was still required. Some apps such as barcode scanners do not function as well with cameras that do not auto-focus. To prevent users from having a bad experience with those apps, existing apps that obtain permission to use the Camera were assumed by default to require -auto-focus. This allowed Android Market to filter those apps from devices that +auto-focus. This allowed Google Play to filter those apps from devices that lack auto-focus.</li> <li>Android 2.2, meanwhile, allowed the microphone to be optional on some diff --git a/docs/html/guide/practices/design/accessibility.html b/docs/html/guide/practices/design/accessibility.html new file mode 100644 index 0000000..0fa7b32 --- /dev/null +++ b/docs/html/guide/practices/design/accessibility.html @@ -0,0 +1,11 @@ +<html> +<head> +<meta http-equiv="refresh" +content="0;url=http://developer.android.com/guide/topics/ui/accessibility/index.html"> +<title>Redirecting...</title> +</head> +<body> +<p>You should be redirected. Please <a +href="http://developer.android.com/guide/topics/ui/accessibility/index.html">click here</a>.</p> +</body> +</html>
\ No newline at end of file diff --git a/docs/html/guide/practices/design/accessibility.jd b/docs/html/guide/practices/design/accessibility.jd deleted file mode 100644 index a66a974..0000000 --- a/docs/html/guide/practices/design/accessibility.jd +++ /dev/null @@ -1,353 +0,0 @@ -page.title=Designing for Accessibility -@jd:body - - -<div id="qv-wrapper"> -<div id="qv"> - - <h2>Quickview</h2> - <ul> - <li>To make your application more accessible, you should make sure your UI is navigable -using a directional controller and your widgets provide content descriptions</li> - <li>If you implement a custom view, you should ensure that it delivers the appropriate -accessibility events during user interaction</li> - </ul> - - <h2>In this document</h2> - <ol> - <li><a href="#Navigation">Allow Navigation with a Directional Controller</a> - <ol> - <li><a href="#FocusOrder">Controlling focus order</a></li> - <li><a href="#ClickingDpad">Clicking with a directional controller</a></li> - </ol> - </li> - <li><a href="#LabelInputs">Label Your Input Widgets</a></li> - <li><a href="#UiBestPractices">Follow Android UI Best Practices</a></li> - <li><a href="#CustomViews">Send Accessibility Events from Custom View Components</a></li> - <li><a href="#Test">Test Your Application’s Accessibility</a></li> - </ol> - - <h2>Key classes</h2> - <ol> - <li>{@link android.view.accessibility.AccessibilityEvent}</li> - <li>{@link android.view.accessibility.AccessibilityEventSource}</li> - </ol> - - <h2>Related samples</h2> - <ol> - <li><a -href="{@docRoot}resources/samples/AccessibilityService/index.html">Accessibility Service</a></li> - </ol> - -</div> -</div> - - - -<p>Many Android users have disabilities that require them to interact with their Android devices in -different ways. These include users who have visual, physical or age-related disabilities that -prevent them from fully using or seeing a touchscreen.</p> - -<p>Android provides an accessibility layer that helps these users navigate their Android-powered -devices more easily. Android's accessibility services provide things like text-to-speech, haptic -feedback, and trackball/d-pad navigation that augment the user experience.</p> - -<p>Your application should follow the guidelines in this document to ensure that it provides a -good experience for users with disabilities. Following these two basic rules will solve most -access-related problems:</p> - -<ul> -<li>Make all of your user interface controls accessible with a trackball or directional -controller (d-pad).</li> -<li>Label your {@link android.widget.ImageButton}, {@link android.widget.EditText}, and other input -widgets using the <a -href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription">{@code -android:contentDescription}</a> attribute.</li> -</ul> - - - -<h2 id="Navigation">Allow Navigation with a Directional Controller</h2> - -<p>Many Android devices come with some sort of directional controller, such as:</p> -<ul> -<li>A clickable trackball that users can move in any direction</li> -<li>A clickable d-pad that allows users to navigate in four directions.</li> -<li>Arrow keys and an OK button that’s equivalent to clicking a trackball or d-pad.</li> -</ul> - -<p>All of these directional controllers allow users to navigate the screen without using the -touchscreen. On some devices, a user can also navigate to the top or bottom of a list by holding -down the <em>alt</em> key while pressing a discrete key for up or down.</p> - -<p>A directional controller is the primary means of navigation for users with visual or some -physical impairments (and also for users without impairments when using devices that don't -have a touchscreen). You should verify that all UI controls in your application are -accessible without using the touchscreen and that clicking with the center button (or OK button) has -the same effect as touching the controls on the touchscreen.</p> - -<p>A UI control (also called a "widget") is accessible using directional controls when it's -"focusable" property is "true." This means that users can focus on the widget using the directional -controls and then interact with it. Widgets provided by the Android APIs are focusable by default -and visually indicate focus by changing the widget visual appearance in some way.</p> - -<p>Android provides several APIs that let you control whether a widget is focusable and even -request that a widget be given focus. Such methods include:</p> - -<ul> - <li>{@link android.view.View#setFocusable setFocusable()}</li> - <li>{@link android.view.View#isFocusable isFocusable()}</li> - <li>{@link android.view.View#requestFocus requestFocus()}</li> -</ul> - -<p>When working with a view that is not focusable by default, you can make it focusable from the XML -layout file by setting the <a -href="{@docRoot}reference/android/view/View.html#attr_android:focusable">{@code -android:focusable}</a> attribute to {@code "true"}.</p> - - - -<h3 id="FocusOrder">Controlling focus order</h3> - -<p>When the user navigates in any direction using the directional controls, focus is passed from one -view to another, as determined by the focus ordering. The ordering of the focus movement is based on -an algorithm that finds the nearest neighbor in a given direction. In rare cases, the default -algorithm may not match the order that you intended for your UI. In these situations, you can -provide explicit overrides to the ordering using the following XML attributes in the layout -file:</p> - -<dl> - <dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusDown" ->{@code android:nextFocusDown}</a></dt> - <dd>Defines the next view to receive focus when the user navigates down.</dd> - <a><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusLeft" ->{@code android:nextFocusLeft}</a></dt> - <dd>Defines the next view to receive focus when the user navigates left.</dd> - <dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusRight" ->{@code android:nextFocusRight}</a></dt> - <dd>Defines the next view to receive focus when the user navigates right.</dd> - <dt><a href="{@docRoot}reference/android/view/View.html#attr_android:nextFocusUp" ->{@code android:nextFocusUp}</a></dt> - <dd>Defines the next view to receive focus when the user navigates up.</dd> -</dl> - -<p>For example, here is an XML layout that contains a focusable {@link android.widget.TextView}. -While the {@link android.widget.TextView} is located to the right of the {@link -android.widget.EditText}, it can now be reached by pressing the down arrow when focus is on the -{@link android.widget.EditText}: </p> - -<pre> -<LinearLayout android:orientation="horizontal" - ... > - <EditText android:id="@+id/edit" - android:nextFocusDown=”@+id/text” - ... /> - <TextView android:id="@+id/text" - android:focusable=”true” - android:text="Hello, I am a focusable TextView" - android:nextFocusUp=”@id/edit” - ... /> -</LinearLayout> -</pre> - -<p>When modifying this ordering, be sure that the navigation works as expected in all directions -from each widget and when navigating in reverse (to get back to where you came from).</p> - -<p>You can also modify the focus ordering at runtime, using methods in the {@link -android.view.View} class, such as {@link android.view.View#setNextFocusDownId -setNextFocusDownId()} and {@link android.view.View#setNextFocusRightId -setNextFocusRightId()}.</p> - - -<h3 id="ClickingDpad">Clicking with a directional controller</h3> - -<p>On most devices, clicking a view using a directional controller sends a {@link -android.view.KeyEvent} with {@link android.view.KeyEvent#KEYCODE_DPAD_CENTER} to the view currently -in focus. Make sure this event has the same effect as touching the view on the touchscreen. All -standard Android views already handle {@link android.view.KeyEvent#KEYCODE_DPAD_CENTER} -appropriately.</p> - -<p>If possible, also treat the {@link android.view.KeyEvent#KEYCODE_ENTER} event the same as -{@link android.view.KeyEvent#KEYCODE_DPAD_CENTER}. That makes interaction much easier from a full -keyboard.</p> - - - - -<h2 id="LabelInputs">Label Your Input Widgets</h2> - -<p>Many input widgets rely on visual cues to inform the user of their meaning. For example, a -notepad application might use an {@link android.widget.ImageButton} with a picture of a plus sign to -indicate that the user can add a new note. Or, an {@link android.widget.EditText} may have -a label near it that indicates its purpose. When a visually impaired user accesses your -application, these visual cues are often useless.</p> - -<p>To provide textual information about these widgets (as an alternative to the visual cues), you -should use the <a href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription" ->{@code android:contentDescription}</a> attribute. The text you provide in this attribute -is not visible on the screen, but if a user has enabled accessibility speech tools then the -description in this attribute is read aloud to the user.</p> - -<p>You should set the <a -href="{@docRoot}reference/android/view/View.html#attr_android:contentDescription" >{@code -android:contentDescription}</a> attribute on every {@link android.widget.ImageButton}, {@link -android.widget.EditText}, {@link android.widget.CheckBox}, and on any other input widgets that might -benefit users with extra information.</p> - -<p>For example, the following {@link android.widget.ImageButton} sets the content description for -the plus button to the {@code add_note} string resource, which might be defined in English as -“Add note":</p> - -<pre> -<ImageButton - android:id=”@+id/add_entry_button” - android:src=”@drawable/plus” - android:contentDescription=”@string/add_note”/> -</pre> - -<p>This way, when using speech accessibility tools, the user hears "Add note" when focused on -this widget.</p> - - - -<h2 id="UiBestPractices">Follow Android UI Best Practices</h2> - -<p>You can make it easier for users to learn how to use your application by developing a user -interface that complies with Android's standard interaction patterns, instead of creating your own -or using interaction patterns from another platform. This consistency is especially important for -many disabled users, as they may have less contextual information available to try to understand -your application’s interface.</p> - -<p>Specifically, you should:</p> - -<ul> -<li>Use the platform's built-in widgets and layouts whenever possible, as these views provide -accessibility support by default.</li> -<li>Use the <a href="{@docRoot}guide/topics/ui/menus.html#options-menu">Options Menu</a> as an -alternative to complex touchscreen tasks.</li> -<li>Make sure the BACK button correctly moves the user back one logical step in the <a -href="{@docRoot}guide/topics/fundamentals/tasks-and-back-stack.html">task's back stack</a> or the -activity's back stack of fragments (when <a -href="{@docRoot}guide/topics/fundamentals/fragments.html#Transactions">performing fragment -transactions</a>), as appropriate.</li> -</ul> - - - -<h2 id="CustomViews">Send Accessibility Events from Custom View Components</h2> - -<p>If your application requires that you create a <a -href="{@docRoot}guide/topics/ui/custom-components.html">custom view component</a>, you may need to -do some additional work to ensure that your view is accessible. Specifically, you should make sure -that your view implements the {@link android.view.accessibility.AccessibilityEventSource} -interface and emits {@link android.view.accessibility.AccessibilityEvent}s at the proper times, -and that each {@link android.view.accessibility.AccessibilityEvent} contains relevant information -about the state of the view.</p> - -<p>Events are emitted whenever something notable happens in the user interface. Currently, there -are five types of accessibility events that a view should send to the system as the user interacts -with it:</p> - -<dl> -<dt>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_CLICKED}</dt> -<dd>Indicates that the user clicked on the view (for example, the user selects a button).</dd> - -<dt>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_LONG_CLICKED}</dt> -<dd>Indicates that the user performed a long press on the view. </dd> - -<dt>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_SELECTED}</dt> -<dd>Indicates that the user selected an item from within the view. This is usually used in the -context of an {@link android.widget.AdapterView}.</dd> - -<dt>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_FOCUSED}</dt> -<dd>Indicates that the user moved the focus to the view.</dd> - -<dt>{@link android.view.accessibility.AccessibilityEvent#TYPE_VIEW_TEXT_CHANGED}</dt> -<dd>Indicates that the text or contents of the view changed.</dd> -</dl> - - -<p>The basic {@link android.view.View} class implements {@link -android.view.accessibility.AccessibilityEventSource} and emits these events at the proper time in -the standard cases. Your custom view should extend from {@link android.view.View} (or one of its -subclasses) to take advantage of these default implementations.</p> - -<p>Depending on the specifics of your custom view, your view may need to emit one of these events at -a different time than the default {@link android.view.View} implementation. To do so, simply call -{@link android.view.accessibility.AccessibilityEventSource#sendAccessibilityEvent -sendAccessibilityEvent()} with the specific event type at the correct time.</p> - -<p>For example, say you are implementing a custom slider bar that allows the user to select a -numeric value by pressing the left or right arrows. This view should emit an event of type {@link -android.view.accessibility.AccessibilityEvent#TYPE_VIEW_TEXT_CHANGED} whenever the slider value -changes:</p> - -<pre> -@Override -public boolean onKeyUp (int keyCode, KeyEvent event) { - if (keyCode == KeyEvent.KEYCODE_DPAD_LEFT) { - mCurrentValue--; - sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_TEXT_CHANGED); - return true; - } - ... -} -</pre> - -<p>Each {@link android.view.accessibility.AccessibilityEvent} has a set of required properties that -describe the current state of the view. These properties include things like the view’s class name, -text and checked state. The specific properties required for each event type are described in the -{@link android.view.accessibility.AccessibilityEvent} documentation. The {@link android.view.View} -implementation will fill in default values for these properties. Most of these values, like the -class name and event timestamp, will not need to be changed. However, depending on the specifics of -your custom view, you may want to provide a different value for one or more of the properties. For -example, your view may have additional state information that you want to add to the event text.</p> - -<p>The {@link android.view.View#dispatchPopulateAccessibilityEvent -dispatchPopulateAccessibilityEvent()} method in {@link android.view.View} provides a hook for making -changes to the {@link android.view.accessibility.AccessibilityEvent} object before it is -emitted.</p> - -<p>In the above slider bar example, the view should add the current value of the slider bar to the -text of the event:</p> - -<pre> -@Override -public boolean dispatchPopulateAccessibilityEvent(final AccessibilityEvent event) { - super.dispatchPopulateAccessibilityEvent(event); - if (!isShown()) { - return false; - } - CharSequence text = String.valueOf(mCurrentValue); - if (text.length() > AccessibilityEvent.MAX_TEXT_LENGTH) { - text = text.subSequence(0, AccessiblityEvent.MAX_TEXT_LENGTH); - } - event.getText().add(text); - return true; -} -</pre> - - -<h2 id="Test">Test Your Application’s Accessibility</h2> - -<p>You can simulate the experience for many users by enabling an accessibility service that speaks -as you move around the screen. One such service is <a -href="https://market.android.com/details?id=com.google.android.marvin.talkback">TalkBack</a>, by the -<a href="http://code.google.com/p/eyes-free/">Eyes-Free Project</a>. It comes preinstalled on many -Android-powered devices, but is also available for free from <a -href="https://market.android.com/details?id=com.google.android.marvin.talkback">Android -Market</a>.</p> - -<p>This service requires that you have a text-to-speech engine installed on your phone. You can -verify if you have one installed in the <strong>Text-to-speech</strong> settings menu by selecting -<strong>Listen to an example</strong>. If you do not hear anything spoken, install the required -voice data by selecting <strong>Install voice data</strong>.</p> - -<p>Once text-to-speech is functioning correctly, you can enable TalkBack (or another accessibility -service) in the <strong>Accessibility</strong> settings menu. Enable both -<strong>Accessibility</strong> and <strong>TalkBack</strong>. As you navigate about the device, you -should now hear spoken feedback.</p> - -<p>You can now attempt to use your application as a blind user would. As you move around using only -the directional controller, make sure that the spoken feedback you hear makes sense and is -sufficient to navigate the application without any visual cues.</p> diff --git a/docs/html/guide/practices/optimizing-for-3.0.jd b/docs/html/guide/practices/optimizing-for-3.0.jd index 39662f1..d6c621e 100644 --- a/docs/html/guide/practices/optimizing-for-3.0.jd +++ b/docs/html/guide/practices/optimizing-for-3.0.jd @@ -108,7 +108,7 @@ SDK with the new platform:</p> SDK starter package now</a>.)</p> <ol> - <li><a href="{@docRoot}sdk/adding-components.html#launching">Launch the Android SDK and AVD + <li><a href="{@docRoot}sdk/adding-components.html#launching">Launch the Android SDK Manager</a> and install the following: <ul> <li>SDK Platform Android 3.0</li> @@ -147,7 +147,7 @@ Android 3.0, the emulator is still best way to evaluate your application's appea functionality on Android 3.0.</p> <p class="note"><strong>Tip:</strong> To improve the startup time for the emulator, enable snapshots -for the AVD when you create it with the SDK and AVD Manager (there's a checkbox in the AVD creator +for the AVD when you create it with the AVD Manager (there's a checkbox in the AVD creator to <strong>Enable</strong> snapshots). Then, start the AVD from the AVD manager and check <b>Launch from snapshot</b> and <b>Save to snapshot</b>. This way, when you close the emulator, a snapshot of the AVD state is saved and used to quickly relaunch the AVD next time. However, when you choose to @@ -281,7 +281,7 @@ to help you add features from Android 3.0 without requiring you to change your < href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">{@code android:minSdkVersion}</a> or build target, we're providing a static library called the <a href="{@docRoot}sdk/compatibility-library.html">Compatibility Library</a> -(downloadable from the AVD and SDK Manager).</p> +(downloadable from the Android SDK Manager).</p> <p>This library includes APIs for <a href="{@docRoot}guide/topics/fundamentals/fragments.html">fragments</a>, <a href="{@docRoot}guide/topics/fundamentals/loaders.html">loaders</a>, and some updated classes. By @@ -421,7 +421,7 @@ href="{@docRoot}sdk/android-3.0.html">Android 3.0 Platform</a> document.</p> href="{@docRoot}sdk/android-3.0.html#api">Android 3.0 Platform</a> document also have accompanying samples that allow you to preview the effects and can help you understand how to use them. To get the samples, download them from the SDK repository <a href="{@docRoot}sdk/adding-components.html" ->using the Android SDK and AVD Manager</a>. After downloading the samples ("Samples for SDK API +>using the Android SDK Manager</a>. After downloading the samples ("Samples for SDK API 11"), you can find them in <code><sdk_root>/samples/android-11/</code>. The following list provides links to the browsable source code for some of the samples:</p> @@ -481,7 +481,7 @@ and densities.</p> configurations of screen size and density, you can instead choose to limit the distribution of your application to certain types of screens, such as only tablets or only mobile devices. To do so, you can add elements to your Android manifest file that enable filtering based on screen configuration -by external services such as Android Market.</p> +by external services such as Google Play.</p> <p>However, before you decide to restrict your application to certain screen configurations, you should understand the techniques for <a @@ -517,14 +517,14 @@ screens, you can declare the element in your manifest like this:</p> </manifest> </pre> -<p>External services such as Android Market read this manifest element and use it to ensure that +<p>External services such as Google Play read this manifest element and use it to ensure that your application is available only to devices with an extra large screen.</p> <p class="note"><strong>Note:</strong> If you use the <a href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code <supports-screens>}</a> element for the reverse scenario (when your application is not compatible with <em>larger</em> screens) and set the larger screen size attributes to {@code "false"}, then -external services such as Android Market <strong>do not</strong> apply filtering. Your application +external services such as Google Play <strong>do not</strong> apply filtering. Your application will still be available to larger screens, but when it runs, it will not fill the screen—the system will draw it in a "postage stamp" window that's the same relative size as the screen size that your application does support. If you want to prevent your application from being downloaded on @@ -541,7 +541,7 @@ larger devices to download the version designed for smaller screens. In such a c use the <a href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code <compatible-screens>}</a> element to manage the distribution of your application based on the combination of screen size and density. External services such as -Android Market uses this information to apply filtering to your application, so that only devices +Google Play uses this information to apply filtering to your application, so that only devices that have a screen configuration with which you declare compatibility can download your application.</p> @@ -551,7 +551,7 @@ which each specify a screen configuration with which your application is compati the {@code android:screenSize} and {@code android:screenDensity} attributes. Each {@code <screen>} element <strong>must include both attributes</strong> to specify an individual screen configuration—if either attribute is missing, then the element is invalid -(external services such as Android Market will ignore it).</p> +(external services such as Google Play will ignore it).</p> <p>For example, if your application is compatible with only small and normal screens, regardless of screen density, then you must specify eight different {@code <screen>} elements, @@ -613,7 +613,7 @@ orientation, you should update your application to support landscape.</p></li> <li><a href="#Telephony">Not all devices have telephony or other features</a> <p>If your application declares the {@code "android.hardware.telephony"} feature in the manifest, then it will not be available to devices that do not offer telephony (such as tablets), based on -Android Market filtering. If your application can function properly without telephony, you should +Google Play filtering. If your application can function properly without telephony, you should update your application to gracefully disable the telephony features when not available on a device.</p></li> </ul> @@ -682,7 +682,7 @@ your applications. For example:</p> <pre><uses-feature android:name="android.hardware.telephony" /></pre> <p>By default, this declares that your application <em>requires</em> telephony features. So, -external services such as Android Market use this information to filter your application from +external services such as Google Play use this information to filter your application from devices that do not offer telephony.</p> <p>If, however, your application uses, but does not require the feature, you should diff --git a/docs/html/guide/practices/screens-distribution.jd b/docs/html/guide/practices/screens-distribution.jd index 60c9c95..a7c4a8e 100644 --- a/docs/html/guide/practices/screens-distribution.jd +++ b/docs/html/guide/practices/screens-distribution.jd @@ -37,7 +37,7 @@ href="{@docRoot}guide/practices/optimizing-for-3.0.html">Optimizing Apps for And configurations of screen size and density, you can instead choose to limit the distribution of your application to certain types of screens, such as only tablets and other large devices or only handsets and similar-sized devices. To do so, you can enable filtering by external services such as -Android Market by adding elements to your manifest file that specify the screen configurations your +Google Play by adding elements to your manifest file that specify the screen configurations your application supports.</p> <p>However, before you decide to restrict your application to certain screen configurations, you @@ -58,7 +58,7 @@ might discover that your application can't scale up well or perhaps you've decid versions of your application for different screen configurations. In such a case, you can use the <a href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code <compatible-screens>}</a> element to manage the distribution of your application based on -combinations of screen size and density. External services such as Android Market use this +combinations of screen size and density. External services such as Google Play use this information to apply filtering to your application, so that only devices that have a screen configuration with which you declare compatibility can download your application.</p> @@ -68,7 +68,7 @@ configuration with which you declare compatibility can download your application compatible, using both the {@code android:screenSize} and {@code android:screenDensity} attributes. Each {@code <screen>} element <strong>must include both attributes</strong> to specify an individual screen configuration—if either attribute is missing, then the element is invalid -(external services such as Android Market will ignore it).</p> +(external services such as Google Play will ignore it).</p> <p>For example, if your application is compatible with only small and normal size screens, regardless of screen density, you must specify eight different {@code <screen>} elements, @@ -173,7 +173,7 @@ Tools for Managing Screen Sizes</a>.</p> href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code <supports-screens>}</a> element for the reverse scenario (when your application is not compatible with <em>larger</em> screens) and set the larger screen size attributes to {@code "false"}, then -external services such as Android Market <strong>do not</strong> apply filtering. Your application +external services such as Google Play <strong>do not</strong> apply filtering. Your application will still be available to larger screens, but when it runs, it will not resize to fit the screen. Instead, the system will emulate a handset screen size (about 320dp x 480dp; see <a href="{@docRoot}guide/practices/screen-compat-mode.html">Screen Compatibility Mode</a> for more @@ -197,13 +197,13 @@ configurations.</p> <h2 id="MultiApks">Publishing Multiple APKs for Different Screens</h2> -<p>Although we recommend that you publish one APK for your application, Android Market allows +<p>Although we recommend that you publish one APK for your application, Google Play allows you to publish multiple APKs for the same application when each APK supports a different set of screen configurations (as declared in the manifest file). For example, if you want to publish both a handset version and a tablet version of your application, but you're unable to make the same APK work for both screen sizes, you can actually publish two APKs for the same application listing. Depending on each device's -screen configuration, Android Market will deliver it the APK that you've declared to support that +screen configuration, Google Play will deliver it the APK that you've declared to support that device's screen.</p> <p>Beware, however, that publishing multiple APKs for the same application is @@ -212,5 +212,5 @@ APK that can support a wide range of device configurations</strong>. Supporting sizes, especially, is within reason using a single APK, as long as you follow the guide to <a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a>.</p> -<p>If you need more information about how to publish multiple APKs on Android Market, read <a +<p>If you need more information about how to publish multiple APKs on Google Play, read <a href="{@docRoot}guide/market/publishing/multiple-apks.html">Multiple APK Support</a>.</p> diff --git a/docs/html/guide/practices/screens-support-1.5.jd b/docs/html/guide/practices/screens-support-1.5.jd index 9f033b4..4c6fb99 100644 --- a/docs/html/guide/practices/screens-support-1.5.jd +++ b/docs/html/guide/practices/screens-support-1.5.jd @@ -46,7 +46,7 @@ android:targetSdkVersion}</a> set to {@code "4"} or higher, then this document i default, an application written for Android 1.5 or below that does not set the <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code android:targetSdkVersion}</a> set to {@code "4"} or higher runs in <a -href="screen-compat-mode">screen compatibility mode</a> when on a device with a screen larger than +href="screen-compat-mode.html">screen compatibility mode</a> when on a device with a screen larger than the <em>normal</em> screen size (basically, the system displays the application in a small window that is roughly the size of the normal screen size).</p> diff --git a/docs/html/guide/practices/screens_support.jd b/docs/html/guide/practices/screens_support.jd index fb121bd..a870b22 100644 --- a/docs/html/guide/practices/screens_support.jd +++ b/docs/html/guide/practices/screens_support.jd @@ -882,8 +882,8 @@ application requires is the smallest possible on any device.</p> <p class="caution"><strong>Caution:</strong> The Android system does not pay attention to this attribute, so it does not affect how your application behaves at runtime. Instead, it is used -to enable filtering for your application on services such as Android Market. However, -<strong>Android Market currently does not support this attribute for filtering</strong> (on Android +to enable filtering for your application on services such as Google Play. However, +<strong>Google Play currently does not support this attribute for filtering</strong> (on Android 3.2), so you should continue using the other size attributes if your application does not support small screens.</p> </dd> @@ -1242,12 +1242,12 @@ have to buy various devices just to test your application's screen support.</p> <p>To set up an environment for testing your application's screen support, you should create a series of AVDs (Android Virtual Devices), using emulator skins and screen configurations that emulate the screen sizes and densities you want your application to support. To do so, you can use -the Android SDK and AVD Manager to create the AVDs and launch them with a graphical interface.</p> +the AVD Manager to create the AVDs and launch them with a graphical interface.</p> -<p>To launch the Android SDK and AVD Manager, execute the {@code +<p>To launch the Android SDK Manager, execute the {@code SDK Manager.exe} from your Android SDK directory (on Windows only) or execute {@code android} from -the {@code <sdk>/tools/} directory (on all platforms). Figure 6 shows the Android SDK and -AVD Manager with a selection of AVDs, for testing various screen configurations.</p> +the {@code <sdk>/tools/} directory (on all platforms). Figure 6 shows the AVD +Manager with a selection of AVDs, for testing various screen configurations.</p> <p>Table 3 shows the various emulator skins that are available in the Android SDK, which you can use to emulate some of the most common screen configurations.</p> @@ -1340,7 +1340,7 @@ dashboard.</p> <div class="figure" style="width:204px"> <img src="{@docRoot}images/screens_support/avd-start.png" alt="" /> <p class="img-caption"><strong>Figure 7.</strong> - Size and density options you can set, when starting an AVD from the Android SDK and AVD + Size and density options you can set, when starting an AVD from the AVD Manager.</p> </div> @@ -1349,12 +1349,12 @@ up to run at a physical size that closely matches an actual device. This makes it a lot easier to compare the results at various sizes and densities. To do so you need to know the approximate density, in dpi, of your computer monitor (for instance, a 30" Dell monitor has a density of about 96 dpi). When you launch an AVD -from the Android SDK and AVD Manager, you can specify the screen size for the emulator and your +from the AVD Manager, you can specify the screen size for the emulator and your monitor dpi in the Launch Options, as shown in figure 7.</p> <p>If you would like to test your application on a screen that uses a resolution or density not supported by the built-in skins, you can create an AVD that uses a custom resolution -or density. When creating the AVD from the Android SDK and AVD Manager, specify the Resolution, +or density. When creating the AVD from the AVD Manager, specify the Resolution, instead of selecting a Built-in Skin.</p> <p>If you are launching your AVD from the command line, you can specify the scale for diff --git a/docs/html/guide/practices/security.jd b/docs/html/guide/practices/security.jd index 476c301..eeaac44 100644 --- a/docs/html/guide/practices/security.jd +++ b/docs/html/guide/practices/security.jd @@ -126,8 +126,8 @@ applications.</p> <p>Use of <a href="{@docRoot}reference/android/content/Context.html#MODE_WORLD_WRITEABLE"> world writable</a> or <a -href="{@docRoot}reference/android/content/Context.html#MODE_WORLD_READABLE -">world readable</a> files for IPC is discouraged because it does not provide +href="{@docRoot}reference/android/content/Context.html#MODE_WORLD_READABLE">world +readable</a> files for IPC is discouraged because it does not provide the ability to limit data access to particular applications, nor does it provide any control on data format. As an alternative, you might consider using a ContentProvider which provides read and write permissions, and can make @@ -199,10 +199,10 @@ ContentProvider</a></code>.</p> <p>ContentProviders can also provide more granular access by declaring the <a href="{@docRoot}guide/topics/manifest/provider-element.html#gprmsn"> grantUriPermissions</a> element and using the <code><a -href="{@docRoot}reference/android/content/Intent.html#FLAG_GRANT_READ_URI_PERMIS -SION">FLAG_GRANT_READ_URI_PERMISSION</a></code> and <code><a -href="{@docRoot}reference/android/content/Intent.html#FLAG_GRANT_WRITE_URI_PERMI -SSION">FLAG_GRANT_WRITE_URI_PERMISSION</a></code> flags in the Intent object +href="{@docRoot}reference/android/content/Intent.html#FLAG_GRANT_READ_URI_PERMISSION">FLAG_GRANT_READ_URI_PERMISSION</a></code> +and <code><a +href="{@docRoot}reference/android/content/Intent.html#FLAG_GRANT_WRITE_URI_PERMISSION">FLAG_GRANT_WRITE_URI_PERMISSION</a></code> +flags in the Intent object that activates the component. The scope of these permissions can be further limited by the <code><a href="{@docRoot}guide/topics/manifest/grant-uri-permission-element.html"> @@ -211,14 +211,9 @@ grant-uri-permission element</a></code>.</p> <p>When accessing a <code> <a href="{@docRoot}reference/android/content/ContentProvider.html"> ContentProvider</a></code>, use parameterized query methods such as <code> -<a href="{@docRoot}reference/android/content/ContentProvider.html#query(android.net -.Uri,%20java.lang.String[],%20java.lang.String,%20java.lang.String[],%20java.lan -g.String)">query()</a></code>, <code><a -href="{@docRoot}reference/android/content/ContentProvider.html#update(android.ne -t.Uri,%20android.content.ContentValues,%20java.lang.String,%20java.lang.String[] -)">update()</a></code>, and <code><a -href="{@docRoot}reference/android/content/ContentProvider.html#delete(android.ne -t.Uri,%20java.lang.String,%20java.lang.String[])">delete()</a></code> to avoid +<a href="{@docRoot}reference/android/content/ContentProvider.html#query(android.net.Uri,%20java.lang.String[],%20java.lang.String,%20java.lang.String[],%20java.lang.String)">query()</a></code>, <code><a +href="{@docRoot}reference/android/content/ContentProvider.html#update(android.net.Uri,%20android.content.ContentValues,%20java.lang.String,%20java.lang.String[])">update()</a></code>, and <code><a +href="{@docRoot}reference/android/content/ContentProvider.html#delete(android.net.Uri,%20java.lang.String,%20java.lang.String[])">delete()</a></code> to avoid potential <a href="http://en.wikipedia.org/wiki/SQL_injection">SQL Injection</a> from untrusted data. Note that using parameterized methods is not sufficient if the <code>selection</code> is built by concatenating user data @@ -249,8 +244,9 @@ href="{@docRoot}reference/android/R.styleable.html#AndroidManifestActivity"> Activities</a>, and <a href="{@docRoot}reference/android/R.styleable.html#AndroidManifestService"> Services</a> are all declared in the application manifest. If your IPC mechanism is -not intended for use by other applications, set the android:exported property -to false. This is useful for applications that consist of multiple processes +not intended for use by other applications, set the <a +href="{@docRoot}guide/topics/manifest/service-element.html#exported">{@code android:exported}</a> +property to false. This is useful for applications that consist of multiple processes within the same UID, or if you decide late in development that you do not actually want to expose functionality as IPC but you don’t want to rewrite the code.</p> @@ -276,11 +272,10 @@ activity.</p> <p>Intents are the preferred mechanism for asynchronous IPC in Android. Depending on your application requirements, you might use <code><a -href="{@docRoot}reference/android/content/Context.html#sendBroadcast(android.con -tent.Intent)">sendBroadcast()</a></code>, <code><a -href="{@docRoot}reference/android/content/Context.html#sendOrderedBroadcast(andr -oid.content.Intent,%20java.lang.String)">sendOrderedBroadcast()</a></code>, or -direct an intent to a specific application component.</p> +href="{@docRoot}reference/android/content/Context.html#sendBroadcast(android.content.Intent)">sendBroadcast()</a></code>, +<code><a +href="{@docRoot}reference/android/content/Context.html#sendOrderedBroadcast(android.content.Intent,%20java.lang.String)">sendOrderedBroadcast()</a></code>, +or direct an intent to a specific application component.</p> <p>Note that ordered broadcasts can be “consumed” by a recipient, so they may not be delivered to all applications. If you are sending an Intent where @@ -311,14 +306,13 @@ and/or access controls on a specific binder interface, those controls must be explicitly added as code in the interface.</p> <p>If providing an interface that does require access controls, use <code><a -href="{@docRoot}reference/android/content/Context.html#checkCallingPermission(ja -va.lang.String)">checkCallingPermission()</a></code> to verify whether the +href="{@docRoot}reference/android/content/Context.html#checkCallingPermission(java.lang.String)">checkCallingPermission()</a></code> +to verify whether the caller of the Binder has a required permission. This is especially important before accessing a Service on behalf of the caller, as the identify of your application is passed to other interfaces. If invoking an interface provided by a Service, the <code><a -href="{@docRoot}reference/android/content/Context.html#bindService(android.conte -nt.Intent,%20android.content.ServiceConnection,%20int)">bindService()</a></code> +href="{@docRoot}reference/android/content/Context.html#bindService(android.content.Intent,%20android.content.ServiceConnection,%20int)">bindService()</a></code> invocation may fail if you do not have permission to access the given Service. If calling an interface provided locally by your own application, it may be useful to use the <code><a @@ -332,14 +326,14 @@ an intent.</p> <p>By default, receivers are exported and can be invoked by any other application. If your <code><a -href={@docRoot}reference/android/content/BroadcastReceiver.html"> +href="{@docRoot}reference/android/content/BroadcastReceiver.html"> BroadcastReceivers</a></code> is intended for use by other applications, you may want to apply security permissions to receivers using the <code><a -href="{@docRoot}reference/android/R.styleable.html#AndroidManifestReceiver"> +href="{@docRoot}guide/topics/manifest/receiver-element.html"> <receiver></a></code> element within the application manifest. This will prevent applications without appropriate permissions from sending an intent to the <code><a -href={@docRoot}reference/android/content/BroadcastReceiver.html"> +href="{@docRoot}reference/android/content/BroadcastReceiver.html"> BroadcastReceivers</a></code>.</p> <h3>Using Services</h3> @@ -349,19 +343,21 @@ use. Each service class must have a corresponding <service> declaration in its package's AndroidManifest.xml.</p> <p>By default, Services are exported and can be invoked by any other -application. Services can be protected using the android:permission attribute +application. Services can be protected using the <a +href="{@docRoot}guide/topics/manifest/service-element.html#prmsn">{@code android:permission}</a> +attribute within the manifest’s <code><a -href="{@docRoot}reference/android/R.styleable.html#AndroidManifestService"> +href="{@docRoot}guide/topics/manifest/service-element.html"> <service></a></code> tag. By doing so, other applications will need to declare a corresponding <code><a -href="{@docRoot}reference/android/R.styleable.html#AndroidManifestService_permis -sion"><uses-permission></a></code> element in their own manifest to be +href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><uses-permission></a> +</code> element in their own manifest to be able to start, stop, or bind to the service.</p> <p>A Service can protect individual IPC calls into it with permissions, by calling <code><a -href="{@docRoot}reference/android/content/Context.html#checkCallingPermission(ja -va.lang.String)">checkCallingPermission()</a></code>before executing +href="{@docRoot}reference/android/content/Context.html#checkCallingPermission(java.lang.String)">checkCallingPermission()</a></code> +before executing the implementation of that call. We generally recommend using the declarative permissions in the manifest, since those are less prone to oversight.</p> @@ -376,9 +372,9 @@ Service to handle IPC, since this modular approach reduces the risk of exposing functionality that is not intended for use by other applications.</p> <p>If you do expose an Activity for purposes of IPC, the <code><a -href="{@docRoot}reference/android/R.styleable.html#AndroidManifestActivity_permi -ssion">android:permission</a></code> attribute in the <code><a -href="{@docRoot}reference/android/R.styleable.html#AndroidManifestActivity"> +href="{@docRoot}guide/topics/manifest/activity-element.html#prmsn">android:permission</a></code> +attribute in the <code><a +href="{@docRoot}guide/topics/manifest/activity-element.html"> <activity></a></code> declaration in the application manifest can be used to restrict access to only those applications which have the stated permissions.</p> @@ -432,8 +428,8 @@ rkeley.edu/~afelt/felt_usenixsec2011.pdf</a></p> <p>Generally, you should strive to create as few permissions as possible while satisfying your security requirements. Creating a new permission is relatively uncommon for most applications, since <a -href="{@docRoot}reference/android/Manifest.permission.html"> -system-defined permissions</a> cover many situations. Where appropriate, +href="{@docRoot}reference/android/Manifest.permission.html">system-defined +permissions</a> cover many situations. Where appropriate, perform access checks using existing permissions.</p> <p>If you must create a new permission, consider whether you can accomplish @@ -560,17 +556,14 @@ href="{@docRoot}reference/android/webkit/WebView.html">WebView</a></code> does not execute JavaScript so cross-site-scripting is not possible.</p> <p>Use <code><a -href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(jav -a.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> with +href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> with particular care because it allows JavaScript to invoke operations that are normally reserved for Android applications. Only expose <code><a -href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(jav -a.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> to +href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> to sources from which all input is trustworthy. If untrusted input is allowed, untrusted JavaScript may be able to invoke Android methods. In general, we recommend only exposing <code><a -href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(jav -a.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> to +href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> to JavaScript that is contained within your application APK.</p> <p>Do not trust information downloaded over HTTP, use HTTPS instead. Even if @@ -578,13 +571,11 @@ you are connecting only to a single website that you trust or control, HTTP is subject to <a href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">MiTM</a> attacks and interception of data. Sensitive capabilities using <code><a -href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(jav -a.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> should +href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> should not ever be exposed to unverified script downloaded over HTTP. Note that even with the use of HTTPS, <code><a -href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(jav -a.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> +href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> increases the attack surface of your application to include the server infrastructure and all CAs trusted by the Android-powered device.</p> @@ -683,8 +674,7 @@ discussed in the Requesting Permissions section.</p> <p>If a GUID is required, create a large, unique number and store it. Do not use phone identifiers such as the phone number or IMEI which may be associated with personal information. This topic is discussed in more detail in the <a -href="http://android-developers.blogspot.com/2011/03/identifying-app-installatio -ns.html">Android Developer Blog</a>.</p> +href="http://android-developers.blogspot.com/2011/03/identifying-app-installations.html">Android Developer Blog</a>.</p> <p>Application developers should be careful writing to on-device logs. In Android, logs are a shared resource, and are available @@ -724,9 +714,8 @@ credentials to the wrong application.</p> <p>If credentials are to be used only by applications that you create, then you can verify the application which accesses the <code><a href="{@docRoot}reference/android/accounts/AccountManager.html"> -AccountManager</a></code> using <code><a href="<code><a -href="{@docRoot}h/reference/android/content/pm/PackageManager.html#checkSignatur -es(java.lang.String,%20java.lang.String)">checkSignature()</a></code>. +AccountManager</a></code> using <code><a +href="{@docRoot}reference/android/content/pm/PackageManager.html#checkSignatures(java.lang.String,%20java.lang.String)">checkSignature()</a></code>. Alternatively, if only one application will use the credential, you might use a <code><a href={@docRoot}reference/java/security/KeyStore.html">KeyStore</a></code> for @@ -756,15 +745,15 @@ RSA provided in the <code><a href="{@docRoot}reference/javax/crypto/Cipher.html">Cipher</a></code> class.</p> <p>Use a secure random number generator ( -<a href="http://developer.android.com/reference/java/security/SecureRandom.html"> +<a href="{@docRoot}reference/java/security/SecureRandom.html"> <code>SecureRandom</code></a>) to initialize any cryptographic keys (<a -href="http://developer.android.com/reference/javax/crypto/KeyGenerator.html"> +href="{@docRoot}reference/javax/crypto/KeyGenerator.html"> <code>KeyGenerator</code></a>). Use of a key that is not generated with a secure random number generator significantly weakens the strength of the algorithm, and may allow offline attacks.</p> <p>If you need to store a key for repeated use, use a mechanism like <code><a -href={@docRoot}reference/java/security/KeyStore.html">KeyStore</a></code> that +href="{@docRoot}reference/java/security/KeyStore.html">KeyStore</a></code> that provides a mechanism for long term storage and retrieval of cryptographic keys.</p> diff --git a/docs/html/guide/practices/tablets-and-handsets.jd b/docs/html/guide/practices/tablets-and-handsets.jd index dc35801..8e07a08 100644 --- a/docs/html/guide/practices/tablets-and-handsets.jd +++ b/docs/html/guide/practices/tablets-and-handsets.jd @@ -99,7 +99,8 @@ side.</p> <p>You can enable items from the options menu to appear directly in the action bar as "action items". You can also add navigation features to the action bar, such as tabs or a drop-down list, -and use the application icon to supplement the system's BACK behavior with the option to navigate to +and use the application icon to supplement the system's <em>Back</em> button behavior with the option to +navigate to your application's "home" activity or "up" the application's structural hierarchy.</p> <p>This guide provides some tips for using the action bar in ways that support both tablets and @@ -458,7 +459,8 @@ attribute.</p> developer guide, you can use the application icon in the action bar to facilitate user navigation when appropriate—either as a method to get back to the "home" activity (similar to clicking the logo on a web site) or as a way to navigate up the application's structural hierarchy. Although -it might seem similar to the standard BACK navigation in some cases, the up navigation option +it might seem similar to the standard <em>Back</em> navigation in some cases, the up navigation +option provides a more predictable navigation method for situations in which the user may have entered from an external location, such as a notification, app widget, or a different application.</p> @@ -481,7 +483,7 @@ href="{@docRoot}guide/topics/ui/actionbar.html#Home">Action Bar</a> developer gu information in each list item based on the available space. That is, you can create alternative layouts to be used by the items in your list adapter such that a large screen might display more detail for each item.</li> - <li>Create <a href="{@docRoot}guide/topics/resources/more-resources.html ">alternative resource + <li>Create <a href="{@docRoot}guide/topics/resources/more-resources.html">alternative resource files</a> for values such as integers, dimensions, and even booleans. Using size qualifiers for these resources, you can easily apply different layout sizes, font sizes, or enable/disable features based on the current screen size.</li> diff --git a/docs/html/guide/practices/ui_guidelines/activity_task_design.jd b/docs/html/guide/practices/ui_guidelines/activity_task_design.jd index 31ad466..8e4528e 100644 --- a/docs/html/guide/practices/ui_guidelines/activity_task_design.jd +++ b/docs/html/guide/practices/ui_guidelines/activity_task_design.jd @@ -3,6 +3,43 @@ parent.title=UI Guidelines parent.link=index.html @jd:body + + + +<div id="deprecatedSticker"> + <a href="#" + onclick="$('#naMessage').show();$('#deprecatedSticker').hide();return false"> + <strong>This doc is deprecated</strong></a> +</div> + + +<div id="naMessage" style="display:block"> +<div><p><strong>This document has been deprecated.</strong></p> + <p>For information about designing an activity structure and navigation, read the design guidelines +for <a href="{@docRoot}design/patterns/app-structure.html">App Structure</a> and +<a href="{@docRoot}design/patterns/navigation.html">Navigation</a>, or the developer guide +about <a +href="{@docRoot}guide/topics/fundamentals/tasks-and-back-stack.html">Tasks and Back Stack</a>.</p> + + <input style="margin-top:1em;padding:5px" type="button" + value="That's nice, but I still want to read this document" +onclick="$('#naMessage').hide();$('#deprecatedSticker').show()" /> +</div> +</div> + + + + + + + + + + + + + + <div id="qv-wrapper"> <div id="qv"> @@ -40,9 +77,10 @@ parent.link=index.html <li><a href=#reusing_tip>Handle case where no activity matches</a></li> <li><a href=#activity_launching_tip>Consider how to launch your activities</a></li> <li><a href=#activities_added_to_task_tip>Allow activities to add to current task</a></li> - <li><a href=#notifications_get_back_tip>Notifications should let user easily get back</li> + <li><a href=#notifications_get_back_tip>Notifications and App Widgets should provide consistent back behavior</li> <li><a href=#use_notification_tip>Use the notification system</a></li> - <li><a href=#taking_over_back_key>Don't take over BACK key unless you absolutely need to</a></li> + <li><a href=#taking_over_back_key>Don't take over <em>Back</em> button unless you absolutely +need to</a></li> </ol> </li> </ol> @@ -241,8 +279,8 @@ independent of the other Android system keeps a linear navigation history of activities the user has visited. This is the <em>activity stack</em>, also known as the back stack. In general, when a user starts a new activity, it is added - to the activity stack, so that pressing BACK displays the previous - activity on the stack. However, the user cannot use the BACK key to go + to the activity stack, so that pressing <em>Back</em> displays the previous + activity on the stack. However, the user cannot use the <em>Back</em> button to go back further than the last visit to Home. The adding of an activity to the current stack happens whether or not that activity begins a new <a href=#tasks title=task>task</a> (as long as that task was started @@ -256,10 +294,11 @@ independent of the other Activities are the only things that can be added to the activity stack — views, windows, menus, and dialogs cannot. That is, when designing the navigation, if you have screen A and you want the user - to be able go to a subsequent screen B and then use the BACK key to go + to be able go to a subsequent screen B and then use the <em>Back</em> button to go back to screen A, then the screen A needs to be implemented as an activity. The one exception to this rule is if your application - <a href="#taking_over_back_key">takes control of the BACK key</a> and manages the navigation + <a href="#taking_over_back_key">takes control of the <em>Back</em> button</a> and manages the +navigation itself. </p> @@ -287,7 +326,7 @@ itself. launcher, Home screen shortcut or "Recent tasks" switcher (a long press on Home on some devices). The user can return to a task by choosing the icon for its root activity the same way they started the - task. Once inside a task, the BACK key goes to previous activities in + task. Once inside a task, the <em>Back</em> button goes to previous activities in that task. The activity stack is made up of one or more tasks. </p> @@ -331,7 +370,7 @@ itself. Browser are two applications that do this. For example, choosing an address in an email starts the Maps activity as a new task, and choosing a link in an email starts the Browser activity as a new - task. In these cases, the BACK key will return to the previous + task. In these cases, the <em>Back</em> button will return to the previous activity in a different task (Email), because it was not started from Home. </p> @@ -341,7 +380,7 @@ itself. <p> The following examples illustrate basic principles for applications, - activities, the activity stack, the BACK key, tasks and intents. It + activities, the activity stack, the <em>Back</em> button, tasks and intents. It shows how the system responds to user actions such as starting activities and switching between tasks. With most of these examples you can follow along, launching activities on your device as @@ -367,19 +406,20 @@ itself. <img src={@docRoot}images/activity_task_design/HomeTaskBasics1a.png> </p> -<h3 id=navigating_away_from_an_activity>Navigating Away from an Activity with BACK and HOME keys</h3> +<h3 id=navigating_away_from_an_activity>Navigating Away from an Activity with <em>Back</em> and +<em>Home</em> buttons</h3> <p> An activity can keep or lose its state depending on how the user - leaves the activity — by the HOME or BACK key. + leaves the activity — by the <em>Home</em> or <em>Back</em> button. </p> <p> - By default, pressing the BACK key finishes (destroys) the current + By default, pressing the <em>Back</em> button finishes (destroys) the current activity and displays the previous activity to the user. In the following figure, the user starts email by touching the Email icon in the Home screen, which displays a list of email messages. The user - scrolls down the list (changing its initial state). Pressing BACK + scrolls down the list (changing its initial state). Pressing <em>Back</em> destroys the List Messages activity and returns to the previous activity, which is Home. If the user re-launches Email, it would re-load the messages and display its initial, non-scrolled state. @@ -390,15 +430,15 @@ itself. </p> <p> - In the above example, pressing BACK goes to Home because it was the + In the above example, pressing <em>Back</em> goes to Home because it was the last activity the user was viewing. But if the user had gotten to List - Message from some other activity, then pressing BACK would have + Message from some other activity, then pressing <em>Back</em> would have returned there. </p> <p> By contrast, the next figure shows the user leaving List Messages by - pressing HOME instead of BACK — the List Messages activity is + pressing <em>Home</em> instead of <em>Back</em> — the List Messages activity is stopped and moved to the background rather than being destroyed. Starting Email again from its icon would simply bring the List Messages activity to the foreground (changing it from stopped to @@ -423,8 +463,8 @@ itself. <p> In addition, not all activities have the behavior that they are - destroyed when BACK is pressed. When the user starts playing music in - the Music application and then presses BACK, the application overrides + destroyed when <em>Back</em> is pressed. When the user starts playing music in + the Music application and then presses <em>Back</em>, the application overrides the normal back behavior, preventing the player activity from being destroyed, and continues playing music, even though its activity is no longer visible — as a visual substitute, the Music application @@ -451,7 +491,7 @@ itself. activity to get a picture. This is a good example of re-use of the Gallery activity. The following figure illustrates the sequence of activities to do this (up to crop). This is how it's done: The user - chooses Contacts, selects the contact for viewing, chooses MENU > + chooses Contacts, selects the contact for viewing, chooses <em>Menu</em> > Edit contact and touches the picture field, which launches the Gallery activity. The user then chooses the picture they want, crops and saves it. Saving it causes the picture to be inserted into the picture field @@ -484,12 +524,12 @@ itself. <b>Gallery Re-Uses Messaging for Sharing a Picture</b> - Sharing is another good example of one application re-using an activity from a different application. As shown in the following figure, the user - starts Gallery, picks a picture to view, chooses MENU > Share, and + starts Gallery, picks a picture to view, chooses <em>Menu</em> > Share, and picks "Messaging". This starts the Messaging activity, creates a new message and attaches the original picture to it. The user then fills in the "To" field, writes a short message and sends it. User focus remains in the Messaging program. If the user wants to go back to the - Gallery, they must press the BACK key. (The user can back up through + Gallery, they must press the <em>Back</em> button. (The user can back up through each activity all the way to Home.) </p> @@ -552,7 +592,7 @@ itself. <ul> <li> State 2 - The user wants to do something else while they're - waiting, so they press HOME, which does not interrupt the map's + waiting, so they press <em>Home</em>, which does not interrupt the map's network connection and allows the map to continue loading in the background. @@ -729,7 +769,7 @@ href="{@docRoot}guide/topics/intents/intents-filters.html">Intents and Intent Fi <b>Start first task.</b> You want to send a text message and attach a photo. You would choose: <p> - Home > Messaging > New message > MENU > Attach + Home > Messaging > New message > <em>Menu</em> > Attach > Pictures. This last step launches the picture gallery for picking a photo. Notice that picture gallery is an activity in a separate application. @@ -883,7 +923,7 @@ href="{@docRoot}guide/topics/intents/intents-filters.html">Intents and Intent Fi You can perform this test when initializing the user interface. For instance, you could disable the user control that initiates the Intent object, or display a message to the user that lets them go - to a location, such as the Market, to download its application. + to a location, such as Google Play, to download its application. In this way, your code can start the activity (using either startActivity() or startActivityForResult()) only if the intent has tested to resolve to an activity that is actually present. @@ -961,7 +1001,7 @@ MAIN and address in an email message (or web page), where the Maps activity is started to map the location. No result from maps is expected to be returned to the email message; the user - can return by pressing the BACK key. (Such an activity is + can return by pressing the <em>Back</em> button. (Such an activity is started with {@link android.content.Context#startActivity(android.content.Intent) startActivity()}.) @@ -1063,110 +1103,23 @@ MAIN and </p> -<h3 id="notifications_get_back_tip">Notifications should let the user easily get back to the previous activity</h3> +<h3 id="notifications_get_back_tip">Notifications and App Widgets should provide consistent back behavior</h3> <p> - Applications that are in the background or not running can have - services that send out notifications to the user letting them know about - events of interest. Two examples are Calendar, which can send out notifications of - upcoming events, and Email, which can send out notifications when new - messages arrive. One of the user interface guidelines is that when the - user is in activity A, gets a notification for activity B and - picks that notification, when they press the BACK key, they should - go back to activity A. + Notifications and app widgets are two common ways that a user can launch + your app through something besides its main icon in Launcher. You must + take care when implementing these so that the user has a consistent experience + with the back button, not causing surprises in where they return to or the + state the application ends up in. </p> <p> - The following scenario shows how the activity stack should work - when the user responds to a notification. -</p> - -<ol> - <li> - User is creating a new event in Calendar. They realize they - need to copy part of an email message into this event - </li> - <li> - The user chooses Home > Gmail - </li> - <li> - While in Gmail, they receive a notification from Calendar for an upcoming meeting - </li> - <li> - So they choose that notification, which takes them to a - dedicated Calendar activity that displays brief details of the - upcoming meeting - </li> - <li> - The user chooses this short notice to view further details - </li> - <li> - When done viewing the event, the user presses the BACK - key. They should be taken to Gmail, which is where they were - when they took the notification - </li> -</ol> - -<p> -This behavior doesn't necessarily happen by default. -</p> - -<p> -Notifications generally happen primarily in one of two ways: -</p> - - <ul> - <li> - <b>The chosen activity is dedicated for notification only</b> - - For example, when the user receives a - Calendar notification, choosing that - notification starts a special activity that displays a list - of upcoming calendar events — this view is available only - from the notification, not through the Calendar's own user - interface. After viewing this upcoming event, to ensure that - the user pressing the BACK key will return to the activity - the user was in when they picked the notification, you would - make sure this dedicated activity does not have the same - task affinity as the Calendar or any other activity. (You do - this by setting task affinity to the empty string, which - means it has no affinity to anything.) The explanation for - this follows. - - <p> - Because of the way tasks work, if the taskAffinity of the - dedicated activity is kept as its default, then pressing the - BACK key (in step 6, above) would go to Calendar, rather - than Gmail. The reason is that, by default, all activities - in a given application have the same task - affinity. Therefore, the task affinity of the dedicated - activity matches the Calendar task, which is already running - in step 1. This means in step 4, choosing the notification - brings the existing Calendar event (in step 1) forward and - starts the dedicated activity on top of it. This is not - what you want to have happen. Setting the dedicated - activity's taskAffinity to empty string fixes this. - </p> - </li> - - <li> - <b>The chosen activity is not dedicated, but always comes to - the foreground in its initial state</b> - For example, in - response to a notification, when the Gmail application comes - to the foreground, it always presents the list of conversations. - You can ensure this happens by setting a "clear top" flag in the - intent that the notification triggers. This ensures that when the - activity is launched, it displays its initial activity, preventing - Gmail from coming to the foreground in whatever state the user last - happened to be viewing it. (To do this, you put {@link - android.content.Intent#FLAG_ACTIVITY_CLEAR_TOP - FLAG_ACTIVITY_CLEAR_TOP} in the intent you pass to startActivity()). - </li> - </ul> - -<p> - There are other ways to handle notifications, such as bringing the - activity to the foreground, set to display specific data, such as - displaying the text message thread for the person who just sent a - new text message. + The + <a href="{@docRoot}guide/topics/ui/notifiers/notifications.html#HandlingNotifications">Handling + Notifications</a> section of the developer guide's + <a href="{@docRoot}guide/topics/ui/notifiers/notifications.html">Status Bar Notifications</a> + documentation provides an overview of how to write code to correctly handle + notification. This dicussion applies equally to handling interactions with + app widgets. </p> <p> @@ -1189,20 +1142,21 @@ Notifications generally happen primarily in one of two ways: convenience to respond to your message. </p> -<h3 id=taking_over_back_key>Don't take over the BACK key unless you absolutely need to</h3> +<h3 id=taking_over_back_key>Don't take over the <em>Back</em> button unless you absolutely need +to</h3> <p> As a user navigates from one activity to the next, the system adds them to the activity stack. This forms a navigation history that is - accessible with the BACK key. Most activities are relatively limited + accessible with the <em>Back</em> button. Most activities are relatively limited in scope, with just one set of data, such as viewing a list of contacts, composing an email, or taking a photo. But what if your application is one big activity with several pages of content and - needs finer-grained control of the BACK key? Examples of such Google + needs finer-grained control of the <em>Back</em> button? Examples of such Google applications are the Browser, which can have several web pages open at once, and Maps, which can have several layers of geographic data to switch between. Both of these applications take control of the - BACK key and maintain their own internal back stacks that operate + <em>Back</em> button and maintain their own internal back stacks that operate only when these applications have focus. </p> @@ -1211,7 +1165,7 @@ Notifications generally happen primarily in one of two ways: information on a map to the user: displaying the location of a search result, displaying locations of friends, and displaying a line for a street path providing direction between points. Maps - stores these layers in its own history so the BACK key can return to + stores these layers in its own history so the <em>Back</em> button can return to a previous layer. </p> @@ -1222,8 +1176,8 @@ Notifications generally happen primarily in one of two ways: as Windows, Macintosh or Linux). For example, if you did a Google web search in one window of the Android Browser, clicking on a link in the search results displays a web page in that same window, and - then pressing BACK would to the search results page. Pressing - BACK goes to a previous window only if the current window was + then pressing <em>Back</em> would to the search results page. Pressing + <em>Back</em> goes to a previous window only if the current window was launched from that previous window. If the user keeps pressing back, they will eventually leave the browser activity and return Home. diff --git a/docs/html/guide/practices/ui_guidelines/icon_design.jd b/docs/html/guide/practices/ui_guidelines/icon_design.jd index 07b73bb..1c66185 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design.jd @@ -42,8 +42,6 @@ Templates Pack, v4.0 »</a></li> Templates Pack, v2.3 »</a></li> <li><a href="{@docRoot}shareables/icon_templates-v2.0.zip">Android Icon Templates Pack, v2.0 »</a></li> -<li><a href="{@docRoot}shareables/icon_templates-v1.0.zip">Android Icon -Templates Pack, v1.0 »</a></li> </ol> <h2>See also</h2> @@ -57,6 +55,16 @@ Screens</a></li> </div> </div> + +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> + + + <p>Creating a unified look and feel throughout a user interface adds value to your product. Streamlining the graphic style will also make the UI seem more professional to users.</p> diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_action_bar.jd b/docs/html/guide/practices/ui_guidelines/icon_design_action_bar.jd index 449c27f..2476255 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_action_bar.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_action_bar.jd @@ -29,6 +29,12 @@ Screens</a></li> </div> </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> <p>Action Bar icons are graphical elements placed in the <a diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_dialog.jd b/docs/html/guide/practices/ui_guidelines/icon_design_dialog.jd index f78bd86..9b8cce7 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_dialog.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_dialog.jd @@ -27,6 +27,12 @@ Screens</a></li> </div> </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> <p>Dialog icons are shown in pop-up dialog boxes that prompt the user for diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd b/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd index 3f6061c..4b6768f 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd @@ -26,6 +26,15 @@ Screens</a></li> </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> + + + <p>A launcher icon is a graphic that represents your application. Launcher icons are used by Launcher applications and appear on the user’s Home screen. Launcher icons can also be used to represent shortcuts into your application (for example, a contact shortcut icon that opens detail @@ -40,9 +49,9 @@ across the range of devices on which your application can be installed. See <a href="{@docRoot}guide/practices/ui_guidelines/icon_design.html#design-tips">Tips for Designers</a> for suggestions on how to work with multiple sets of icons.</p> -<p>A high-resolution version of your application launcher icon is also required by Android Market +<p>A high-resolution version of your application launcher icon is also required by Google Play for use in application listings. For more details on this, see <a -href="#icons_in_market">Application Icons in Android Market</a> below.</p> +href="#icons_in_market">Application Icons on Google Play</a> below.</p> <p class="note"><strong>Note:</strong> @@ -72,7 +81,7 @@ need to review the old guidelines, see the <ol> <li>Promote the brand and tell the story of the app.</li> - <li>Help users discover the app in Android Market.</li> + <li>Help users discover the app on Google Play.</li> <li>Function well in the Launcher.</li> </ol> @@ -91,19 +100,19 @@ app is about. Thus, you should:</p> </ul> -<h3 id="help_users_discover">Help users discover the app in Android Market</h3> +<h3 id="help_users_discover">Help users discover the app on Google Play</h3> -<p>App launcher icons are the first look that prospective users will get of your app in Android -Market. A high quality app icon can influence users to find out more as they scroll through lists of +<p>App launcher icons are the first look that prospective users will get of your app on Google Play. +A high quality app icon can influence users to find out more as they scroll through lists of applications.</p> <p>Quality matters here. A well-designed icon can be a strong signal that your app is of similarly high quality. Consider working with an icon designer to develop the app’s launcher icon.</p> -<p class="note"><strong>Note:</strong> Android Market requires a high-resolution version of your -icon; for more details on this, see <a href="#icons_in_market">Application Icons in Android -Market</a> below.</p> +<p class="note"><strong>Note:</strong> Google Play requires a high-resolution version of your +icon; for more details on this, see <a href="#icons_in_market">Application Icons in Google +Play</a> below.</p> <h3 id="function_well_in_launcher">Function well in the Launcher</h3> @@ -230,21 +239,21 @@ This padding can also be used to make room for a subtle drop shadow, which can h that launcher icons are legible across on any background color.</p> -<h3 id="icons_in_market">Application Icons in Android Market</h3> +<h3 id="icons_in_market">Application Icons on Google Play</h3> <p>If you are <a href="{@docRoot}guide/publishing/publishing.html">publishing your application on -Android Market</a>, you will also need to provide a 512 x 512 pixel, high-resolution application icon -in the <a href="http://market.android.com/publish">developer console</a> at upload time. This icon -will be used in various locations in Android Market and does not replace your launcher icon.</p> +Google Play</a>, you will also need to provide a 512 x 512 pixel, high-resolution application icon +in the <a href="http://play.google.com/apps/publish">developer console</a> at upload time. This icon +will be used in various locations on Google Play and does not replace your launcher icon.</p> <p>For tips and recommendations on creating high-resolution launcher icons that can easily be scaled up to 512x512, see <a href="{@docRoot}guide/practices/ui_guidelines/icon_design.html#design-tips"> Tips for Designers</a>.</p> -<p>For information and specifications about high-resolution application icons in Android Market, see +<p>For information and specifications about high-resolution application icons on Google Play, see the following article:</p> <p style="margin-left:2em"><a href="http://market.android.com/support/bin/answer.py?answer=1078870"> -Graphic Assets for your Application (Android Market Help) »</a> +Graphic Assets for your Application (Google Play Help) »</a> <br><br> diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_launcher_archive.jd b/docs/html/guide/practices/ui_guidelines/icon_design_launcher_archive.jd index ea036cd..85a3cc8 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_launcher_archive.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_launcher_archive.jd @@ -56,13 +56,13 @@ suggestions on how to work with multiple sets of icons.</p> -<h2 id="market">Application Icons in Android Market</h2> +<h2 id="market">Application Icons on Google Play</h2> <p>If you are <a href="{@docRoot}guide/publishing/publishing.html">publishing -your application on Android Market</a>, you will also need to provide a 512x512 +your application on Google Play</a>, you will also need to provide a 512x512 pixel, high-resolution application icon in the <a -href="http://market.android.com/publish">developer console</a> at upload-time. -This icon will be used in various locations in Android Market and does +href="http://play.google.com/apps/publish">developer console</a> at upload-time. +This icon will be used in various locations on Google Play and does not replace your launcher icon.</p> <p>For tips and recommendations on creating high-resolution launcher icons that @@ -71,11 +71,11 @@ can easily be scaled up to 512x512, see Tips for Designers</a>.</p> <p>For information and specifications about high-resolution application -icons in Android Market, see the following article:</p> +icons on Google Play, see the following article:</p> <p style="margin-left:2em"><a href="http://market.android.com/support/bin/answer.py?answer=1078870"> - Graphic Assets for your Application (Android Market Help) »</a> + Graphic Assets for your Application (Google Play Help) »</a> diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_list.jd b/docs/html/guide/practices/ui_guidelines/icon_design_list.jd index 7bf34cc..fd4dc6b 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_list.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_list.jd @@ -28,6 +28,13 @@ Screens</a></li> </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> + <p>List view icons look a lot like dialog icons, but they use an inner shadow effect where the light source is above the object. They are also designed to be diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_menu.jd b/docs/html/guide/practices/ui_guidelines/icon_design_menu.jd index 974e48f..e267013 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_menu.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_menu.jd @@ -32,6 +32,13 @@ Screens</a></li> </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> + <p>Menu icons are graphical elements placed in the options menu shown to users when they press the Menu button. They are drawn in a flat-front perspective and diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_status_bar.jd b/docs/html/guide/practices/ui_guidelines/icon_design_status_bar.jd index b8e07b5..a20c1ee 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_status_bar.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_status_bar.jd @@ -40,6 +40,13 @@ Screens</a></li> </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> + <p>Status bar icons are used to represent notifications from your application in the status bar.</p> diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_tab.jd b/docs/html/guide/practices/ui_guidelines/icon_design_tab.jd index 271bd85..f85398d 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_tab.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_tab.jd @@ -32,6 +32,13 @@ Screens</a></li> </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> + <p>Tab icons are graphical elements used to represent individual tabs in a multi-tab interface. Each tab icon has two states: unselected and selected.</p> diff --git a/docs/html/guide/practices/ui_guidelines/index.jd b/docs/html/guide/practices/ui_guidelines/index.jd index 0e42788..24fb855 100644 --- a/docs/html/guide/practices/ui_guidelines/index.jd +++ b/docs/html/guide/practices/ui_guidelines/index.jd @@ -2,18 +2,28 @@ page.title=User Interface Guidelines @jd:body -<img src="{@docRoot}assets/images/uiguidelines1.png" alt="" align="right"> + +<div class="design-announce" style="background:none;overflow:auto;padding:10px 5px"> + <a href="{@docRoot}design/index.html"><img src="{@docRoot}images/home/android-design.png" alt="" +style="float:left;margin:0 1em 0 0;"/></a> +<p><strong>New Guides for App Designers!</strong></p> +<p>The Android UX team has put together a set of guidelines for the interaction and +visual design of Android applications. The new collection provides an overview of +Android styles, design patterns, building blocks for exceptional Android designs, and more.</p> +<p><strong><a href="{@docRoot}design/index.html">Android Design</a></strong></p> + +<p>Over time, the documents below will be deprecated as more design information is published at +the new location.</p> +</div> + -<p>The Android UI team has begun developing guidelines for the interaction and -visual design of Android applications. Look here for articles that describe -these guidelines as we release them.</p> <dl> <dt><a href="{@docRoot}guide/practices/ui_guidelines/icon_design.html">Icon Design Guidelines</a> and <a href="{@docRoot}shareables/icon_templates-v4.0.zip">Android Icon Templates Pack -» </a> <span class="new">updated</span></dt> +» </a></dt> <dd>Your applications need a wide variety of icons, from a launcher icon to icons in menus, dialogs, tabs, the status bar, and lists. The Icon Guidelines describe each kind of icon in detail, with specifications for the size, color, @@ -22,32 +32,13 @@ The Icon Templates Pack is an archive of Photoshop and Illustrator templates and filters that make it much simpler to create conforming icons.</dd> </dl> <dl> - <dt><a href="{@docRoot}guide/practices/ui_guidelines/widget_design.html">Widget Design Guidelines</a> <span class="new">updated</span></dt> + <dt><a href="{@docRoot}guide/practices/ui_guidelines/widget_design.html">Widget Design +Guidelines</a> </dt> <dd>A widget displays an application's most important or timely information at a glance, on a user's Home screen. These design guidelines describe how to design widgets that fit with others on the Home screen. They include links to graphics files and templates that will make your designer's life easier.</dd> </dl> - <dl> - <dt><a href="{@docRoot}guide/practices/ui_guidelines/activity_task_design.html">Activity and Task Design Guidelines</a> </dt> - <dd>Activities are the basic, independent building blocks of applications. - As you design your application's UI and feature set, you are free to - re-use activities from other applications as if they were yours, - to enrich and extend your application. These guidelines - describe how activities work, illustrates them with examples, and - describes important underlying principles and mechanisms, such as - multitasking, activity reuse, intents, the activity stack, and - tasks. It covers this all from a high-level design perspective. -</dd> - <dt><a href="{@docRoot}guide/practices/ui_guidelines/menu_design.html">Menu Design Guidelines</a> </dt> - <dd>Android applications make use of Option menus and Context menus - that enable users to perform operations and navigate to other parts - of your application or to other applications. These guidelines describe - the difference between Options and Context menus, how to arrange - menu items, when to put commands on-screen, and other details about - menu design. -</dd> -</dl> diff --git a/docs/html/guide/practices/ui_guidelines/menu_design.jd b/docs/html/guide/practices/ui_guidelines/menu_design.jd index 3edf33f..b4e2ea7 100644 --- a/docs/html/guide/practices/ui_guidelines/menu_design.jd +++ b/docs/html/guide/practices/ui_guidelines/menu_design.jd @@ -2,7 +2,38 @@ page.title=Menu Design Guidelines parent.title=UI Guidelines parent.link=index.html @jd:body + + + + +<div id="deprecatedSticker"> + <a href="#" + onclick="$('#naMessage').show();$('#deprecatedSticker').hide();return false"> + <strong>This doc is deprecated</strong></a> +</div> + + +<div id="naMessage" style="display:block"> +<div><p><strong>This document has been deprecated.</strong></p> + <p>For design guidelines about adding user actions and other options, read the design guidelines +for <a href="{@docRoot}design/patterns/actionbar.html">Action Bar</a> or the developer guide about +<a href="{@docRoot}guide/topics/ui/menus.html">Menus</a>.</p> + + <input style="margin-top:1em;padding:5px" type="button" + value="That's nice, but I still want to read this document" +onclick="$('#naMessage').hide();$('#deprecatedSticker').show()" /> +</div> +</div> + + + + + + + + + <div id="qv-wrapper"> <div id="qv"> @@ -71,7 +102,7 @@ parent.link=index.html <ul> <li>The <em>Options menu</em> contains primary functionality that applies globally to the current activity or starts a related activity. - It is typically invoked by a user pressing a hard button, often labeled MENU.</li> + It is typically invoked by a user pressing a hard button, often labeled <em>Menu</em>.</li> <li>The <em>Context menu</em> contains secondary functionality for the currently selected item. It is typically invoked by a user's touch & hold on an item. Like on the Options menu, the operation can run either @@ -109,10 +140,10 @@ or device to another. </p> <p> - On most devices, a user presses the MENU button to access the Options menu, + On most devices, a user presses the <em>Menu</em> button to access the Options menu, as shown in the screenshot below. To close the menu, the user presses - MENU again, or presses the BACK button. - In fact, to cancel out of any menu, press the BACK button. (Pressing the MENU + <em>Menu</em> again, or presses the <em>Back</em> button. + In fact, to cancel out of any menu, press the <em>Back</em> button. (Pressing the <em>Menu</em> button or touching outside the menu also works.) Note that how to invoke this menu may be different on different devices. </p> @@ -140,7 +171,7 @@ or device to another. <ul> <li> - <b>Options icon menu</b> - The first press of the MENU button displays a + <b>Options icon menu</b> - The first press of the <em>Menu</em> button displays a non-scrollable grid of icons at the bottom of the screen. (On the G1 phone, up to 6 buttons typically appear.) </li> @@ -156,7 +187,7 @@ or device to another. <p> On some versions of Android, the user can display keyboard shortcuts in the - icon menu by long pressing the MENU button — the text in the icon menu + icon menu by long pressing the <em>Menu</em> button — the text in the icon menu alternates between the command names and their keyboard shortcuts (if any). </p> @@ -299,7 +330,7 @@ or device to another. <a href="#location">location</a>) on the screen, put the command in the Context menu for that content. If the command acts on no specific content or location, put it in the Options menu. This separation of commands - is enforced by the system in the following way. When you press the MENU + is enforced by the system in the following way. When you press the <em>Menu</em> button to display the Options menu, the selected content becomes unselected, and so cannot be operated on. For an explanation of why the content becomes unselected, see the article on @@ -340,7 +371,7 @@ or device to another. <p> Before opening a Context menu, it has no visual representation that identifies - its presence (whereas the Options menu has the MENU button), and so is not + its presence (whereas the Options menu has the <em>Menu</em> button), and so is not particularly discoverable. Therefore, in general, a Context menu should <em>duplicate</em> commands found in the corresponding activity screen. For example, while it's useful to @@ -459,7 +490,8 @@ or device to another. <h3 id="a_dialog_should_not_have_an_options_menu">A dialog should not have an Options menu</h3> <p> - When a dialog is displayed, pressing the MENU button should do nothing. This also holds true + When a dialog is displayed, pressing the <em>Menu</em> button should do nothing. This also holds +true for activities that look like dialogs. A dialog box is recognizable by being smaller than full-screen, having zero to three buttons, is non-scrollable, and possibly a list of selectable items that can include checkboxes or radio buttons. @@ -475,7 +507,7 @@ or device to another. <h3 id="do_not_substitute_message">If an activity has no Options menu, do not display a message</h3> <p> - When the user presses the MENU button, if there is no Options menu, the system + When the user presses the <em>Menu</em> button, if there is no Options menu, the system currently does nothing. We recommend you do not perform any action (such as displaying a message). It's a better user experience for this behavior to be consistent across applications. diff --git a/docs/html/guide/practices/ui_guidelines/widget_design.jd b/docs/html/guide/practices/ui_guidelines/widget_design.jd index f63f3c4..d789407 100644 --- a/docs/html/guide/practices/ui_guidelines/widget_design.jd +++ b/docs/html/guide/practices/ui_guidelines/widget_design.jd @@ -44,6 +44,13 @@ parent.link=index.html </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>.</p> +</div> + + <p>App widgets (sometimes just "widgets") are a feature introduced in Android 1.5 and vastly improved in Android 3.0 and 3.1. A widget can display an application's most timely or otherwise relevant information at a glance, on a user's Home screen. The standard Android system image |