diff --git a/docs/html/design/building-blocks/buttons.jd b/docs/html/design/building-blocks/buttons.jd
index 1f7e25d35b0dd..2a77e24be793b 100644
--- a/docs/html/design/building-blocks/buttons.jd
+++ b/docs/html/design/building-blocks/buttons.jd
@@ -1,5 +1,5 @@
page.title=Buttons
-page.tags="button","input"
+page.tags=button,input
@jd:body
diff --git a/docs/html/design/building-blocks/dialogs.jd b/docs/html/design/building-blocks/dialogs.jd
index f4bb87e9303c4..f9897f44e23d2 100644
--- a/docs/html/design/building-blocks/dialogs.jd
+++ b/docs/html/design/building-blocks/dialogs.jd
@@ -1,5 +1,5 @@
page.title=Dialogs
-page.tags="dialog","alert","popup","toast"
+page.tags=dialog,alert,popup,toast
@jd:body
diff --git a/docs/html/design/building-blocks/grid-lists.jd b/docs/html/design/building-blocks/grid-lists.jd
index 1a09ef551082a..cef7514b925b0 100644
--- a/docs/html/design/building-blocks/grid-lists.jd
+++ b/docs/html/design/building-blocks/grid-lists.jd
@@ -1,5 +1,5 @@
page.title=Grid Lists
-page.tags="gridview","layout","listview"
+page.tags=gridview,layout,listview
@jd:body
Progress bars and activity indicators signal to users that something is happening that will take a moment. Scrolling allows the user to navigate to content in the overflow using a swipe gesture. The
diff --git a/docs/html/design/building-blocks/seek-bars.jd b/docs/html/design/building-blocks/seek-bars.jd
index 9d38e36e2d908..1465688ed7f2c 100644
--- a/docs/html/design/building-blocks/seek-bars.jd
+++ b/docs/html/design/building-blocks/seek-bars.jd
@@ -1,5 +1,5 @@
page.title=Seek Bars and Sliders
-page.tags="seekbar","progressbar"
+page.tags=seekbar,progressbar
@jd:body
Interactive sliders make it possible to select a value from a continuous or discrete range of values
diff --git a/docs/html/design/building-blocks/spinners.jd b/docs/html/design/building-blocks/spinners.jd
index c00b639b39fb7..f8d92d4aec182 100644
--- a/docs/html/design/building-blocks/spinners.jd
+++ b/docs/html/design/building-blocks/spinners.jd
@@ -1,5 +1,5 @@
page.title=Spinners
-page.tags="spinner","dropdown"
+page.tags=spinner,dropdown
@jd:body
diff --git a/docs/html/design/building-blocks/switches.jd b/docs/html/design/building-blocks/switches.jd
index 74cab5ae21012..b2946897fed19 100644
--- a/docs/html/design/building-blocks/switches.jd
+++ b/docs/html/design/building-blocks/switches.jd
@@ -1,5 +1,5 @@
page.title=Switches
-page.tags="switch","checkbox","radiobutton","button"
+page.tags=switch,checkbox,radiobutton,button
@jd:body
Switches allow the user to select options. There are three kinds of switches: checkboxes, radio
diff --git a/docs/html/design/building-blocks/tabs.jd b/docs/html/design/building-blocks/tabs.jd
index 5a5da5d8ad970..1fa3461be37ee 100644
--- a/docs/html/design/building-blocks/tabs.jd
+++ b/docs/html/design/building-blocks/tabs.jd
@@ -1,5 +1,5 @@
page.title=Tabs
-page.tags="tabs","actionbar","navigation","viewpager"
+page.tags=tabs,actionbar,navigation,viewpager
@jd:body
Sometimes it is important to display contextual information for your app that's always visible.
Examples are the number of unread messages in a messaging inbox view or the Now Playing information
in a music player. Carefully plan which important information you would like to display and
-structure your action bars accordingly. Apps come in many varieties that address very different needs. For example: Allow for quick navigation between detail items with swipe views.
@@ -148,4 +148,4 @@ page.tags="buttons"
Replace previous implementations of Lights Out mode with the Lean Back or
Immersive approaches. Continue to use Lights Out mode for implementations of
your app targeted for earlier releases.
- In some situations, when a user invokes an action in your app, it's a good idea to confirm or acknowledge that action through text. Acknowledgment is unnecessary. The user will know the app is gone from the Home Screen because they made it disappear by dragging it away.
@@ -148,4 +148,4 @@ page.tags="full screen","immersive", "leanback"
Replace previous implementations of Lights Out mode with the Lean Back or
Immersive approaches. Continue to use Lights Out mode for implementations of
your app targeted for earlier releases.
- Gestures allow users to interact with your app by manipulating the screen objects you provide. The
diff --git a/docs/html/design/patterns/help.jd b/docs/html/design/patterns/help.jd
index ad5742d78757f..bf708b14eece7 100644
--- a/docs/html/design/patterns/help.jd
+++ b/docs/html/design/patterns/help.jd
@@ -1,5 +1,5 @@
page.title=Help
-page.tags="settings","preferences"
+page.tags=settings,preferences
@jd:body
We wish we could guarantee that if you follow every piece of advice on this website, everyone will be able to learn and use your app without a hitch. Sadly, that's not the case. People don't read help from start to finish. They scan around, looking for a piece of information containing the answer they need. Make it less burdensome with friendly formatting and layout choices like bold headings, bulleted and numbered lists, tables, and white space between paragraphs. And if you have a large amount of content, divide it into multiple screens to cut down on scrolling. What's better than a screen that's easy to scan? A screen that requires no scanning at all because the answer's right there. Consider having each screen in your app navigate to help that's relevant just to that screen. We call this contextual help, and it's the holy grail of user assistance. If you take this approach, be sure to also provide a way to get to the rest of the help content. What's better than a screen that's easy to scan? A screen that requires no scanning at all because the answer's right there. Consider having each screen in your app navigate to help that's relevant just to that screen. We call this contextual help, and it's the holy grail of user assistance. If you take this approach, be sure to also provide a way to get to the rest of the help content. Use design patterns wherever applicable so users don't face a learning curve. Choose defaults that are safe, neutral, and fit the majority of users. Give each setting a clear, concise label and use secondary text appropriately. Following Android design patterns doesn't mean that your app has to look the same as
diff --git a/docs/html/design/style/iconography.jd b/docs/html/design/style/iconography.jd
index fe4a3f9bcd226..5dde600272226 100644
--- a/docs/html/design/style/iconography.jd
+++ b/docs/html/design/style/iconography.jd
@@ -1,5 +1,5 @@
page.title=Iconography
-page.tags="icons"
+page.tags=icons
@jd:body
Devices vary not only in physical size, but also in screen density (
@@ -83,4 +83,4 @@ item to be removed.
diff --git a/docs/html/design/building-blocks/lists.jd b/docs/html/design/building-blocks/lists.jd
index 5514824b056b3..54fa442728335 100644
--- a/docs/html/design/building-blocks/lists.jd
+++ b/docs/html/design/building-blocks/lists.jd
@@ -1,5 +1,5 @@
page.title=Lists
-page.tags="listview","layout"
+page.tags=listview,layout
@jd:body
diff --git a/docs/html/design/building-blocks/pickers.jd b/docs/html/design/building-blocks/pickers.jd
index 6dd72ba06c22c..860a126fa44dd 100644
--- a/docs/html/design/building-blocks/pickers.jd
+++ b/docs/html/design/building-blocks/pickers.jd
@@ -1,5 +1,5 @@
page.title=Pickers
-page.tags="datepicker","timepicker"
+page.tags=datepicker,timepicker
@jd:body
diff --git a/docs/html/design/building-blocks/progress.jd b/docs/html/design/building-blocks/progress.jd
index 90732f49a3572..6946a753abdc2 100644
--- a/docs/html/design/building-blocks/progress.jd
+++ b/docs/html/design/building-blocks/progress.jd
@@ -1,5 +1,5 @@
page.title=Progress & Activity
-page.tags="progressbar","download","network"
+page.tags=progressbar,download,network
@jd:body
diff --git a/docs/html/design/building-blocks/text-fields.jd b/docs/html/design/building-blocks/text-fields.jd
index 383531b1adadf..4545bfbaf4965 100644
--- a/docs/html/design/building-blocks/text-fields.jd
+++ b/docs/html/design/building-blocks/text-fields.jd
@@ -1,5 +1,5 @@
page.title=Text Fields
-page.tags="text","edittext","input"
+page.tags=text,edittext,input
@jd:body
diff --git a/docs/html/design/downloads/index.jd b/docs/html/design/downloads/index.jd
index 16f55092c5147..ddeda5c457956 100644
--- a/docs/html/design/downloads/index.jd
+++ b/docs/html/design/downloads/index.jd
@@ -1,5 +1,5 @@
page.title=Downloads
-page tags="Icons", "stencils", "color swatches"
+page.tags=Icons,stencils,color swatches
@jd:body
@@ -277,4 +277,4 @@ actions exceeds the capacity of the main action bar, display them separately in
Take me straight to the answer
-
diff --git a/docs/html/design/style/metrics-grids.jd b/docs/html/design/style/metrics-grids.jd
index c375631514d37..a553475e7e621 100644
--- a/docs/html/design/style/metrics-grids.jd
+++ b/docs/html/design/style/metrics-grids.jd
@@ -1,5 +1,5 @@
page.title=Metrics and Grids
-page.tags="layout","screens"
+page.tags=layout,screens
@jd:body
Note: The SDK doesn’t currently support DFP, Ad Exchange or Search Ads for Mobile Apps but support is coming soon.
CAMERA permission, you would add this
android.hardware.wifiAndroid will run on many devices in many regions. To reach the most users, -your application should handle text, audio files, numbers, currency, and -graphics in ways appropriate to the locales where your application will be used. -
- -This document describes best practices for localizing Android -applications. The principles apply whether you are developing your application -using ADT with Eclipse, Ant-based tools, or any other IDE.
- -You should already have a working knowledge of Java and be familiar with -Android resource loading, the declaration of user interface elements in XML, -development considerations such as Activity lifecycle, and general principles of -internationalization and localization.
- -It is good practice to use the Android resource framework to separate the -localized aspects of your application as much as possible from the core Java -functionality:
- -For a short guide to localizing strings in your app, see the training lesson, Supporting Different Languages.
- - -Resources are text strings, layouts, sounds, graphics, and any other static -data that your Android application needs. An application can include multiple -sets of resources, each customized for a different device configuration. When a -user runs the application, Android automatically selects and loads the -resources that best match the device.
- -(This document focuses on localization and locale. For a complete description -of resource-switching and all the types of configurations that you can -specify — screen orientation, touchscreen type, and so on — see Providing -Alternative Resources.)
- -
- When you write your application:
- |
-
-
|
-
- When a user runs your application:
- |
-
When you write your application, you create default and alternative resources
-for your application to use. To create resources, you place files within
-specially named subdirectories of the project's res/ directory.
-
Whenever the application runs in a locale for which you have not provided
-locale-specific text, Android will load the default strings from
-res/values/strings.xml. If this default file is absent, or if it
-is missing a string that your application needs, then your application will not run
-and will show an error.
-The example below illustrates what can happen when the default text file is incomplete.
Example: -
An application's Java code refers to just two strings, text_a and
- text_b. This application includes a localized resource file
- (res/values-en/strings.xml) that defines text_a and
- text_b in English. This application also includes a default
- resource file (res/values/strings.xml) that includes a
-definition for text_a, but not for text_b:
-
res/values-en/strings.xml contains both of the needed text
- strings.To prevent this situation, make sure that a res/values/strings.xml
- file exists and that it defines every needed string. The situation applies to
- all types of resources, not just strings: You
- need to create a set of default resource files containing all
- the resources that your application calls upon — layouts, drawables,
- animations, etc. For information about testing, see
- Testing for Default Resources.
Put the application's default text in -a file with the following location and name:
- res/values/strings.xml (required directory)
The text strings in res/values/strings.xml should use the
-default language, which is the language that you expect most of your application's users to
-speak.
The default resource set must also include any default drawables and layouts,
- and can include other types of resources such as animations.
-
- res/drawable/(required directory holding at least
- one graphic file, for the application's icon on Google Play)
- res/layout/ (required directory holding an XML
- file that defines the default layout)
- res/anim/ (required if you have any
- res/anim-<qualifiers> folders)
- res/xml/ (required if you have any
- res/xml-<qualifiers> folders)
- res/raw/ (required if you have any
- res/raw-<qualifiers> folders)
-
Tip: In your code, examine each reference to - an Android resource. Make sure that a default resource is defined for each - one. Also make sure that the default string file is complete: A - localized string file can contain a subset of the strings, but the - default string file must contain them all. -
- -A large part of localizing an application is providing alternative text for -different languages. In some cases you will also provide alternative graphics, -sounds, layouts, and other locale-specific resources.
- -An application can specify many res/<qualifiers>/
-directories, each with different qualifiers. To create an alternative resource for
-a different locale, you use a qualifier that specifies a language or a
-language-region combination. (The name of a resource directory must conform
-to the naming scheme described in
-Providing
-Alternative Resources,
-or else it will not compile.)
Example:
- -Suppose that your application's default language is English. Suppose also
-that you want to localize all the text in your application to French, and most
-of the text in your application (everything except the application's title) to
-Japanese. In this case, you could create three alternative strings.xml
-files, each stored in a locale-specific resource directory:
res/values/strings.xmltitle.res/values-fr/strings.xmltitle.res/values-ja/strings.xmltitle.If your Java code refers to R.string.title, here is what will
-happen at runtime:
title from the res/values/strings.xml file.title from
-the res/values-fr/strings.xml file.Notice that if the device is set to Japanese, Android will look for
-title in the res/values-ja/strings.xml file. But
-because no such string is included in that file, Android will fall back to the
-default, and will load title in English from the
-res/values/strings.xml file.
If multiple resource files match a device's configuration, Android follows a -set of rules in deciding which file to use. Among the qualifiers that can be -specified in a resource directory name, locale almost always takes -precedence.
-Example:
- -Assume that an application includes a default set of graphics and two other -sets of graphics, each optimized for a different device setup:
- -res/drawable/res/drawable-small-land-stylus/res/drawable-ja/ If the application runs on a device that is configured to use Japanese,
-Android will load graphics from res/drawable-ja/, even if the
-device happens to be one that expects input from a stylus and has a QVGA
-low-density screen in landscape orientation.
Exception: The only qualifiers that take -precedence over locale in the selection process are MCC and MNC (mobile country -code and mobile network code).
- -Example:
- -Assume that you have the following situation:
- -R.string.text_ares/values-mcc404/strings.xml, which includes
-text_a in the application's default language, in this case
-English.res/values-hi/strings.xml, which includes
-text_a in Hindi.hi).Android will load text_a from
-res/values-mcc404/strings.xml (in English), even if the device is
-configured for Hindi. That is because in the resource-selection process, Android
-will prefer an MCC match over a language match.
The selection process is not always as straightforward as these examples -suggest. Please read How Android Finds -the Best-matching Resource for a more nuanced description of the -process. All the qualifiers are described and listed in order of -precedence in Table 2 of Providing -Alternative Resources.
- -In your application's Java code, you refer to resources using the syntax
-R.resource_type.resource_name or
-android.R.resource_type.resource_name.
-For more about this, see Accessing Resources.
For a complete overview of the process of localizing and distributing an Android application, -see the Localization -Checklist document.
- -You cannot assume anything about the device on which a user will -run your application. The device might have hardware that you were not -anticipating, or it might be set to a locale that you did not plan for or that -you cannot test. Design your application so that it will function normally or fail gracefully no -matter what device it runs on.
- -Important: Make sure that your application -includes a full set of default resources.
Make sure to include
-res/drawable/ and a res/values/ folders (without any
-additional modifiers in the folder names) that contain all the images and text
-that your application will need.
If an application is missing even one default resource, it will not run on a
- device that is set to an unsupported locale. For example, the
- res/values/strings.xml default file might lack one string that
- the application needs: When the application runs in an unsupported locale and
- attempts to load res/values/strings.xml, the user will see an
- error message and a Force Close button. An IDE such as Eclipse will not
- highlight this kind of error, and you will not see the problem when you
- test the application on a device or emulator that is set to a supported locale.
For more information, see Testing for Default Resources.
- - If you need to rearrange your layout to fit a certain language (for example
-German with its long words), you can create an alternative layout for that
-language (for example res/layout-de/main.xml). However, doing this
-can make your application harder to maintain. It is better to create a single
-layout that is more flexible.
Another typical situation is a language that requires something different in -its layout. For example, you might have a contact form that should include two -name fields when the application runs in Japanese, but three name fields when -the application runs in some other language. You could handle this in either of -two ways:
- -You probably do not need to create a locale-specific
-alternative for every resource in your application. For example, the layout
-defined in the res/layout/main.xml file might work in any locale,
-in which case there would be no need to create any alternative layout files.
-
Also, you might not need to create alternative text for every -string. For example, assume the following:
- -res/values/strings.xml. To do this, you could create a small file called
-res/values-en-rGB/strings.xml that includes only the strings that
-should be different when the application runs in the U.K. For all the rest of
-the strings, the application will fall back to the defaults and use what is
-defined in res/values/strings.xml.
You can look up the locale using the {@link android.content.Context} object -that Android makes available:
- -String locale = context.getResources().getConfiguration().locale.getDisplayName();- -
Keep in mind that the device you are testing may be significantly different from - the devices available to consumers in other geographies. The locales available - on your device may differ from those available on other devices. Also, the - resolution and density of the device screen may differ, which could affect - the display of strings and drawables in your UI.
- -To change the locale on a device, use the Settings application (Home > -Menu > Settings > Locale & text > Select locale).
- -For details about using the emulator, see See Android Emulator.
-A "custom" locale is a language/region combination that the Android -system image does not explicitly support. (For a list of supported locales in -Android platforms see the Version Notes in the SDK tab). You can test -how your application will run in a custom locale by creating a custom locale in -the emulator. There are two ways to do this:
- -When you set the emulator to a locale that is not available in the Android -system image, the system itself will display in its default language. Your -application, however, should localize properly.
- -To change the locale in the emulator by using the adb shell.
- -fr for French and CA for Canada.adb shell-e option:adb -e shell#), run this command: setprop persist.sys.language [language code];setprop
-persist.sys.country [country code];stop;sleep 5;start
- Replace bracketed sections with the appropriate codes from Step
-1.For instance, to test in Canadian French:
- -setprop persist.sys.language fr;setprop persist.sys.country
-CA;stop;sleep 5;start
This will cause the emulator to restart. (It will look like a full reboot, -but it is not.) Once the Home screen appears again, re-launch your application (for -example, click the Run icon in Eclipse), and the application will launch with -the new locale.
- -Here's how to test whether an application includes every string resource that it needs:
-res/values-fr/ but does not have any Spanish strings in
- res/values-es/, then set the emulator's locale to Spanish.
- (You can use the Custom Locale application to set the emulator to an
- unsupported locale.)res/values/strings.xml file includes a definition for
- every string that the application uses.If the test is successful, repeat it for other types of
- configurations. For example, if the application has a layout file called
- res/layout-land/main.xml but does not contain a file called
- res/layout-port/main.xml, then set the emulator or device to
- portrait orientation and see if the application will run.
-
-
-
+page.title=Localizing with Resources
+parent.title=Application Resources
+page.tags=localizing,localization,resources,formats,l10n
+parent.link=index.html
+@jd:body
+
+
Android will run on many devices in many regions. To reach the most users, +your application should handle text, audio files, numbers, currency, and +graphics in ways appropriate to the locales where your application will be used. +
+ +This document describes best practices for localizing Android +applications. The principles apply whether you are developing your application +using ADT with Eclipse, Ant-based tools, or any other IDE.
+ +You should already have a working knowledge of Java and be familiar with +Android resource loading, the declaration of user interface elements in XML, +development considerations such as Activity lifecycle, and general principles of +internationalization and localization.
+ +It is good practice to use the Android resource framework to separate the +localized aspects of your application as much as possible from the core Java +functionality:
+ +For a short guide to localizing strings in your app, see the training lesson, Supporting Different Languages.
+ + +Resources are text strings, layouts, sounds, graphics, and any other static +data that your Android application needs. An application can include multiple +sets of resources, each customized for a different device configuration. When a +user runs the application, Android automatically selects and loads the +resources that best match the device.
+ +(This document focuses on localization and locale. For a complete description +of resource-switching and all the types of configurations that you can +specify — screen orientation, touchscreen type, and so on — see Providing +Alternative Resources.)
+ +
+ When you write your application:
+ |
+
+
|
+
+ When a user runs your application:
+ |
+
When you write your application, you create default and alternative resources
+for your application to use. To create resources, you place files within
+specially named subdirectories of the project's res/ directory.
+
Whenever the application runs in a locale for which you have not provided
+locale-specific text, Android will load the default strings from
+res/values/strings.xml. If this default file is absent, or if it
+is missing a string that your application needs, then your application will not run
+and will show an error.
+The example below illustrates what can happen when the default text file is incomplete.
Example: +
An application's Java code refers to just two strings, text_a and
+ text_b. This application includes a localized resource file
+ (res/values-en/strings.xml) that defines text_a and
+ text_b in English. This application also includes a default
+ resource file (res/values/strings.xml) that includes a
+definition for text_a, but not for text_b:
+
res/values-en/strings.xml contains both of the needed text
+ strings.To prevent this situation, make sure that a res/values/strings.xml
+ file exists and that it defines every needed string. The situation applies to
+ all types of resources, not just strings: You
+ need to create a set of default resource files containing all
+ the resources that your application calls upon — layouts, drawables,
+ animations, etc. For information about testing, see
+ Testing for Default Resources.
Put the application's default text in +a file with the following location and name:
+ res/values/strings.xml (required directory)
The text strings in res/values/strings.xml should use the
+default language, which is the language that you expect most of your application's users to
+speak.
The default resource set must also include any default drawables and layouts,
+ and can include other types of resources such as animations.
+
+ res/drawable/(required directory holding at least
+ one graphic file, for the application's icon on Google Play)
+ res/layout/ (required directory holding an XML
+ file that defines the default layout)
+ res/anim/ (required if you have any
+ res/anim-<qualifiers> folders)
+ res/xml/ (required if you have any
+ res/xml-<qualifiers> folders)
+ res/raw/ (required if you have any
+ res/raw-<qualifiers> folders)
+
Tip: In your code, examine each reference to + an Android resource. Make sure that a default resource is defined for each + one. Also make sure that the default string file is complete: A + localized string file can contain a subset of the strings, but the + default string file must contain them all. +
+ +A large part of localizing an application is providing alternative text for +different languages. In some cases you will also provide alternative graphics, +sounds, layouts, and other locale-specific resources.
+ +An application can specify many res/<qualifiers>/
+directories, each with different qualifiers. To create an alternative resource for
+a different locale, you use a qualifier that specifies a language or a
+language-region combination. (The name of a resource directory must conform
+to the naming scheme described in
+Providing
+Alternative Resources,
+or else it will not compile.)
Example:
+ +Suppose that your application's default language is English. Suppose also
+that you want to localize all the text in your application to French, and most
+of the text in your application (everything except the application's title) to
+Japanese. In this case, you could create three alternative strings.xml
+files, each stored in a locale-specific resource directory:
res/values/strings.xmltitle.res/values-fr/strings.xmltitle.res/values-ja/strings.xmltitle.If your Java code refers to R.string.title, here is what will
+happen at runtime:
title from the res/values/strings.xml file.title from
+the res/values-fr/strings.xml file.Notice that if the device is set to Japanese, Android will look for
+title in the res/values-ja/strings.xml file. But
+because no such string is included in that file, Android will fall back to the
+default, and will load title in English from the
+res/values/strings.xml file.
If multiple resource files match a device's configuration, Android follows a +set of rules in deciding which file to use. Among the qualifiers that can be +specified in a resource directory name, locale almost always takes +precedence.
+Example:
+ +Assume that an application includes a default set of graphics and two other +sets of graphics, each optimized for a different device setup:
+ +res/drawable/res/drawable-small-land-stylus/res/drawable-ja/ If the application runs on a device that is configured to use Japanese,
+Android will load graphics from res/drawable-ja/, even if the
+device happens to be one that expects input from a stylus and has a QVGA
+low-density screen in landscape orientation.
Exception: The only qualifiers that take +precedence over locale in the selection process are MCC and MNC (mobile country +code and mobile network code).
+ +Example:
+ +Assume that you have the following situation:
+ +R.string.text_ares/values-mcc404/strings.xml, which includes
+text_a in the application's default language, in this case
+English.res/values-hi/strings.xml, which includes
+text_a in Hindi.hi).Android will load text_a from
+res/values-mcc404/strings.xml (in English), even if the device is
+configured for Hindi. That is because in the resource-selection process, Android
+will prefer an MCC match over a language match.
The selection process is not always as straightforward as these examples +suggest. Please read How Android Finds +the Best-matching Resource for a more nuanced description of the +process. All the qualifiers are described and listed in order of +precedence in Table 2 of Providing +Alternative Resources.
+ +In your application's Java code, you refer to resources using the syntax
+R.resource_type.resource_name or
+android.R.resource_type.resource_name.
+For more about this, see Accessing Resources.
For a complete overview of the process of localizing and distributing an Android application, +see the Localization +Checklist document.
+ +You cannot assume anything about the device on which a user will +run your application. The device might have hardware that you were not +anticipating, or it might be set to a locale that you did not plan for or that +you cannot test. Design your application so that it will function normally or fail gracefully no +matter what device it runs on.
+ +Important: Make sure that your application +includes a full set of default resources.
Make sure to include
+res/drawable/ and a res/values/ folders (without any
+additional modifiers in the folder names) that contain all the images and text
+that your application will need.
If an application is missing even one default resource, it will not run on a
+ device that is set to an unsupported locale. For example, the
+ res/values/strings.xml default file might lack one string that
+ the application needs: When the application runs in an unsupported locale and
+ attempts to load res/values/strings.xml, the user will see an
+ error message and a Force Close button. An IDE such as Eclipse will not
+ highlight this kind of error, and you will not see the problem when you
+ test the application on a device or emulator that is set to a supported locale.
For more information, see Testing for Default Resources.
+ + If you need to rearrange your layout to fit a certain language (for example
+German with its long words), you can create an alternative layout for that
+language (for example res/layout-de/main.xml). However, doing this
+can make your application harder to maintain. It is better to create a single
+layout that is more flexible.
Another typical situation is a language that requires something different in +its layout. For example, you might have a contact form that should include two +name fields when the application runs in Japanese, but three name fields when +the application runs in some other language. You could handle this in either of +two ways:
+ +You probably do not need to create a locale-specific
+alternative for every resource in your application. For example, the layout
+defined in the res/layout/main.xml file might work in any locale,
+in which case there would be no need to create any alternative layout files.
+
Also, you might not need to create alternative text for every +string. For example, assume the following:
+ +res/values/strings.xml. To do this, you could create a small file called
+res/values-en-rGB/strings.xml that includes only the strings that
+should be different when the application runs in the U.K. For all the rest of
+the strings, the application will fall back to the defaults and use what is
+defined in res/values/strings.xml.
You can look up the locale using the {@link android.content.Context} object +that Android makes available:
+ +String locale = context.getResources().getConfiguration().locale.getDisplayName();+ +
Keep in mind that the device you are testing may be significantly different from + the devices available to consumers in other geographies. The locales available + on your device may differ from those available on other devices. Also, the + resolution and density of the device screen may differ, which could affect + the display of strings and drawables in your UI.
+ +To change the locale on a device, use the Settings application (Home > +Menu > Settings > Locale & text > Select locale).
+ +For details about using the emulator, see See Android Emulator.
+A "custom" locale is a language/region combination that the Android +system image does not explicitly support. (For a list of supported locales in +Android platforms see the Version Notes in the SDK tab). You can test +how your application will run in a custom locale by creating a custom locale in +the emulator. There are two ways to do this:
+ +When you set the emulator to a locale that is not available in the Android +system image, the system itself will display in its default language. Your +application, however, should localize properly.
+ +To change the locale in the emulator by using the adb shell.
+ +fr for French and CA for Canada.adb shell-e option:adb -e shell#), run this command: setprop persist.sys.language [language code];setprop
+persist.sys.country [country code];stop;sleep 5;start
+ Replace bracketed sections with the appropriate codes from Step
+1.For instance, to test in Canadian French:
+ +setprop persist.sys.language fr;setprop persist.sys.country
+CA;stop;sleep 5;start
This will cause the emulator to restart. (It will look like a full reboot, +but it is not.) Once the Home screen appears again, re-launch your application (for +example, click the Run icon in Eclipse), and the application will launch with +the new locale.
+ +Here's how to test whether an application includes every string resource that it needs:
+res/values-fr/ but does not have any Spanish strings in
+ res/values-es/, then set the emulator's locale to Spanish.
+ (You can use the Custom Locale application to set the emulator to an
+ unsupported locale.)res/values/strings.xml file includes a definition for
+ every string that the application uses.If the test is successful, repeat it for other types of
+ configurations. For example, if the application has a layout file called
+ res/layout-land/main.xml but does not contain a file called
+ res/layout-port/main.xml, then set the emulator or device to
+ portrait orientation and see if the application will run.
+
diff --git a/docs/html/guide/topics/resources/runtime-changes.jd b/docs/html/guide/topics/resources/runtime-changes.jd
index 45a548a602bca..695647ba9027a 100644
--- a/docs/html/guide/topics/resources/runtime-changes.jd
+++ b/docs/html/guide/topics/resources/runtime-changes.jd
@@ -1,5 +1,5 @@
page.title=Handling Runtime Changes
-page.tags="activity","lifecycle"
+page.tags=activity,lifecycle
@jd:body
The Android SDK provides a sample application that shows how to use the rotation vector sensor. The sample application is located in the API Demos code ( -OS - RotationVectorDemo).
\ No newline at end of file +OS - RotationVectorDemo). diff --git a/docs/html/guide/topics/sensors/sensors_position.jd b/docs/html/guide/topics/sensors/sensors_position.jd index 55b282b4c74fc..65b9350d7fa58 100644 --- a/docs/html/guide/topics/sensors/sensors_position.jd +++ b/docs/html/guide/topics/sensors/sensors_position.jd @@ -1,5 +1,5 @@ page.title=Position Sensors -page.tags="sensorevent","orientation","proximity" +page.tags=sensorevent,orientation,proximity @jd:bodyFor more information about this XML syntax, including how to define a disabled, hovered, or other button states, read about State List -Drawable.
\ No newline at end of file +Drawable. diff --git a/docs/html/guide/topics/ui/controls/pickers.jd b/docs/html/guide/topics/ui/controls/pickers.jd index 4c558406cc44a..31e4d3f521418 100644 --- a/docs/html/guide/topics/ui/controls/pickers.jd +++ b/docs/html/guide/topics/ui/controls/pickers.jd @@ -1,5 +1,5 @@ page.title=Pickers -page.tags="datepicker","timepicker" +page.tags=datepicker,timepicker @jd:bodyIf you implement the {@link
android.widget.AdapterView.OnItemSelectedListener} interface with your {@link
android.app.Activity} or {@link android.app.Fragment} (such as in the example above), you can pass
-this as the interface instance.
this as the interface instance.
diff --git a/docs/html/guide/topics/ui/controls/text.jd b/docs/html/guide/topics/ui/controls/text.jd
index c0b98737749f6..9474dee8e148f 100644
--- a/docs/html/guide/topics/ui/controls/text.jd
+++ b/docs/html/guide/topics/ui/controls/text.jd
@@ -1,5 +1,5 @@
page.title=Text Fields
-page.tags="edittext","autocompletetextview"
+page.tags=edittext,autocompletetextview
@jd:body
For details about all the layout attributes available to each child view of a {@link -android.widget.RelativeLayout}, see {@link android.widget.RelativeLayout.LayoutParams}.
\ No newline at end of file +android.widget.RelativeLayout}, see {@link android.widget.RelativeLayout.LayoutParams}. diff --git a/docs/html/guide/topics/ui/settings.jd b/docs/html/guide/topics/ui/settings.jd index d96447dc032f8..1d36430a9481a 100644 --- a/docs/html/guide/topics/ui/settings.jd +++ b/docs/html/guide/topics/ui/settings.jd @@ -1,5 +1,5 @@ page.title=Settings -page.tags="preference","preferenceactivity","preferencefragment" +page.tags=preference,preferenceactivity,preferencefragment @jd:body diff --git a/docs/html/samples/index.jd b/docs/html/samples/index.jd index c1213b6bbc712..ab15e32c1936e 100644 --- a/docs/html/samples/index.jd +++ b/docs/html/samples/index.jd @@ -1,5 +1,5 @@ page.title=Samples -page.tags="samples","examples","code" +page.tags=samples,examples,code @jd:body diff --git a/docs/html/sdk/index.jd b/docs/html/sdk/index.jd index a77cdfb416563..bc22416af907b 100644 --- a/docs/html/sdk/index.jd +++ b/docs/html/sdk/index.jd @@ -1,5 +1,5 @@ page.title=Android SDK -page.tags="download" +page.tags=download page.template=sdk header.hide=1 page.metaDescription=Download the official Android SDK to develop apps for Android-powered devices. diff --git a/docs/html/sdk/installing/studio.jd b/docs/html/sdk/installing/studio.jd index d57d75b0dfda5..e83d1e05e0991 100644 --- a/docs/html/sdk/installing/studio.jd +++ b/docs/html/sdk/installing/studio.jd @@ -1,5 +1,5 @@ page.title=Getting Started with Android Studio -page.tags="studio" +page.tags=studio @jd:body diff --git a/docs/html/tools/adk/adk.jd b/docs/html/tools/adk/adk.jd index 16517473e30ac..7e75c11be020a 100644 --- a/docs/html/tools/adk/adk.jd +++ b/docs/html/tools/adk/adk.jd @@ -1,5 +1,5 @@ page.title=Accessory Development Kit 2011 Guide -page.tags="adk" +page.tags=adk @jd:bodyThe Accessory Development Kit (ADK) is a reference implementation for hardware manufacturers and diff --git a/docs/html/tools/debugging/debugging-memory.jd b/docs/html/tools/debugging/debugging-memory.jd index a7f443c8524e7..fccb67ec7a609 100644 --- a/docs/html/tools/debugging/debugging-memory.jd +++ b/docs/html/tools/debugging/debugging-memory.jd @@ -1,5 +1,5 @@ page.title=Investigating Your RAM Usage -page.tags="memory","OutOfMemoryError" +page.tags=memory,OutOfMemoryError @jd:body
Tip: You can also perform the above steps by using the "monkey" test framework. For more information on running the monkey test framework, read the monkeyrunner -documentation.
\ No newline at end of file +documentation. diff --git a/docs/html/tools/help/adb.jd b/docs/html/tools/help/adb.jd index c25990f3289ba..1850123004488 100644 --- a/docs/html/tools/help/adb.jd +++ b/docs/html/tools/help/adb.jd @@ -1,7 +1,7 @@ page.title=Android Debug Bridge parent.title=Tools parent.link=index.html -page.tags="adb" +page.tags=adb @jd:bodyThe Draw 9-patch tool allows you to easily create a diff --git a/docs/html/tools/samples/index.jd b/docs/html/tools/samples/index.jd index 76ba37af10b5d..a0d11e967c421 100644 --- a/docs/html/tools/samples/index.jd +++ b/docs/html/tools/samples/index.jd @@ -1,5 +1,5 @@ page.title=Samples -page.tags="example","code" +page.tags=example,code @jd:body
To help you understand some fundamental Android APIs and coding practices, a variety of sample @@ -29,4 +29,4 @@ Android SDK, then execute {@code android sdk}. API level.
You can easily create new Android projects with the downloaded samples, modify them -if you'd like, and then run them on an emulator or device.
\ No newline at end of file +if you'd like, and then run them on an emulator or device. diff --git a/docs/html/training/accessibility/index.jd b/docs/html/training/accessibility/index.jd index 0af1d87605bb2..ea54dc4406b61 100644 --- a/docs/html/training/accessibility/index.jd +++ b/docs/html/training/accessibility/index.jd @@ -1,5 +1,5 @@ page.title=Implementing Accessibility -page.tags="navigation","input" +page.tags=navigation,input trainingnavtop=true startpage=true diff --git a/docs/html/training/activity-testing/index.jd b/docs/html/training/activity-testing/index.jd index ddede712d83ee..b9542b6de62f2 100644 --- a/docs/html/training/activity-testing/index.jd +++ b/docs/html/training/activity-testing/index.jd @@ -1,5 +1,5 @@ page.title=Testing Your Android Activity -page.tags="testing" +page.tags=testing trainingnavtop=true startpage=true diff --git a/docs/html/training/animation/index.jd b/docs/html/training/animation/index.jd index b6940f82221fc..4f3778844dbfd 100644 --- a/docs/html/training/animation/index.jd +++ b/docs/html/training/animation/index.jd @@ -1,5 +1,5 @@ page.title=Adding Animations -page.tags="Animator","views","layout","user interface" +page.tags=Animator,views,layout,user interface trainingnavtop=true startpage=true @@ -84,4 +84,4 @@ startpage=true