diff options
Diffstat (limited to 'docs/html/guide/practices')
11 files changed, 149 insertions, 443 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.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/ui_guidelines/activity_task_design.jd b/docs/html/guide/practices/ui_guidelines/activity_task_design.jd index 9be72ee..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"> @@ -886,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. 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 6b686b1..4b6768f 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd @@ -49,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> @@ -81,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> @@ -100,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> @@ -239,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/index.jd b/docs/html/guide/practices/ui_guidelines/index.jd index 3255275..24fb855 100644 --- a/docs/html/guide/practices/ui_guidelines/index.jd +++ b/docs/html/guide/practices/ui_guidelines/index.jd @@ -39,26 +39,6 @@ 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 anontext 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 7576b6c..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"> |