From 4143781cdea0741ce6e87967c4ab903288c3e4c3 Mon Sep 17 00:00:00 2001 From: Scott Main Date: Thu, 7 Jul 2011 14:51:56 -0700 Subject: [PATCH 01/17] docs: add docs for market OBB includes splitting the Licensing dev guide into multiple pages; Turned original licensing doc into a redirect to the new files that are under guide/market/licensing/; Fix all links pointing to app licensing Change-Id: Ic49493f0e560db225dd7a382ffabc904a2fa1228 --- docs/html/guide/appendix/install-location.jd | 2 +- docs/html/guide/developing/tools/proguard.jd | 2 +- docs/html/guide/guide_toc.cs | 22 +- docs/html/guide/market/expansion-files.jd | 1259 +++++++++ .../market/licensing/adding-licensing.jd | 1072 ++++++++ docs/html/guide/market/licensing/index.jd | 61 + .../market/licensing/licensing-reference.jd | 439 +++ docs/html/guide/market/licensing/overview.jd | 245 ++ .../html/guide/market/licensing/setting-up.jd | 707 +++++ docs/html/guide/publishing/licensing.html | 11 + docs/html/guide/publishing/licensing.jd | 2388 ----------------- docs/html/guide/publishing/preparing.jd | 3 +- docs/html/guide/publishing/publishing.jd | 4 +- .../guide/publishing/publishing_overview.jd | 3 +- .../guide/topics/manifest/manifest-element.jd | 2 +- docs/html/sitemap.txt | 2 +- 16 files changed, 3825 insertions(+), 2397 deletions(-) create mode 100644 docs/html/guide/market/expansion-files.jd create mode 100644 docs/html/guide/market/licensing/adding-licensing.jd create mode 100644 docs/html/guide/market/licensing/index.jd create mode 100644 docs/html/guide/market/licensing/licensing-reference.jd create mode 100644 docs/html/guide/market/licensing/overview.jd create mode 100644 docs/html/guide/market/licensing/setting-up.jd create mode 100644 docs/html/guide/publishing/licensing.html delete mode 100644 docs/html/guide/publishing/licensing.jd diff --git a/docs/html/guide/appendix/install-location.jd b/docs/html/guide/appendix/install-location.jd index 292d3e75d9974..e5ed226322d5e 100644 --- a/docs/html/guide/appendix/install-location.jd +++ b/docs/html/guide/appendix/install-location.jd @@ -174,7 +174,7 @@ external storage, it can never receive this broadcast.
Copy Protection
Your application cannot be installed to a device's SD card if it uses Android Market's Copy Protection feature. However, if you use Android Market's - Application Licensing instead, your + Application Licensing instead, your application can be installed to internal or external storage, including SD cards.
diff --git a/docs/html/guide/developing/tools/proguard.jd b/docs/html/guide/developing/tools/proguard.jd index eca262a3ba08e..ea8a1eabafdad 100644 --- a/docs/html/guide/developing/tools/proguard.jd +++ b/docs/html/guide/developing/tools/proguard.jd @@ -39,7 +39,7 @@ parent.link=index.html sized .apk file that is more difficult to reverse engineer. Because ProGuard makes your application harder to reverse engineer, it is important that you use it when your application utilizes features that are sensitive to security like when you are - Licensing Your Applications.

+ Licensing Your Applications.

ProGuard is integrated into the Android build system, so you do not have to invoke it manually. ProGuard runs only when you build your application in release mode, so you do not diff --git a/docs/html/guide/guide_toc.cs b/docs/html/guide/guide_toc.cs index 4a9a6848632a8..fd2ec93c0d87c 100644 --- a/docs/html/guide/guide_toc.cs +++ b/docs/html/guide/guide_toc.cs @@ -451,8 +451,24 @@

  • Publishing on Android Market
    • -
  • +
  • +
    Application Licensing +
    +
  • @@ -485,6 +501,10 @@
  • Multiple APK Support
    • +
  • + APK Expansion Files + new! +
    • diff --git a/docs/html/guide/market/expansion-files.jd b/docs/html/guide/market/expansion-files.jd new file mode 100644 index 0000000000000..09f1d2e090671 --- /dev/null +++ b/docs/html/guide/market/expansion-files.jd @@ -0,0 +1,1259 @@ +page.title=APK Expansion Files +@jd:body + + +
    +
    +

    Quickview

    +
      +
    • Recommended for most apps that exceed the 50MB APK limit
      • +
    • You can provide up to 4GB of additional data for each APK
      • +
    • Android Market hosts and serves the expansion files at no charge
      • +
    • The files can be any file type you want and are saved to the device's shared storage
      • +
    + +

    In this document

    +
      +
    1. Overview +
        +
      1. File name format
        2. +
      2. Storage location
        3. +
      3. Download process
        4. +
      4. Development checklist
        5. +
      +
      2. +
    2. Rules and Limitations
      3. +
    3. Downloading the Expansion Files +
        +
      1. About the Expansion Downloader Library
        2. +
      2. Preparing to use the Expansion Downloader Library
        3. +
      3. Declaring user permissions
        4. +
      4. Implementing the downloader service
        5. +
      5. Implementing the alarm receiver
        6. +
      6. Starting the download
        7. +
      7. Receiving download progress
        8. +
      +
      4. +
    4. Using APKExpansionPolicy
      5. +
    5. Reading the Expansion File +
        +
      1. Getting the file names
        2. +
      2. Using the APK Expansion Zip Library
        3. +
      +
      6. +
    6. Testing Your Expansion Files +
        +
      1. Testing file reads
        2. +
      2. Testing file downloads
        3. +
      +
      7. +
    7. Updating Your Application
      8. +
    + +

    See also

    +
      +
    1. Application Licensing
      2. +
    2. Multiple +APK Support
      3. +
    +
    +
    + + + +

    Android Market currently requires that your APK file be no more than 50MB. For most +applications, this is plenty of space for all the application's code and assets. +However, some apps need more space for high-fidelity graphics, media files, or other large assets. +Previously, if your app exceeded 50MB, you had to host and download the additional resources +yourself when the user opens the app. Hosting and serving the extra files can be costly, and the +user experience is often less than ideal. To make this process easier for you and more pleasant +for users, Android Market allows you to attach two large expansion files that supplement your +APK.

    + +

    Android Market hosts the expansion files for your application and serves them to the device at +no cost to you. The expansion files are saved to the device's shared storage location (the +SD card or USB-mountable partition; also known as the "external" storage) where your app can access +them. On most devices, Android Market downloads the expansion file(s) at the same time it +downloads the APK, so your application has everything it needs when the user opens it for the +first time. In some cases, however, your application must download the files from Android Market +when your application starts.

    + + + +

    Overview

    + +

    Each time you upload an APK using the Android Market Developer Console, you have the option to +add one or two expansion files to the APK. Each file can be up to 2GB and it can be any format you +choose, but we recommend you use a compressed file to conserve bandwidth during the download. +Conceptually, each expansion file plays a different role:

    + + + +

    Note: The patch expansion file is semantically the same as the +main expansion file—you can use each file any way you want. The system does +not use the patch expansion file to perform patching for your app. You must perform patching +yourself or be able to distinguish between the two files.

    + + + +

    File name format

    + +

    Each expansion file you upload can be any format you choose (ZIP, PDF, MP4, etc.). Regardless of +the file type, Android Market considers them opaque binary blobs and renames the files +using the following scheme:

    + +
    +[main|patch].<expansion-version>.<package-name>.obb
+
    + +

    There are three components to this scheme:

    + +
    +
    {@code main} or {@code patch}
    +
    Specifies whether the file is the main or patch expansion file. There can be +only one main file and one patch file for each APK.
    +
    {@code <expansion-version>}
    +
    This is an integer that matches the version code of the APK with which the expansion is +first associated (it matches the application's {@code android:versionCode} +value). +

    "First" is emphasized because although the Android Market Developer Console allows you to +re-use an uploaded expansion file with a new APK, the expansion file's name does not change—it +retains the version applied to it when you first uploaded the file.

    +
    {@code <package-name>}
    +
    Your application's Java-style package name.
    +
    + +

    For example, suppose your APK version is 314159 and your package name is com.example.app. If you +upload a main expansion file, the file is renamed to:

    +
    main.314159.com.example.app.obb
    + + +

    Storage location

    + +

    When Android Market downloads your expansion files to a device, it saves them to the system's +shared storage location. To ensure proper behavior, you must not delete, move, or rename the +expansion files. In the event that your application must perform the download from Android Market +itself, you must save the files to the exact same location.

    + +

    The specific location for your expansion files is:

    + +
    +<shared-storage>/Android/obb/<package-name>/
+
    + + +

    + +

    Note: The location of the shared storage may be +different on different devices, so you should never refer to the shared storage space using an +absolute URI path. Always use {@link android.os.Environment#getExternalStorageDirectory} to +retrieve the root directory of the shared storage location.

    + +

    For each application, there are never more than two expansion files in this directory. +One is the main expansion file and the other is the patch expansion file (if necessary). Previous +versions are overwritten when you update your application with new expansion files.

    + +

    If you must unpack the contents of your expansion files, do not delete the +{@code .obb} expansion files afterwards and do not save the unpacked data +in the same directory. You should save your unpacked files in the directory +specified by {@link android.content.Context#getExternalFilesDir getExternalFilesDir()}. However, +if possible, it's best if you use an expansion file format that allows you to read directly from +the file instead of requiring you to unpack the data. For example, we've provided a library +project called the APK Expansion Zip Library that reads your data directly +from the ZIP file.

    + +

    Note: If you're packaging media files into a ZIP, you can use media +playback calls on the files with offset and length controls (such as {@link +android.media.MediaPlayer#setDataSource(FileDescriptor,long,long) MediaPlayer.setDataSource()} and +{@link android.media.SoundPool#load(FileDescriptor,long,long,int) SoundPool.load()}) without the +need to unpack your ZIP. In order for this to work, you must not perform additional compression on +the media files when creating the ZIP packages. For example, when using the zip tool, +you should use the -n option to specify the file suffixes that should not be +compressed:
    +zip -n .mp4;.ogg main_expansion media_files

    + + +

    Download process

    + +

    Most of the time, Android Market downloads and saves your expansion files at the same time it +downloads the APK to the device. However, in some cases Android Market +cannot download the expansion files or the user might have deleted previously downloaded expansion +files. To handle these situations, your app must be able to download the files +itself when the main activity starts, using a URL provided by Android Market.

    + +

    The download process from a high level looks like this:

    + +
      +
    1. User selects to install your app from Android Market.
      2. +
    2. If Android Market is able to download the expansion files (which is the case for most +devices), it downloads them along with the APK. +

      If Android Market is unable to download the expansion files, it downloads the +APK only.

      +
      3. +
    3. When the user launches your application, your app must check whether the expansion files are +already saved on the device. +
        +
      1. If yes, your app is ready to go.
        2. +
      2. If no, your app must download the expansion files over HTTP from Android Market. Your app +must send a request to the Android Market client using the Android Market's Application Licensing service, which +responds with the name, file size, and URL for each expansion file. With this information, you then +download the files and save them to the proper storage location.
        3. +
      +
      4. +
    + +

    Caution: It is critical that you include the necessary code to +download the expansion files from Android Market in the event that the files are not already on the +device when your application starts. As discussed in the following section about Downloading the Expansion Files, we've made a library available to you that +greatly simplifies this process and performs the download from a service with a minimal amount of +code from you.

    + + + + +

    Development checklist

    + +

    Here's a summary of the tasks you should perform to use expansion files with your +application:

    + +
      +
    1. First determine whether your application absolutely requires more than 50MB per installation. +Space is precious and you should keep your total application size as small as possible. If your app +uses more than 50MB in order to provide multiple versions of your graphic assets for multiple screen +densities, consider instead publishing multiple APKs in which each APK +contains only the assets required for the screens that it targets.
      2. +
    2. Determine which application resources to separate from your APK and package them in a +file to use as the main expansion file. +

      Normally, you should only use the second patch expansion file when performing updates to +the main expansion file. However, if your resources exceed the 2GB limit for the main +expansion file, you can use the patch file for the rest of your assets.

      +
      3. +
    3. Develop your application such that it uses the resources from your expansion files in the +device's shared storage location. +

      Remember that you must not delete, move, or rename the expansion files.

      +

      If your application doesn't demand a specific format, we suggest you create ZIP files for +your expansion files, then read them using the APK Expansion Zip +Library.

      +
      4. +
    4. Add logic to your application's main activity that checks whether the expansion files +are on the device upon start-up. If the files are not on the device, use Android Market's Application Licensing service to request URLs +for the expansion files, then download and save them. +

      To greatly reduce the amount of code you must write and ensure a good user experience +during the download, we recommend you use the Expansion Downloader +Library to implement your download behavior.

      +

      If you build your own download service instead of using the library, be aware that you +must not change the name of the expansion files and must save them to the proper +storage location.

      5. +
    + +

    Once you've finished your application development, follow the guide to Testing +Your Expansion Files.

    + + + + + + +

    Rules and Limitations

    + +

    Adding APK expansion files is a feature available when you upload your application using the +Android Market Developer Console. When uploading your application for the first time or updating an +application that uses expansion files, you must be aware of the following rules and limitations:

    + +
      +
    1. Each expansion file can be no more than 2GB.
      2. +
    2. In order to download your expansion files from Android Market, the user must have +acquired your application from Android Market. Android Market will not +provide the URLs for your expansion files if the application was installed by other means.
      3. +
    3. When performing the download from within your application, the URL that Android Market +provides for each file is unique for every download and each one expires shortly after it is given +to your application.
      4. +
    4. If you update your application with a new APK or upload multiple APKs for the same +application, you can select expansion files that you've uploaded for a previous APK. The +expansion file's name does not change—it retains the version received by the APK to +which the file was originally associated.
      5. +
    5. If you use expansion files in combination with multiple APKs in order to +provide different expansion files for different devices, you still must upload separate APKs +for each device in order to provide a unique {@code versionCode} +value and declare different filters for +each APK.
      6. +
    6. You cannot issue an update to your application by changing the expansion files +alone—you must upload a new APK to update your app. If your changes only +concern the assets in your expansion files, you can update your APK simply by changing the {@code versionCode} (and +perhaps also the {@code +versionName}).

      7. +
    7. Do not save other data into your obb/ +directory. If you must unpack some data, save it into the location specified by {@link +android.content.Context#getExternalFilesDir getExternalFilesDir()}.
      8. +
    8. Do not delete or rename the {@code .obb} expansion file (unless you're +performing an update). Doing so will cause Android Market (or your app itself) to repeatedly +download the expansion file.
      9. +
    9. When updating an expansion file manually, you must delete the previous expansion file.
      10. +
    + + + + + + + + + +

    Downloading the Expansion Files

    + +

    In most cases, Android Market downloads and saves your expansion files to the device at the same +time it installs or updates the APK. This way, the expansion files are available when your +application launches for the first time. However, in some cases your app must download the +expansion files itself by requesting them from a URL provided to you in a response +from Android Market's Application Licensing service.

    + +

    The basic logic you need to download your expansion files is the following:

    + +
      +
    1. When your application starts, look for the expansion files on the shared storage location (in the +Android/obb/<package-name>/ directory). +
        +
      1. If the expansion files are there, you're all set and your application can continue.
        2. +
      2. If the expansion files are not there: +
          +
        1. Perform a request using the License Verification Library to get your +app's expansion file names, sizes, and URLs.
          2. +
        2. Use the URLs provided by Android Market to download the expansion files and save +the expansion files. You must save the files to the shared storage location +(Android/obb/<package-name>/) and use the exact file name provided +by Android Market's response. +

          Note: The URL that Android Market provides for your +expansion files is unique for every download and each one expires shortly after it is given to +your application.

          +
          3. +
        +
        3. +
      +
      2. +
    + + +

    If your application is free (not a paid app), then you probably haven't used the Application Licensing service. It's primarily +designed for you to enforce +licensing policies for your application and ensure that the user has the right to +use your app (he or she rightfully paid for it on Android Market). In order to facilitate the +expansion file functionality, the licensing service has been enhanced to provide a response +to your application that includes the URL of your application's expansion files that are hosted +on Android Market. So, even if your application is free for users, you need to include the Android +Market License Verification Library (LVL) to use APK expansion files. Of course, if your application +is free, you don't need to enforce license verification—you simply need the +library to perform the request that returns the URL of your expansion files.

    + +

    Note: Whether your application is free or not, Android Market +returns the expansion file URLs only if the user acquired your application from Android Market.

    + +

    To simplify this work for you, we've built the Expansion Downloader +Library, which requests the expansion file URLs through the licensing service and +downloads the expansion files for you. By adding this library and a few code hooks to your +application, almost all the work to download the expansion files is already coded for you, including +a status notification that tracks the download progress. As such, in order to provide the best user +experience with minimal effort on your behalf, we recommend you use the +Expansion Downloader Library to download your expansion files. The information in the following +sections explain how to integrate the library into your application.

    + +

    If you'd rather develop your own solution to download the expansion files using the Android +Market URLs, you must follow the Application +Licensing documentation to perform a license request, then retrieve the expansion file names, +sizes, and URLs from the response extras. You should use the {@code +APKExpansionPolicy} class (included in the License Verification Library) as your licensing +policy, which captures the expansion file names, sizes, and URLs from the licensing service..

    + + + +

    About the Expansion Downloader Library

    + +

    To use APK expansion files with your application and provide the best user experience with +minimal effort on your behalf, we recommend you use the Android Market Expansion Downloader +Library.

    + +

    As mentioned above, in order to use expansion files hosted by Android Market, you must use +the Android Market License Verification Library (LVL) to request the URLs from which to download the +expansion files. In addition to the LVL, you need a set of code that downloads the expansion files +over an HTTP connection and saves them to the proper location on the device's shared storage. +As you build this procedure into your application, there are several issues you should take into +consideration:

    + + + +

    Fortunately, the Android Market Expansion Downloader Library handles all of this work for you +and also allows your app to pause and resume the download. To implement expansion file downloads +using the library, all you need to do is:

    + + + + + +

    Preparing to use the Expansion Downloader Library

    + +

    To use the Expansion Downloader Library, you need to +download two packages from the SDK Manager and add the appropriate libraries to your +application.

    + +

    First, open the Android SDK Manager, expand Extras and download:

    + + +

    If you're using Eclipse, create a project for each library and add it to your app:

    +
      +
    1. Create a new Library Project for the License Verification Library and Expansion Downloader +Library. For each library: +
        +
      1. Begin a new Android project.
        2. +
      2. Select Create project from existing +source and choose the library from the {@code <sdk>/extras/google/} directory.
        3. +
      3. Specify a Project Name such as "Android Market License Library" and "Market +Downloader +Library"
        4. +
      4. Click Finish.
        5. +
      +

      Note: The Expansion Downloader Library depends on the License +Verification Library. Be sure to add the License +Verification Library to the Expansion Downloader Library's project properties (same process as +steps 2 and 3 below).

      +
      2. +
    2. Right-click the Android project in which you want to use APK expansion files and +select Properties.
      3. +
    3. In the Library panel, click Add to select and add each of the +libraries to your application.
      4. +
    + +

    Or, from a command line, update your project to include the libraries:

    +
      +
    1. Change directories to the <sdk>/tools/ directory.
      2. +
    2. Execute android update project with the {@code --library} option to add both the +LVL and the Downloader Library to your project. For example: +
      +android update project --path ~/Android/MyApp \
+--library ~/android_sdk/extras/google/market_licensing \
+--library ~/android_sdk/extras/google/market_downloader
+
      +
      3. +
    + +

    With both the License Verification Library and Expansion Downloader Library added to your +application, you'll be able to quickly integrate the ability to download expansion files from +Android Market. The format that you choose for the expansion files and how you read them +from the shared storage is a separate implementation that you should consider based on your +application needs.

    + +

    Tip: The Expansion Downloader package includes a sample application +that shows how to use the Expansion Downloader library in an app. The sample uses a third library +available in the Expansion Downloader package called the APK Expansion Zip Library. If you plan on +using ZIP files for your expansion files, we suggest you also add the APK Expansion Zip Library to +your application. You might want to use the sample application as a starting point for your +implementation.

    + + + +

    Declaring user permissions

    + +

    In order to download the expansion files, the Expansion Downloader Library +requires several permissions that you must declare in your application's manifest file. They +are:

    + +
    +<manifest ...>
+    <!-- Required to access Android Market Licensing -->
+    <uses-permission android:name="com.android.vending.CHECK_LICENSE" />
+
+    <!-- Required to download files from Android Market -->
+    <uses-permission android:name="android.permission.INTERNET" />
+
+    <!-- Required to keep CPU alive while downloading files (NOT to keep screen awake) -->
+    <uses-permission android:name="android.permission.WAKE_LOCK" />
+
+    <!-- Required to poll the state of the network connection and respond to changes -->
+    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
+
+    <!-- Required to check whether Wi-Fi is enabled -->
+    <uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
+
+    <!-- Required to read and write the expansion files on shared storage -->
+    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
+    ...
+</manifest>
+
    + +

    Note: By default, the Expansion Downloader Library requires API +level 4, but the APK Expansion Zip Library requires API level 5.

    + + +

    Implementing the downloader service

    + +

    In order to perform downloads in the background, the Expansion Downloader Library provides its +own {@link android.app.Service} subclass called {@code DownloaderService} that you should extend. In +addition to downloading the expansion files for you, the {@code DownloaderService} also:

    + + + +

    All you need to do is create a class in your application that extends the {@code +DownloaderService} class and override three methods to provide specific application details:

    + +
    +
    {@code getPublicKey()}
    +
    This must return a string that is the Base64-encoded RSA public key for your publisher +account, available from the profile page on the Android Market Developer Console (see Setting Up for Licensing).
    +
    {@code getSALT()}
    +
    This must return an array of random bytes that the licensing {@code Policy} uses to +create an {@code +Obfuscator}. The salt ensures that your obfuscated {@link android.content.SharedPreferences} +file in which your licensing data is saved will be unique and non-discoverable.
    +
    {@code getAlarmReceiverClassName()}
    +
    This must return the class name of the {@link android.content.BroadcastReceiver} in +your application that should receive the alarm indicating that the download should be +restarted (which might happen if the downloader service unexpectedly stops).
    +
    + +

    For example, here's a complete implementation of {@code DownloaderService}:

    + +
    +public class SampleDownloaderService extends DownloaderService {
+    // You must use the public key belonging to your publisher account
+    public static final String BASE64_PUBLIC_KEY = "YourAndroidMarketLVLKey";
+    // You should also modify this salt
+    public static final byte[] SALT = new byte[] { 1, 42, -12, -1, 54, 98,
+            -100, -12, 43, 2, -8, -4, 9, 5, -106, -107, -33, 45, -1, 84
+    };
+
+    @Override
+    public String getPublicKey() {
+        return BASE64_PUBLIC_KEY;
+    }
+
+    @Override
+    public byte[] getSALT() {
+        return SALT;
+    }
+
+    @Override
+    public String getAlarmReceiverClassName() {
+        return SampleAlarmReceiver.class.getName();
+    }
+}
+
    + +

    Notice: You must update the {@code BASE64_PUBLIC_KEY} value +to be the public key belonging to your publisher account. You can find the key in the Android +Market Developer Console under your profile information. This is necessary even when testing +your downloads.

    + +

    Remember to declare the service in your manifest file:

    +
    +<application ...>
+    <service android:name=".SampleDownloaderService" />
+    ...
+</application>
+
    + + + +

    Implementing the alarm receiver

    + +

    In order to monitor the progress of the file downloads and restart the download if necessary, the +{@code DownloaderService} schedules an {@link android.app.AlarmManager#RTC_WAKEUP} alarm that +delivers an {@link android.content.Intent} to a {@link android.content.BroadcastReceiver} in your +application. You must define the {@link android.content.BroadcastReceiver} to call an API +from the Expansion Downloader Library that checks the status of the download and restarts +it if necessary.

    + +

    You simply need to override the {@link android.content.BroadcastReceiver#onReceive +onReceive()} method to call {@code +DownloaderClientMarshaller.startDownloadServiceIfRequired()}.

    + +

    For example:

    + +
    +public class SampleAlarmReceiver extends BroadcastReceiver {
+    @Override
+    public void onReceive(Context context, Intent intent) {
+        try {
+            DownloaderClientMarshaller.startDownloadServiceIfRequired(context, intent,
+                    SampleDownloaderService.class);
+        } catch (NameNotFoundException e) {
+            e.printStackTrace();
+        }      
+    }
+}
+
    + +

    Notice that this is the class for which you must return the name +in your service's {@code getAlarmReceiverClassName()} method (see the previous section).

    + +

    Remember to declare the receiver in your manifest file:

    +
    +<application ...>
+    <receiver android:name=".SampleAlarmReceiver" />
+    ...
+</application>
+
    + + + +

    Starting the download

    + +

    The main activity in your application (the one started by your launcher icon) is +responsible for verifying whether the expansion files are already on the device and initiating +the download if they are not.

    + +

    Starting the download using the Expansion Downloader library requires the following +procedures:

    + +
      +
    1. Check whether the files have been downloaded. +

      The Expansion Downloader library includes some APIs in the {@code Helper} class to +help with this process:

      +
        +
      • {@code getExtendedAPKFileName(Context, c, boolean mainFile, int +versionCode)}
        • +
      • {@code doesFileExist(Context c, String fileName, long fileSize)}
        • +
      +

      For example, the sample app provided in the Expansion Downloader package calls the +following method in the activity's {@link android.app.Activity#onCreate onCreate()} method to check +whether the expansion files already exist on the device:

      +
      +boolean expansionFilesDelivered() {
+    for (XAPKFile xf : xAPKS) {
+        String fileName = Helpers.getExpansionAPKFileName(this, xf.mIsBase, xf.mFileVersion);
+        if (!Helpers.doesFileExist(this, fileName, xf.mFileSize, false))
+            return false;
+    }
+    return true;
+}        
+
      +

      In this case, each {@code XAPKFile} object holds the version number and file size of a known +expansion file and a boolean as to whether it's the main expansion file.

      +

      If this method returns false, then the application must begin the download.

      +
      2. +
    2. Start the download by calling the static method {@code +DownloaderClientMarshaller.startDownloadServiceIfRequired(Context c, PendingIntent +notificationClient, Class<?> serviceClass)}. +

      The method takes the following parameters:

      +
        +
      • context: Your application's {@link android.content.Context}.
        • +
      • notificationClient: A {@link android.app.PendingIntent} to start your main +activity. This is used in the {@link android.app.Notification} that the {@code DownloaderService} +creates to show the download progress. When the user selects the notification, the system +invokes the {@link android.app.PendingIntent} you supply here and should open the activity +that shows the download progress (usually the same activity that started the download).
        • +
      • serviceClass: The {@link java.lang.Class} object for your implementation of +{@code DownloaderService}, required to start the service and begin the download if necessary.
        • +
      +

      The method returns an integer that indicates +whether or not the download is required. Possible values are:

      +
        +
      • {@code NO_DOWNLOAD_REQUIRED}: Returned if the files already +exist or a download is already in progress.
        • +
      • {@code LVL_CHECK_REQUIRED}: Returned if a license verification is +required in order to acquire the expansion file URLs.
        • +
      • {@code DOWNLOAD_REQUIRED}: Returned if the expansion file URLs are already known, +but have not been downloaded.
        • +
      +

      The behavior for {@code LVL_CHECK_REQUIRED} and {@code DOWNLOAD_REQUIRED} are essentially the +same and you normally don't need to be concerned about them. In your main activity that calls {@code +startDownloadServiceIfRequired()}, you can simply check whether or not the response is {@code +NO_DOWNLOAD_REQUIRED}. If the response is anything other than {@code NO_DOWNLOAD_REQUIRED}, +the Expansion Downloader library begins the download and you should update your activity UI to +display the download progress (see the next step). If the response is {@code +NO_DOWNLOAD_REQUIRED}, then the files are available and your application can start.

      +

      For example:

      +
      +@Override
+public void onCreate(Bundle savedInstanceState) {
+    // Check if expansion files are available before going any further
+    if (!expansionFilesDelivered()) {
+        // Build an Intent to start this activity from the Notification
+        Intent notifierIntent = new Intent(this, MainActivity.getClass());
+        notifierIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK |
+                                Intent.FLAG_ACTIVITY_CLEAR_TOP);
+        ...
+        PendingIntent pendingIntent = PendingIntent.getActivity(this, 0,
+                notifierIntent, PendingIntent.FLAG_UPDATE_CURRENT);
+        
+        // Start the download service (if required)
+        int startResult = DownloaderClientMarshaller.startDownloadServiceIfRequired(this,
+                        pendingIntent, SampleDownloaderService.class);
+        // If download has started, initialize this activity to show download progress
+        if (startResult != DownloaderClientMarshaller.NO_DOWNLOAD_REQUIRED) {
+            // This is where you do set up to display the download progress (next step)
+            ...
+            return;
+        } // If the download wasn't necessary, fall through to start the app
+    }
+    startApp(); // Expansion files are available, start the app
+}
+
      +
      3. +
    3. When the {@code startDownloadServiceIfRequired()} method returns anything other +than {@code NO_DOWNLOAD_REQUIRED}, create an instance of {@code IStub} by +calling {@code DownloaderClientMarshaller.CreateStub(IDownloaderClient client, Class<?> +downloaderService)}. The {@code IStub} provides a binding between your activity to the downloader +service such that your activity receives callbacks about the download progress. +

      In order to instantiate your {@code IStub} by calling {@code CreateStub()}, you must pass it +an implementation of the {@code IDownloaderClient} interface and your {@code DownloaderService} +implementation. The next section about Receiving download progress discusses +the {@code IDownloaderClient} interface, which you should usually implement in your {@link +android.app.Activity} class so you can update the activity UI when the download state changes.

      +

      We recommend that you call {@code +CreateStub()} to instantiate your {@code IStub} during your activity's {@link +android.app.Activity#onCreate onCreate()} method, after {@code startDownloadServiceIfRequired()} +starts the download.

      +

      For example, in the previous code sample for {@link android.app.Activity#onCreate +onCreate()}, you can respond to the {@code startDownloadServiceIfRequired()} result like this:

      +
      +        // Start the download service (if required)
+        int startResult = DownloaderClientMarshaller.startDownloadServiceIfRequired(this,
+                        pendingIntent, SampleDownloaderService.class);
+        // If download has started, initialize activity to show progress
+        if (startResult != DownloaderClientMarshaller.NO_DOWNLOAD_REQUIRED) {
+            // Instantiate a member instance of IStub
+            mDownloaderClientStub = DownloaderClientMarshaller.CreateStub(this,
+                    SampleDownloaderService.class);
+            // Inflate layout that shows download progress
+            setContentView(R.layout.downloader_ui);
+            return;
+        }
+
      + +

      After the {@link android.app.Activity#onCreate onCreate()} method returns, your activity +receives a call to {@link android.app.Activity#onResume onResume()}, which is where you should then +call {@code connect()} on the {@code IStub}, passing it your application's {@link +android.content.Context}. Conversely, you should call +{@code disconnect()} in your activity's {@link android.app.Activity#onStop onStop()} callback.

      +
      +@Override
+protected void onResume() {
+    if (null != mDownloaderClientStub) {
+        mDownloaderClientStub.connect(this);
+    }
+    super.onResume();
+}
+
+@Override
+protected void onStop() {
+    if (null != mDownloaderClientStub) {
+        mDownloaderClientStub.disconnect(this);
+    }
+    super.onStop();
+}
+
      +

      Calling {@code connect()} on the {@code IStub} binds your activity to the {@code +DownloaderService} such that your activity receives callbacks regarding changes to the download +state through the {@code IDownloaderClient} interface.

      +
      4. +
    + + + +

    Receiving download progress

    + +

    To receive updates regarding the download progress and to interact with the {@code +DownloaderService}, you must implement the Downloader Library's {@code IDownloaderClient} interface. +Usually, the activity you use to start the download should implement this interface in order to +display the download progress and send requests to the service.

    + +

    The required interface methods for {@code IDownloaderClient} are:

    + +
    +
    {@code onServiceConnected(Messenger m)}
    +
    After you instantiate the {@code IStub} in your activity, you'll receive a call to this +method, which passes a {@link android.os.Messenger} object that's connected with your instance +of {@code DownloaderService}. To send requests to the service, such as to pause and resume +downloads, you must call {@code DownloaderServiceMarshaller.CreateProxy()} to receive the {@code +IDownloaderService} interface connected to the service. +

    A recommended implementation looks like this:

    +
    +private IDownloaderService mRemoteService;
+...
+
+@Override
+public void onServiceConnected(Messenger m) {
+    mRemoteService = DownloaderServiceMarshaller.CreateProxy(m);
+    mRemoteService.onClientUpdated(mDownloaderClientStub.getMessenger());
+}
+
    +

    With the {@code IDownloaderService} object initialized, you can send commands to the +downloader service, such as to pause and resume the download ({@code requestPauseDownload()} +and {@code requestContinueDownload()}).

    +
    +
    {@code onDownloadStateChanged(int newState)}
    +
    The download service calls this when a change in download state occurs, such as the +download begins or completes. +

    The newState value will be one of several possible values specified in +by one of the {@code IDownloaderClient} class's {@code STATE_*} constants.

    +

    To provide a useful message to your users, you can request a corresponding string +for each state by calling {@code Helpers.getDownloaderStringResourceIDFromState()}. This +returns the resource ID for one of the strings bundled with the Expansion Downloader +Library. For example, the string "Download paused because you are roaming" corresponds to {@code +STATE_PAUSED_ROAMING}.

    +
    {@code onDownloadProgress(DownloadProgressInfo progress)}
    +
    The download service calls this to deliver a {@code DownloadProgressInfo} object, +which describes various information about the download progress, including estimated time remaining, +current speed, overall progress, and total so you can update the download progress UI.
    +
    +

    Tip: For examples of these callbacks that update the download +progress UI, see the {@code SampleDownloaderActivity} in the sample app provided with the Expansion +Downloader package.

    + +

    Some public methods for the {@code IDownloaderService} interface you might find useful are:

    + +
    +
    {@code requestPauseDownload()}
    +
    Pauses the download.
    +
    {@code requestContinueDownload()}
    +
    Resumes a paused download.
    +
    {@code setDownloadFlags(int flags)}
    +
    Sets user preferences for network types on which its OK to download the files. The +current implementation supports one flag, {@code FLAGS_DOWNLOAD_OVER_CELLULAR}, but you can add +others. By default, this flag is not enabled, so the user must be on Wi-Fi to download +expansion files. You might want to provide a user preference to enable downloads over +the cellular network. In which case, you can call: +
    +mRemoteService.setDownloadFlags(IDownloaderService.FLAGS_DOWNLOAD_OVER_CELLULAR);
+
    +
    +
    + + + + +

    Using APKExpansionPolicy

    + +

    If you decide to build your own downloader service instead of using the Android Market +Expansion Downloader Library, you should still use the {@code +APKExpansionPolicy} that's provided in the License Verification Library. The {@code +APKExpansionPolicy} class is nearly identical to {@code ServerManagedPolicy} (available in the +Android Market License Verification Library) but includes additional handling for the APK expansion +file response extras.

    + +

    Note: If you do use the Expansion Downloader Library as discussed in the previous section, the +library performs all interaction with the {@code APKExpansionPolicy} so you don't have to use +this class directly.

    + +

    The class includes methods to help you get the necessary information about the available +expansion files:

    + + + +

    For more information about how to use the {@code APKExpansionPolicy} when you're not +using the Expansion Downloader Library, see the documentation for Adding Licensing to Your App, +which explains how to implement a license policy such as this one.

    + + + + + + + +

    Reading the Expansion File

    + +

    Once your APK expansion files are saved on the device, how you read your files +depends on the type of file you've used. As discussed in the overview, your +expansion files can be any kind of file you +want, but are renamed using a particular file name format and are saved to +{@code <shared-storage>/Android/obb/<package-name>/}.

    + +

    Regardless of how you read your files, you should always first check that the external +storage is available for reading. There's a chance that the user has the storage mounted to a +computer over USB or has actually removed the SD card.

    + +

    Note: When your application starts, you should always check whether +the external storage space is available and readable by calling {@link +android.os.Environment#getExternalStorageState()}. This returns one of several possible strings +that represent the state of the external storage. In order for it to be readable by your +application, the return value must be {@link android.os.Environment#MEDIA_MOUNTED}.

    + + +

    Getting the file names

    + +

    As described in the overview, your APK expansion files are saved +using a specific file name format:

    + +
    +[main|patch].<expansion-version>.<package-name>.obb
+
    + +

    To get the location and names of your expansion files, you should use the +{@link android.os.Environment#getExternalStorageDirectory()} and {@link +android.content.Context#getPackageName()} methods to construct the path to your files.

    + +

    Here's a method you can use in your application to get an array containing the complete path +to both your expansion files:

    + +
    +// The shared path to all app expansion files
+private final static String EXP_PATH = "/Android/obb/";
+
+static String[] getAPKExpansionFiles(Context ctx, int mainVersion, int patchVersion) {
+    String packageName = ctx.getPackageName();
+    Vector<String> ret = new Vector<String>();
+    if (Environment.getExternalStorageState().equals(Environment.MEDIA_MOUNTED)) {
+        // Build the full path to the app's expansion files
+        File root = Environment.getExternalStorageDirectory();
+        File expPath = new File(root.toString() + EXP_PATH + packageName);
+
+        // Check that expansion file path exists
+        if (expPath.exists()) {
+            if ( mainVersion > 0 ) {
+                String strMainPath = expPath + File.separator + "main." +
+                        mainVersion + "." + packageName + ".obb";
+                File main = new File(strMainPath);
+                if ( main.isFile() ) {
+                        ret.add(strMainPath);
+                }
+            }
+            if ( patchVersion > 0 ) {
+                String strPatchPath = expPath + File.separator + "patch." +
+                        mainVersion + "." + packageName + ".obb";
+                File main = new File(strPatchPath);
+                if ( main.isFile() ) {
+                        ret.add(strPatchPath);
+                }
+            }
+        }
+    }
+    String[] retArray = new String[ret.size()];
+    ret.toArray(retArray);
+    return retArray;
+}
+
    + +

    You can call this method by passing it your application {@link android.content.Context} +and the desired expansion file's version.

    + +

    There are many ways you could determine the expansion file version number. One simple way is to +save the version in a {@link android.content.SharedPreferences} file when the download begins, by +querying the expansion file name with the {@code APKExpansionPolicy} class's {@code +getExpansionFileName(int index)} method. You can then get the version code by reading the {@link +android.content.SharedPreferences} file when you want to access the expansion +file.

    + +

    For more information about reading from the shared storage, see the Data Storage +documentation.

    + + + +

    Using the APK Expansion Zip Library

    + +
    +
    +

    Reading media files from a ZIP

    +

    If you're using your expansion files to store media files, a ZIP file still allows you to +use Android media playback calls that provide offset and length controls (such as {@link +android.media.MediaPlayer#setDataSource(FileDescriptor,long,long) MediaPlayer.setDataSource()} and +{@link android.media.SoundPool#load(FileDescriptor,long,long,int) SoundPool.load()}). In order for +this to work, you must not perform additional compression on the media files when creating the ZIP +packages. For example, when using the zip tool, you should use the -n +option to specify the file suffixes that should not be compressed:

    +

    zip -n .mp4;.ogg main_expansion media_files

    +
    +
    + +

    The Android Market Expansion Downloader package includes a library called the APK +Expansion Zip Library. This is an optional library that helps you read your expansion +files when they're saved as ZIP files. Using this library allows you to easily read resources from +your ZIP expansion files as a virtual file system.

    + +

    The APK Expansion Zip Library includes the following classes and APIs:

    + +
    +
    {@code APKExpansionSupport}
    +
    Provides some methods to access expansion file names and ZIP files: + +
    +
    {@code getAPKExpansionFiles()}
    +
    The same method shown above that returns the complete file path to both expansion +files.
    +
    {@code getAPKExpansionZipFile(Context ctx, int mainVersion, int +patchVersion)}
    +
    Returns a {@code ZipResourceFile} representing the sum of both the main file and +patch file. That is, if you specify both the mainVersion and the +patchVersion, this returns a {@code ZipResourceFile} that provides read access to +all the data, with the patch file's data merged on top of the main file.
    +
    +
    + +
    {@code ZipResourceFile}
    +
    Represents a ZIP file on the shared storage and performs all the work to provide a virtual +file system based on your ZIP files. You can get an instance using {@code +APKExpansionSupport.getAPKExpansionZipFile()} or with the {@code ZipResourceFile} by passing it the +path to your expansion file. This class includes a variety of useful methods, but you generally +don't need to access most of them. A couple of important methods are: + +
    +
    {@code getInputStream(String assetPath)}
    +
    Provides an {@link java.io.InputStream} to read a file within the ZIP file. The +assetPath must be the path to the desired file, relative to +the root of the ZIP file contents.
    +
    {@code getAssetFileDescriptor(String assetPath)}
    +
    Provides an {@link android.content.res.AssetFileDescriptor} for a file within the +ZIP file. The assetPath must be the path to the desired file, relative to +the root of the ZIP file contents. This is useful for certain Android APIs that require an {@link +android.content.res.AssetFileDescriptor}, such as some {@link android.media.MediaPlayer} APIs.
    +
    +
    + +
    {@code APEZProvider}
    +
    Most applications don't need to use this class. This class defines a {@link +android.content.ContentProvider} that marshals the data from the ZIP files through a content +provider {@link android.net.Uri} in order to provide file access for certain Android APIs that +expect {@link android.net.Uri} access to media files. +

    The sample application available in the +Expansion Downloader package demonstrates a scenario in which this class is useful +to specify a video with {@link android.widget.VideoView#setVideoURI +VideoView.setVideoURI()}. See the sample app's class {@code SampleZipfileProvider} for an +example of how to extend this class to use in your application.

    +
    + +

    Reading from a ZIP file

    + +

    When using the APK Expansion Zip Library, reading a file from your ZIP usually requires the +following:

    + +
    +// Get a ZipResourceFile representing a merger of both the main and patch files
+ZipResourceFile expansionFile = APKExpansionSupport.getAPKExpansionZipFile(appContext,
+        mainVersion, patchVersion);
+        
+// Get an input stream for a known file inside the expansion file ZIPs
+InputStream fileStream = expansionFile.getInputStream(pathToFileInsideZip);
+
    + +

    The above code provides access to any file that exists in either your main expansion file or +patch expansion file, by reading from a merged map of all the files from both files. All you +need to provide the {@code getAPKExpansionFile()} method is your application {@code +android.content.Context} and the version number for both the main expansion file and patch +expansion file.

    + +

    If you'd rather read from a specific expansion file, you can use the {@code +ZipResourceFile} constructor with the path to the desired expansion file:

    + +
    +// Get a ZipResourceFile representing a specific expansion file
+ZipResourceFile expansionFile = new ZipResourceFile(filePathToMyZip);
+
+// Get an input stream for a known file inside the expansion file ZIPs
+InputStream fileStream = expansionFile.getInputStream(pathToFileInsideZip);
+
    + + + + + +

    Testing Your Expansion Files

    + +

    Before publishing your application, there are two things you should test: Reading the +expansion files and downloading the files.

    + + +

    Testing file reads

    + +

    Before you upload your application to Android Market, you +should test your application's ability to read the files from the shared storage. All you need to do +is add the files to the appropriate location on the device shared storage and launch your +application:

    + +
      +
    1. On your device, create the appropriate directory on the shared storage where Android +Market will save your files. +

      For example, if your package name is {@code com.example.android}, you need to create +the directory {@code Android/obb/com.example.android/} on the shared storage space. (Plug in +your test device to your computer to mount the shared storage and manually create this +directory.)

      +
      2. +
    2. Manually add the expansion files to that directory. Be sure that you rename your files to +match the file name format that Android Market will use. +

      For example, regardless of the file type, the main expansion file for the {@code +com.example.android} application should be {@code main.0300110.com.example.android.obb}. +The version code can be whatever value you want. Just remember:

      +
        +
      • The main expansion file always starts with {@code main} and the patch file starts with +{@code patch}.
        • +
      • The package name always matches that of the APK to which the file is attached on +Android Market. +
      +
      3. +
    3. Now that the expansion file(s) are on the device, you can install and run your application to +test your expansion file(s).
      4. +
    + +

    Here are some reminders about handling the expansion files:

    + + + + +

    Testing file downloads

    + +

    Because your application must sometimes manually download the expansion files when it first +opens, it's important that you test this process to be sure your application can successfully query +for the URLs, download the files, and save them to the device.

    + +

    To test your application's implementation of the manual download procedure, you must upload +your application to Android Market as a "draft" to make your expansion files available for +download:

    + +
      +
    1. Upload your APK and corresponding expansion files using the Android Market Developer +Console.
      2. +
    2. Fill in the necessary application details (title, screenshots, etc.). You can come back and +finalize these details before publishing your application. +

      Click the Save button. Do not click Publish. This saves +the application as a draft, such that your application is not published for Android Market users, +but the expansion files are available for you to test the download process.

      3. +
    3. Install the application on your test device using the Eclipse tools or {@code adb}.
      4. +
    4. Launch the app.
      5. +
    + +

    If everything works as expected, your application should begin downloading the expansion +files as soon as the main activity starts.

    + + + + +

    Updating Your Application

    + +

    One of the great benefits to using expansion files on Android Market is the ability to +update your application without re-downloading all of the original assets. Because Android Market +allows you to provide two expansion files with each APK, you can use the second file as a "patch" +that provides updates and new assets. Doing so avoids the +need to re-download the main expansion file which could be large and expensive for users.

    + +

    The patch expansion file is technically the same as the main expansion file and neither +the Android system nor Android Market perform actual patching between your main and patch expansion +files. Your application code must perform any necessary patches itself.

    + +

    If you use ZIP files as your expansion files, the APK Expansion Zip +Library that's included with the Expansion Downloader package includes the ability to merge your +patch file with the main expansion file.

    + +

    Note: Even if you only need to make changes to the patch +expansion file, you must still update the APK in order for Android Market to perform an update. +If you don't require code changes in the application, you should simply update the {@code versionCode} in the +manifest.

    + +

    As long as you don't change the main expansion file that's associated with the APK +in the Android Market Developer Console, users who previously installed your application will not +download the main expansion file. Existing users receive only the updated APK and the new patch +expansion file (retaining the previous main expansion file).

    + +

    Here are a few issues to keep in mind regarding updates to expansion files:

    + + + + + + + diff --git a/docs/html/guide/market/licensing/adding-licensing.jd b/docs/html/guide/market/licensing/adding-licensing.jd new file mode 100644 index 0000000000000..d1fe8395db293 --- /dev/null +++ b/docs/html/guide/market/licensing/adding-licensing.jd @@ -0,0 +1,1072 @@ +page.title=Adding Licensing to Your App +parent.title=Application Licensing +parent.link=index.html +@jd:body + + + +
    + +
    + + + +

    After you've set up a publisher account and development environment (see Setting Up for Licensing), you are ready to add license verification to +your app with the License Verification Library (LVL).

    + +

    Adding license verification with the LVL involves these tasks:

    + +
      +
    1. Adding the licensing permission your application's manifest.
      2. +
    2. Implementing a Policy — you can choose one of the full implementations provided in the LVL or create your own.
      3. +
    3. Implementing an Obfuscator, if your {@code Policy} will cache any +license response data.
      4. +
    4. Adding code to check the license in your application's main +Activity.
      5. +
    5. Implementing a DeviceLimiter (optional and not recommended for +most applications).
      6. +
    + +

    The sections below describe these tasks. When you are done with the +integration, you should be able to compile your application successfully and you +can begin testing, as described in Setting Up the Test +Environment.

    + +

    For an overview of the full set of source files included in the LVL, see Summary of LVL Classes +and Interfaces.

    + + +

    Adding the Licensing Permission

    + +

    To use the Android Market application for sending a license check to the +server, your application must request the proper permission, +com.android.vending.CHECK_LICENSE. If your application does +not declare the licensing permission but attempts to initiate a license check, +the LVL throws a security exception.

    + +

    To request the licensing permission in your application, declare a <uses-permission> +element as a child of <manifest>, as follows:

    + +

    <uses-permission +android:name="com.android.vending.CHECK_LICENSE">

    + +

    For example, here's how the LVL sample application declares the permission: +

    + +
    <?xml version="1.0" encoding="utf-8"?>
+
+<manifest xmlns:android="http://schemas.android.com/apk/res/android" ...">
+    <!-- Devices >= 3 have version of Android Market that supports licensing. -->
+    <uses-sdk android:minSdkVersion="3" />
+    <!-- Required permission to check licensing. -->
+    <uses-permission android:name="com.android.vending.CHECK_LICENSE" />
+    ...
+</manifest>
+
    + +

    Note: Currently, you cannot declare the +CHECK_LICENSE permission in the LVL library project's manifest, +because the SDK Tools will not merge it into the manifests of dependent +applications. Instead, you must declare the permission in each dependent +application's manifest.

    + + +

    Implementing a Policy

    + +
    +
    +

    ServerManagedPolicy

    + +

    The LVL includes a complete {@code Policy} implementation called ServerManagedPolicy +that makes use of license-management settings provided by the Android Market +server.

    + +

    Use of ServerManagedPolicy as the basis for your +Policy is strongly recommended. For more information, see ServerManagedPolicy section, below.

    + +
    +
    + +

    Android Market licensing service does not itself determine whether a +given user with a given license should be granted access to your application. +Rather, that responsibility is left to a {@code Policy} implementation that you provide +in your application.

    + +

    Policy is an interface declared by the LVL that is designed to hold your +application's logic for allowing or disallowing user access, based on the result +of a license check. To use the LVL, your application must provide an +implementation of {@code Policy}.

    + +

    The {@code Policy} interface declares two methods, allowAccess() and +processServerResponse(), which are called by a {@code LicenseChecker} +instance when processing a response from the license server. It also declares an +enum called LicenseResponse, which specifies the license response +value passed in calls to processServerResponse().

    + + + +

    To simplify the process of adding licensing to your application and to +provide an illustration of how a {@code Policy} should be designed, the LVL includes +two full {@code Policy} implementations that you can use without modification or +adapt to your needs:

    + + + +

    For most applications, the use of ServerManagedPolicy is highly +recommended. ServerManagedPolicy is the LVL default and is integrated with +the LVL sample application.

    + + +

    Guidelines for custom policies

    + +

    In your licensing implementation, you can use one of the complete policies +provided in the LVL (ServerManagedPolicy or StrictPolicy) or you can create a +custom policy. For any type of custom policy, there are several important design +points to understand and account for in your implementation.

    + +

    The licensing server applies general request limits to guard against overuse +of resources that could result in denial of service. When an application exceeds +the request limit, the licensing server returns a 503 response, which gets +passed through to your application as a general server error. This means that no +license response will be available to the user until the limit is reset, which +can affect the user for an indefinite period.

    + +

    If you are designing a custom policy, we recommend that the {@code Policy}: +

      + +
    1. Caches (and properly obfuscates) the most recent successful license response +in local persistent storage.
      2. +
    2. Returns the cached response for all license checks, for as long as the +cached response is valid, rather than making a request to the licensing server. +Setting the response validity according to the server-provided VT +extra is highly recommended. See Server Response Extras +for more information.
      3. +
    3. Uses an exponential backoff period, if retrying any requests the result in +errors. Note that the Android Market client automatically retries failed +requests, so in most cases there is no need for your {@code Policy} to retry them.
      4. +
    4. Provides for a "grace period" that allows the user to access your +application for a limited time or number of uses, while a license check is being +retried. The grace period benefits the user by allowing access until the next +license check can be completed successfully and it benefits you by placing a +hard limit on access to your application when there is no valid license response +available.
      5. +
    + +

    Designing your {@code Policy} according to the guidelines listed above is critical, +because it ensures the best possible experience for users while giving you +effective control over your application even in error conditions.

    + +

    Note that any {@code Policy} can use settings provided by the licensing server to +help manage validity and caching, retry grace period, and more. Extracting the +server-provided settings is straightforward and making use of them is highly +recommended. See the ServerManagedPolicy implementation for an example of how to +extract and use the extras. For a list of server settings and information about +how to use them, see Server Response +Extras.

    + +

    ServerManagedPolicy

    + +
    +
    +

    Server Response Extras

    + +

    For certain types of licensing responses, the licensing server appends extra +settings to the responses, to help the application manage licensing effectively. +

    + +

    See Server Response Extras +for +a list of settings and ServerManagedPolicy.java for information +about how a {@code Policy} can use the extras.

    + +
    +
    + +

    The LVL includes a full and recommended implementation of the {@code Policy} +interface called ServerManagedPolicy. The implementation is integrated with the +LVL classes and serves as the default {@code Policy} in the library.

    + +

    ServerManagedPolicy provides all of the handling for license and retry +responses. It caches all of the response data locally in a +{@link android.content.SharedPreferences} file, obfuscating it with the +application's {@code Obfuscator} implementation. This ensures that the license response +data is secure and persists across device power cycles. ServerManagedPolicy +provides concrete implementations of the interface methods +processServerResponse() and allowAccess() and also +includes a set of supporting methods and types for managing license +responses.

    + +

    Importantly, a key feature of ServerMangedPolicy is its use of +server-provided settings as the basis for managing licensing across an +application's refund period and through varying network and error conditions. +When an application contacts the Android Market server for a license check, the +server appends several settings as key-value pairs in the extras field of certain +license response types. For example, the server provides recommended values for the +application's license validity period, retry grace period, and maximum allowable +retry count, among others. ServerManagedPolicy extracts the values from the +license response in its processServerResponse() method and checks +them in its allowAccess() method. For a list of the server-provided +settings used by ServerManagedPolicy, see Server Response +Extras.

    + +

    For convenience, best performance, and the benefit of using license settings +from the Android Market server, using ServerManagedPolicy as your +licensing {@code Policy} is strongly recommended.

    + +

    If you are concerned about the security of license response data that is +stored locally in {@link android.content.SharedPreferences}, you can use a stronger obfuscation +algorithm or design a stricter {@code Policy} that does not store license data. The LVL +includes an example of such a {@code Policy} — see StrictPolicy for more information.

    + +

    To use ServerManagedPolicy, simply import it to your Activity, create an +instance, and pass a reference to the instance when constructing your +{@code LicenseChecker}. See Instantiate LicenseChecker and +LicenseCheckerCallback for more information.

    + +

    StrictPolicy

    + +

    The LVL includes an alternative full implementation of the {@code Policy} interface +called StrictPolicy. The StrictPolicy implementation provides a more restrictive +Policy than ServerManagedPolicy, in that it does not allow the user to access +the application unless a license response is received from the server at the +time of access that indicates that the user is licensed.

    + +

    The principal feature of StrictPolicy is that it does not store any +license response data locally, in a persistent store. Because no data is stored, +retry requests are not tracked and cached responses can not be used to fulfill +license checks. The {@code Policy} allows access only if:

    + + + +

    Using StrictPolicy is appropriate if your primary concern is to ensure that, +in all possible cases, no user will be allowed to access the application unless +the user is confirmed to be licensed at the time of use. Additionally, the +Policy offers slightly more security than ServerManagedPolicy — since +there is no data cached locally, there is no way a malicious user could tamper +with the cached data and obtain access to the application.

    + +

    At the same time, this {@code Policy} presents a challenge for normal users, since it +means that they won't be able to access the application when there is no network +(cell or Wi-Fi) connection available. Another side-effect is that your +application will send more license check requests to the server, since using a +cached response is not possible.

    + +

    Overall, this policy represents a tradeoff of some degree of user convenience +for absolute security and control over access. Consider the tradeoff carefully +before using this {@code Policy}.

    + +

    To use StrictPolicy, simply import it to your Activity, create an instance, +and pass a reference to it when constructing your {@code LicenseChecker}. See +Instantiate LicenseChecker and LicenseCheckerCallback +for more information.

    + +

    Implementing an Obfuscator

    + +
    +
    +

    AESObfuscator

    + +

    The LVL includes a full {@code Obfuscator} implementation in the +AESObfuscator.java file. The {@code Obfuscator} uses AES encryption to +obfuscate/unobfuscate data. If you are using a {@code Policy} (such as +ServerManagedPolicy) that caches license response data, using AESObfuscator as +basis for your {@code Obfuscator} implementation is highly recommended.

    + +
    +
    + +

    A typical {@code Policy} implementation needs to save the license response data for +an application to a persistent store, so that it is accessible across +application invocations and device power cycles. For example, a {@code Policy} would +maintain the timestamp of the last successful license check, the retry count, +the license validity period, and similar information in a persistent store, +rather than resetting the values each time the application is launched. The +default {@code Policy} included in the LVL, ServerManagedPolicy, stores license response +data in a {@link android.content.SharedPreferences} instance, to ensure that the +data is persistent.

    + +

    Because the {@code Policy} will use stored license response data to determine whether +to allow or disallow access to the application, it must ensure that any +stored data is secure and cannot be reused or manipulated by a root user on a +device. Specifically, the {@code Policy} must always obfuscate the data before storing +it, using a key that is unique for the application and device. Obfuscating using +a key that is both application-specific and device-specific is critical, because +it prevents the obfuscated data from being shared among applications and +devices.

    + +

    The LVL assists the application with storing its license response data in a +secure, persistent manner. First, it provides an {@code Obfuscator} +interface that lets your application supply the obfuscation algorithm of its +choice for stored data. Building on that, the LVL provides the helper class +PreferenceObfuscator, which handles most of the work of calling the +application's {@code Obfuscator} class and reading and writing the obfuscated data in a +{@link android.content.SharedPreferences} instance.

    + +

    The LVL provides a full {@code Obfuscator} implementation called +AESObfuscator that uses AES encryption to obfuscate data. You can +use AESObfuscator in your application without modification or you +can adapt it to your needs. For more information, see the next section.

    + + +

    AESObfuscator

    + +

    The LVL includes a full and recommended implementation of the {@code Obfuscator} +interface called AESObfuscator. The implementation is integrated with the +LVL sample application and serves as the default {@code Obfuscator} in the library.

    + +

    AESObfuscator provides secure obfuscation of data by using AES to +encrypt and decrypt the data as it is written to or read from storage. +The {@code Obfuscator} seeds the encryption using three data fields provided +by the application:

    + +
      +
    1. A salt — an array of random bytes to use for each (un)obfuscation.
      2. +
    2. An application identifier string, typically the package name of the application.
      3. +
    3. A device identifier string, derived from as many device-specific sources +as possible, so as to make it as unique.
      4. +
    + +

    To use AESObfuscator, first import it to your Activity. Declare a private +static final array to hold the salt bytes and initialize it to 20 randomly +generated bytes.

    + +
        ...
+    // Generate 20 random bytes, and put them here.
+    private static final byte[] SALT = new byte[] {
+     -46, 65, 30, -128, -103, -57, 74, -64, 51, 88, -95,
+     -45, 77, -117, -36, -113, -11, 32, -64, 89
+     };
+    ...
+
    + +

    Next, declare a variable to hold a device identifier and generate a value for +it in any way needed. For example, the sample application included in the LVL +queries the system settings for the +android.Settings.Secure.ANDROID_ID, which is unique to each device. +

    + +

    Note that, depending on the APIs you use, your application might need to +request additional permissions in order to acquire device-specific information. +For example, to query the {@link android.telephony.TelephonyManager} to obtain +the device IMEI or related data, the application will also need to request the +android.permission.READ_PHONE_STATE permission in its manifest.

    + +

    Before requesting new permissions for the sole purpose of acquiring +device-specific information for use in your {@code Obfuscator}, consider +how doing so might affect your application or its filtering on Android Market +(since some permissions can cause the SDK build tools to add +the associated <uses-feature>).

    + +

    Finally, construct an instance of AESObfuscator, passing the salt, +application identifier, and device identifier. You can construct the instance +directly, while constructing your {@code Policy} and {@code LicenseChecker}. For example:

    + +
        ...
+    // Construct the LicenseChecker with a Policy.
+    mChecker = new LicenseChecker(
+        this, new ServerManagedPolicy(this,
+            new AESObfuscator(SALT, getPackageName(), deviceId)),
+        BASE64_PUBLIC_KEY  // Your public licensing key.
+        );
+    ...
+
    + +

    For a complete example, see MainActivity in the LVL sample application.

    + + +

    Checking the License from an Activity

    + +

    Once you've implemented a {@code Policy} for managing access to your application, the +next step is to add a license check to your application, which initiates a query +to the licensing server if needed and manages access to the application based on +the license response. All of the work of adding the license check and handling +the response takes place in your main {@link android.app.Activity} source file. +

    + +

    To add the license check and handle the response, you must:

    + +
      +
    1. Add imports
      2. +
    2. Implement LicenseCheckerCallback as a private inner class
      3. +
    3. Create a Handler for posting from LicenseCheckerCallback to the UI thread
      4. +
    4. Instantiate LicenseChecker and LicenseCheckerCallback
      5. +
    5. Call checkAccess() to initiate the license check
      6. +
    6. Embed your public key for licensing
      7. +
    7. Call your LicenseChecker's onDestroy() method to close IPC connections.
      8. +
    + +

    The sections below describe these tasks.

    + +

    Overview of license check and response

    + +
    +
    +

    Example: MainActivity

    + +

    The sample application included with the LVL provides a full example of how +to initiate a license check and handle the result, in the +MainActivity.java file.

    + +
    +
    + +

    In most cases, you should add the license check to your application's main +{@link android.app.Activity}, in the {@link android.app.Activity#onCreate onCreate()} method. This +ensures that when the user launches your application directly, the license check +will be invoked immediately. In some cases, you can add license checks in other +locations as well. For example, if your application includes multiple Activity +components that other applications can start by {@link android.content.Intent}, +you could add license checks in those Activities.

    + +

    A license check consists of two main actions:

    + + + +
    + + +
    Figure 6. Overview of a +typical license check interaction.
    +
    + +

    The diagram above illustrates how a typical license check takes place:

    + +
      +
    1. Code in the application's main Activity instantiates {@code LicenseCheckerCallback} +and {@code LicenseChecker} objects. When constructing {@code LicenseChecker}, the code passes in +{@link android.content.Context}, a {@code Policy} implementation to use, and the +publisher account's public key for licensing as parameters.
      2. +
    2. The code then calls the checkAccess() method on the +{@code LicenseChecker} object. The method implementation calls the {@code Policy} to determine +whether there is a valid license response cached locally, in +{@link android.content.SharedPreferences}. +
        +
      • If so, the checkAccess() implementation calls + allow().
        • +
      • Otherwise, the {@code LicenseChecker} initiates a license check request that is sent + to the licensing server.
        • +
      + +

      Note: The licensing server always returns +LICENSED when you perform a license check of a draft application.

      +
      3. +
    3. When a response is received, {@code LicenseChecker} creates a LicenseValidator that +verifies the signed license data and extracts the fields of the response, then +passes them to your {@code Policy} for further evaluation. +
        +
      • If the license is valid, the {@code Policy} caches the response in +{@link android.content.SharedPreferences} and notifies the validator, which then calls the +allow() method on the {@code LicenseCheckerCallback} object.
        • +
      • If the license not valid, the {@code Policy} notifies the validator, which calls +the dontAllow() method on {@code LicenseCheckerCallback}.
        • +
      +
      4. +
    4. In case of a recoverable local or server error, such as when the network is +not available to send the request, {@code LicenseChecker} passes a {@code RETRY} response to +your {@code Policy} object's processServerResponse() method. +

      Also, both the {@code allow()} and {@code dontAllow()} callback methods receive a +reason argument. The {@code allow()} method's reason is usually {@code +Policy.LICENSED} or {@code Policy.RETRY} and the {@code dontAllow()} reason is usually {@code +Policy.NOT_LICENSED} or {@code Policy.RETRY}. These response values are useful so you can show +an appropriate response for the user, such as by providing a "Retry" button when {@code +dontAllow()} responds with {@code Policy.RETRY}, which might have been because the service was +unavailable.

      5. +
    5. In case of a application error, such as when the application attempts to +check the license of an invalid package name, {@code LicenseChecker} passes an error +response to the LicenseCheckerCallback's applicationError() +method.
      6. +
    + +

    Note that, in addition to initiating the license check and handling the +result, which are described in the sections below, your application also needs +to provide a Policy implementation and, if the {@code Policy} +stores response data (such as ServerManagedPolicy), an Obfuscator implementation.

    + + +

    Add imports

    + +

    First, open the class file of the application's main Activity and import +{@code LicenseChecker} and {@code LicenseCheckerCallback} from the LVL package.

    + +
        import com.android.vending.licensing.LicenseChecker;
+    import com.android.vending.licensing.LicenseCheckerCallback;
    + +

    If you are using the default {@code Policy} implementation provided with the LVL, +ServerManagedPolicy, import it also, together with the AESObfuscator. If you are +using a custom {@code Policy} or {@code Obfuscator}, import those instead.

    + +
        import com.android.vending.licensing.ServerManagedPolicy;
+    import com.android.vending.licensing.AESObfuscator;
    + +

    Implement LicenseCheckerCallback as a private inner class

    + +

    {@code LicenseCheckerCallback} is an interface provided by the LVL for handling +result of a license check. To support licensing using the LVL, you must +implement {@code LicenseCheckerCallback} and +its methods to allow or disallow access to the application.

    + +

    The result of a license check is always a call to one of the +{@code LicenseCheckerCallback} methods, made based on the validation of the response +payload, the server response code itself, and any additional processing provided +by your {@code Policy}. Your application can implement the methods in any way needed. In +general, it's best to keep the methods simple, limiting them to managing UI +state and application access. If you want to add further processing of license +responses, such as by contacting a backend server or applying custom constraints, +you should consider incorporating that code into your {@code Policy}, rather than +putting it in the {@code LicenseCheckerCallback} methods.

    + +

    In most cases, you should declare your implementation of +{@code LicenseCheckerCallback} as a private class inside your application's main +Activity class.

    + +

    Implement the allow() and dontAllow() methods as +needed. To start with, you can use simple result-handling behaviors in the +methods, such as displaying the license result in a dialog. This helps you get +your application running sooner and can assist with debugging. Later, after you +have determined the exact behaviors you want, you can add more complex handling. +

    + +

    Some suggestions for handling unlicensed responses in +dontAllow() include:

    + + + +

    The example below shows how the LVL sample application implements +{@code LicenseCheckerCallback}, with methods that display the license check result in a +dialog.

    + +
    +private class MyLicenseCheckerCallback implements LicenseCheckerCallback {
+    public void allow(int reason) {
+        if (isFinishing()) {
+            // Don't update UI if Activity is finishing.
+            return;
+        }
+        // Should allow user access.
+        displayResult(getString(R.string.allow));
+    }
+
+    public void dontAllow(int reason) {
+        if (isFinishing()) {
+            // Don't update UI if Activity is finishing.
+            return;
+        }
+        displayResult(getString(R.string.dont_allow));
+        
+        if (reason == Policy.RETRY) {
+            // If the reason received from the policy is RETRY, it was probably
+            // due to a loss of connection with the service, so we should give the
+            // user a chance to retry. So show a dialog to retry.
+            showDialog(DIALOG_RETRY);
+        } else {
+            // Otherwise, the user is not licensed to use this app.
+            // Your response should always inform the user that the application
+            // is not licensed, but your behavior at that point can vary. You might
+            // provide the user a limited access version of your app or you can
+            // take them to Android Market to purchase the app.
+            showDialog(DIALOG_GOTOMARKET);
+        }
+    }
+}
+
    + +

    Additionally, you should implement the applicationError() +method, which the LVL calls to let your application handle errors that are not +retryable. For a list of such errors, see Server +Response Codes in the Licensing Reference. You can implement +the method in any way needed. In most cases, the +method should log the error code and call dontAllow().

    + +

    Create a Handler for posting from LicenseCheckerCallback +to the UI thread

    + +

    During a license check, the LVL passes the request to the Android Market +application, which handles communication with the licensing server. The LVL +passes the request over asynchronous IPC (using {@link android.os.Binder}) so +the actual processing and network communication do not take place on a thread +managed by your application. Similarly, when the Android Market application +receives the result, it invokes a callback method over IPC, which in turn +executes in an IPC thread pool in your application's process.

    + +

    The {@code LicenseChecker} class manages your application's IPC communication with +the Android Market application, including the call that sends the request and +the callback that receives the response. {@code LicenseChecker} also tracks open license +requests and manages their timeouts.

    + +

    So that it can handle timeouts properly and also process incoming responses +without affecting your application's UI thread, {@code LicenseChecker} spawns a +background thread at instantiation. In the thread it does all processing of +license check results, whether the result is a response received from the server +or a timeout error. At the conclusion of processing, the LVL calls your +{@code LicenseCheckerCallback} methods from the background thread.

    + +

    To your application, this means that:

    + +
      +
    1. Your {@code LicenseCheckerCallback} methods will be invoked, in many cases, from a +background thread.
      2. +
    2. Those methods won't be able to update state or invoke any processing in the +UI thread, unless you create a Handler in the UI thread and have your callback +methods post to the Handler.
      3. +
    + +

    If you want your {@code LicenseCheckerCallback} methods to update the UI thread, +instantiate a {@link android.os.Handler} in the main Activity's +{@link android.app.Activity#onCreate(android.os.Bundle) onCreate()} method, +as shown below. In this example, the LVL sample application's +{@code LicenseCheckerCallback} methods (see above) call displayResult() to +update the UI thread through the Handler's +{@link android.os.Handler#post(java.lang.Runnable) post()} method.

    + +
    private Handler mHandler;
+
+    @Override
+    public void onCreate(Bundle savedInstanceState) {
+        ...
+        mHandler = new Handler();
+    }
+
    + +

    Then, in your {@code LicenseCheckerCallback} methods, you can use Handler methods to +post Runnable or Message objects to the Handler. Here's how the sample +application included in the LVL posts a Runnable to a Handler in the UI thread +to display the license status.

    + +
        private void displayResult(final String result) {
+        mHandler.post(new Runnable() {
+            public void run() {
+                mStatusText.setText(result);
+                setProgressBarIndeterminateVisibility(false);
+                mCheckLicenseButton.setEnabled(true);
+            }
+        });
+    }
+
    + +

    Instantiate LicenseChecker and LicenseCheckerCallback

    + +

    In the main Activity's +{@link android.app.Activity#onCreate(android.os.Bundle) onCreate()} method, +create private instances of LicenseCheckerCallback and {@code LicenseChecker}. You must +instantiate {@code LicenseCheckerCallback} first, because you need to pass a reference +to that instance when you call the constructor for {@code LicenseChecker}.

    + +

    When you instantiate {@code LicenseChecker}, you need to pass in these parameters:

    + + + +

    If you are using ServerManagedPolicy, you won't need to access the class +directly, so you can instantiate it in the {@code LicenseChecker} constructor, +as shown in the example below. Note that you need to pass a reference to a new +Obfuscator instance when you construct ServerManagedPolicy.

    + +

    The example below shows the instantiation of {@code LicenseChecker} and +{@code LicenseCheckerCallback} from the onCreate() method of an Activity +class.

    + +
    public class MainActivity extends Activity {
+    ...
+    private LicenseCheckerCallback mLicenseCheckerCallback;
+    private LicenseChecker mChecker;
+
+    @Override
+    public void onCreate(Bundle savedInstanceState) {
+        super.onCreate(savedInstanceState);
+        ...
+        // Construct the LicenseCheckerCallback. The library calls this when done.
+        mLicenseCheckerCallback = new MyLicenseCheckerCallback();
+
+        // Construct the LicenseChecker with a Policy.
+        mChecker = new LicenseChecker(
+            this, new ServerManagedPolicy(this,
+                new AESObfuscator(SALT, getPackageName(), deviceId)),
+            BASE64_PUBLIC_KEY  // Your public licensing key.
+            );
+        ...
+    }
+}
+
    + + +

    Note that {@code LicenseChecker} calls the {@code LicenseCheckerCallback} methods from the UI +thread only if there is valid license response cached locally. If the +license check is sent to the server, the callbacks always originate from the +background thread, even for network errors.

    + + +

    Call checkAccess() to initiate the license check

    + +

    In your main Activity, add a call to the checkAccess() method of the +{@code LicenseChecker} instance. In the call, pass a reference to your +{@code LicenseCheckerCallback} instance as a parameter. If you need to handle any +special UI effects or state management before the call, you might find it useful +to call checkAccess() from a wrapper method. For example, the LVL +sample application calls checkAccess() from a +doCheck() wrapper method:

    + +
        @Override
+    public void onCreate(Bundle savedInstanceState) {
+        super.onCreate(savedInstanceState);
+        ...
+        // Call a wrapper method that initiates the license check
+        doCheck();
+        ...
+    }
+    ...
+    private void doCheck() {
+        mCheckLicenseButton.setEnabled(false);
+        setProgressBarIndeterminateVisibility(true);
+        mStatusText.setText(R.string.checking_license);
+        mChecker.checkAccess(mLicenseCheckerCallback);
+    }
+
    + + +

    Embed your public key for licensing

    + +

    For each publisher account, the Android Market service automatically +generates a 2048-bit RSA public/private key pair that is used exclusively for +licensing. The key pair is uniquely associated with the publisher account and is +shared across all applications that are published through the account. Although +associated with a publisher account, the key pair is not the same as +the key that you use to sign your applications (or derived from it).

    + +

    The Android Market publisher site exposes the public key for licensing to any +developer signed in to the publisher account, but it keeps the private key +hidden from all users in a secure location. When an application requests a +license check for an application published in your account, the licensing server +signs the license response using the private key of your account's key pair. +When the LVL receives the response, it uses the public key provided by the +application to verify the signature of the license response.

    + +

    To add licensing to an application, you must obtain your publisher account's +public key for licensing and copy it into your application. Here's how to find +your account's public key for licensing:

    + +
      +
    1. Go to the Android Market publisher site and sign in. +Make sure that you sign in to the account from which the application you are +licensing is published (or will be published).
      2. +
    2. In the account home page, locate the "Edit profile" link and click it.
      3. +
    3. In the Edit Profile page, locate the "Licensing" pane, shown below. Your +public key for licensing is given in the "Public key" text box.
      4. +
    + +

    To add the public key to your application, simply copy/paste the key string +from the text box into your application as the value of the String variable +BASE64_PUBLIC_KEY. When you are copying, make sure that you have +selected the entire key string, without omitting any characters.

    + +

    Here's an example from the LVL sample application:

    + +
        public class MainActivity extends Activity {
+        private static final String BASE64_PUBLIC_KEY = "MIIBIjANBgkqhkiG ... "; //truncated for this example
+    ...
+    }
+
    + +

    Call your LicenseChecker's onDestroy() method +to close IPC connections

    + +

    Finally, to let the LVL clean up before your application +{@link android.content.Context} changes, add a call to the {@code LicenseChecker}'s +onDestroy() method from your Activity's +{@link android.app.Activity#onDestroy()} implementation. The call causes the +{@code LicenseChecker} to properly close any open IPC connection to the Android Market +application's ILicensingService and removes any local references to the service +and handler.

    + +

    Failing to call the {@code LicenseChecker}'s onDestroy() method +can lead to problems over the lifecycle of your application. For example, if the +user changes screen orientation while a license check is active, the application +{@link android.content.Context} is destroyed. If your application does not +properly close the {@code LicenseChecker}'s IPC connection, your application will crash +when the response is received. Similarly, if the user exits your application +while a license check is in progress, your application will crash when the +response is received, unless it has properly called the +{@code LicenseChecker}'s onDestroy() method to disconnect from the service. +

    + +

    Here's an example from the sample application included in the LVL, where +mChecker is the {@code LicenseChecker} instance:

    + +
        @Override
+    protected void onDestroy() {
+        super.onDestroy();
+        mChecker.onDestroy();
+        ...
+    }
+
    + +

    If you are extending or modifying {@code LicenseChecker}, you might also need to call +the {@code LicenseChecker}'s finishCheck() method, to clean up any open IPC +connections.

    + +

    Implementing a DeviceLimiter

    + +

    In some cases, you might want your {@code Policy} to limit the number of actual +devices that are permitted to use a single license. This would prevent a user +from moving a licensed application onto a number of devices and using the +application on those devices under the same account ID. It would also prevent a +user from "sharing" the application by providing the account information +associated with the license to other individuals, who could then sign in to that +account on their devices and access the license to the application.

    + +

    The LVL supports per-device licensing by providing a +DeviceLimiter interface, which declares a single method, +allowDeviceAccess(). When a LicenseValidator is handling a response +from the licensing server, it calls allowDeviceAccess(), passing a +user ID string extracted from the response.

    + +

    If you do not want to support device limitation, no work is +required — the {@code LicenseChecker} class automatically uses a default +implementation called NullDeviceLimiter. As the name suggests, NullDeviceLimiter +is a "no-op" class whose allowDeviceAccess() method simply returns +a LICENSED response for all users and devices.

    + +
    +

    Caution: Per-device licensing is not recommended for +most applications because:

    + +
    + + + + + + + + + + + +

    Obfuscating Your Code

    + +

    To ensure the security of your application, particularly for a paid +application that uses licensing and/or custom constraints and protections, it's +very important to obfuscate your application code. Properly obfuscating your +code makes it more difficult for a malicious user to decompile the application's +bytecode, modify it — such as by removing the license check — +and then recompile it.

    + +

    Several obfuscator programs are available for Android applications, including +ProGuard, which also offers +code-optimization features. The use of ProGuard or a similar program to obfuscate +your code is strongly recommended for all applications that use Android +Market Licensing.

    + +

    Publishing a Licensed Application

    + +

    When you are finished testing your license implementation, you are ready to +publish the application on Android Market. Follow the normal steps to prepare, sign, and then publish the application. +

    + +

    Removing Copy Protection

    + +

    After uploading your licensed application, remember to remove copy protection +from the application, if it is currently used. To check and remove copy +protection, sign in to the publisher site and go the application's upload +details page. In the Publishing options section, make sure that the Copy +Protection radio button selection is "Off".

    + + +

    Where to Get Support

    + +

    If you have questions or encounter problems while implementing or deploying +publishing in your applications, please use the support resources listed in the +table below. By directing your queries to the correct forum, you can get the +support you need more quickly.

    + +

    Table 2. Developer support resources +for Android Market Licensing Service.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Support TypeResourceRange of Topics
    Development and testing issuesGoogle Groups: android-developers +LVL download and integration, library projects, {@code Policy} +questions, user experience ideas, handling of responses, {@code Obfuscator}, IPC, test +environment setup
    Stack Overflow: http://stackoverflow.com/questions/tagged/android
    Accounts, publishing, and deployment issuesAndroid +Market Help ForumPublisher accounts, licensing key pair, test accounts, server +responses, test responses, application deployment and results
    Market +Licensing Support FAQ
    LVL issue trackerMarketlicensing +project issue trackerBug and issue reports related specifically to the LVL source code classes +and interface implementations
    + +

    For general information about how to post to the groups listed above, see Developer Forums document +in the Resources tab.

    + + diff --git a/docs/html/guide/market/licensing/index.jd b/docs/html/guide/market/licensing/index.jd new file mode 100644 index 0000000000000..f08176d57101c --- /dev/null +++ b/docs/html/guide/market/licensing/index.jd @@ -0,0 +1,61 @@ +page.title=Application Licensing +@jd:body + + +

    Android Market offers a licensing service that lets you enforce licensing policies for +applications that you publish on Android Market. With Android Market Licensing, your application can +query Android Market at run time to obtain the licensing status for the current user, then allow or +disallow further use as appropriate.

    + +

    Using the service, you can apply a flexible licensing policy on an application-by-application +basis—each application can enforce licensing in the way most appropriate for it. If necessary, +an application can apply custom constraints based on the licensing status obtained from Android +Market. For example, an application can check the licensing status and then apply custom constraints +that allow the user to run it unlicensed for a specific validity period. An application can also +restrict use of the application to a specific device, in addition to any other constraints.

    + +

    The licensing service is a secure means of controlling access to your applications. When an +application checks the licensing status, the Android Market server signs the licensing status +response using a key pair that is uniquely associated with the publisher account. Your application +stores the public key in its compiled .apk file and uses it to verify the licensing +status response.

    + +

    Any application that you publish through Android Market can use the Android Market Licensing +service. No special account or registration is needed. Additionally, because the service uses no +dedicated framework APIs, you can add licensing to any application that uses a minimum API level of +3 or higher.

    + +

    Note: The Android Market Licensing service is primarily intended +for paid applications that wish to verify that the current user did in fact pay for the application +on Android Market. However, any application (including free apps) may use the licensing service +to initiate the download of an APK expansion file. In which case, the request that your application +sends to the licensing service is not to check whether the user paid for the app, but to request the +URL of the expansion files. For information about downloading expansion files for your application, +read the guide to APK Expansion Files.

    + + +

    To learn more about Android Market's application licensing service and start integrating it into +your applications, read the following documents:

    + +
    +
    Licensing +Overview
    +
    Describes how the service works and what a typical licensing implementation looks +like.
    +
    Setting Up for +Licensing
    +
    Explains how to set up your Android Market account, development environment, and +testing environment in order to add licensing to your app.
    +
    Adding +Licensing to Your App
    +
    Provides a step-by-step guide to add licensing verification to your application.
    +
    Licensing +Reference
    +
    Provides detailed information about the licensing library's classes and the service response +codes.
    +
    + + + + + diff --git a/docs/html/guide/market/licensing/licensing-reference.jd b/docs/html/guide/market/licensing/licensing-reference.jd new file mode 100644 index 0000000000000..ac5d59618b221 --- /dev/null +++ b/docs/html/guide/market/licensing/licensing-reference.jd @@ -0,0 +1,439 @@ +page.title=Licensing Reference +parent.title=Application Licensing +parent.link=index.html +@jd:body + + + +
    + +
    + + +

    LVL Classes and Interfaces

    + +

    Table 1 lists all of the source files in the License Verification +Library (LVL) available through the Android SDK. All of the files are part of +the com.android.vending.licensing package.

    + +

    Table 1. Summary of LVL library +classes and interfaces.

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    CategoryNameDescription
    License check and resultLicenseCheckerClass that you instantiate (or subclass) to initiate a license check.
    LicenseCheckerCallbackInterface that you implement to handle result of the license check.
    PolicyPolicyInterface that you implement to determine whether to allow +access to the application, based on the license response.
    ServerManagedPolicyDefault {@code Policy} implementation. Uses settings provided by the +licensing server to manage local storage of license data, license validity, +retry.
    StrictPolicyAlternative {@code Policy} implementation. Enforces licensing based on a direct +license response from the server only. No caching or request retry.
    Data obfuscation
    (optional)    		ObfuscatorInterface that you implement if you are using a {@code Policy} (such as +ServerManagedPolicy) that caches license response data in a persistent store. +Applies an obfuscation algorithm to encode and decode data being written or +read.
    AESObfuscatorDefault Obfuscator implementation that uses AES encryption/decryption +algorithm to obfuscate/unobfuscate data.
    Device limitation
    (optional)    		DeviceLimiterInterface that you implement if you want to restrict use of an +application to a specific device. Called from LicenseValidator. Implementing +DeviceLimiter is not recommended for most applications because it requires a +backend server and may cause the user to lose access to licensed applications, +unless designed with care.
    NullDeviceLimiterDefault DeviceLimiter implementation that is a no-op (allows access to all +devices).
    Library core, no integration neededResponseDataClass that holds the fields of a license response.
    LicenseValidatorClass that decrypts and verifies a response received from the licensing +server.
    ValidationExceptionClass that indicates errors that occur when validating the integrity of data +managed by an Obfuscator.
    PreferenceObfuscatorUtility class that writes/reads obfuscated data to the system's +{@link android.content.SharedPreferences} store.
    ILicensingServiceOne-way IPC interface over which a license check request is passed to the +Android Market client.
    ILicenseResultListenerOne-way IPC callback implementation over which the application receives an +asynchronous response from the licensing server.
    +
    + + +

    Server Response Codes

    + +

    Table 2 lists all of the license response codes supported by the +licensing server. In general, an application should handle all of these response +codes. By default, the LicenseValidator class in the LVL provides all of the +necessary handling of these response codes for you.

    + +

    Table 2. Summary of response codes +returned by the Android Market server in a license response.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Response CodeDescriptionSigned?ExtrasComments
    {@code LICENSED}The application is licensed to the user. The user has purchased the +application or the application only exists as a draft.YesVT, GT, GRAllow access according to {@code Policy} constraints.
    {@code LICENSED_OLD_KEY}The application is licensed to the user, but there is an updated application +version available that is signed with a different key. Yes VT, GT, GR, UTOptionally allow access according to {@code Policy} constraints. +

    Can indicate that the key pair used by the installed +application version is invalid or compromised. The application can allow access +if needed or inform the user that an upgrade is available and limit further use +until upgrade.

    +
    {@code NOT_LICENSED}The application is not licensed to the user.NoDo not allow access.
    {@code ERROR_CONTACTING_SERVER}Local error — the Android Market application was not able to reach the +licensing server, possibly because of network availability problems. NoRetry the license check according to {@code Policy} retry limits.
    {@code ERROR_SERVER_FAILURE}Server error — the server could not load the publisher account's key +pair for licensing.NoRetry the license check according to {@code Policy} retry limits. +
    {@code ERROR_INVALID_PACKAGE_NAME}Local error — the application requested a license check for a package +that is not installed on the device. No Do not retry the license check. +

    Typically caused by a development error.

    +
    {@code ERROR_NON_MATCHING_UID}Local error — the application requested a license check for a package +whose UID (package, user ID pair) does not match that of the requesting +application. No Do not retry the license check. +

    Typically caused by a development error.

    +
    {@code ERROR_NOT_MARKET_MANAGED}Server error — the application (package name) was not recognized by +Android Market. NoDo not retry the license check. +

    Can indicate that the application was not published +through Android Market or that there is an development error in the licensing +implementation.

    +
    + +

    Note: As documented in +Setting Up The Testing Environment, the response code can be manually +overridden for the application developer and any registered test users via the +Android Market publisher site. +

    +Additionally, as noted above, applications that are in draft mode (in other +words, applications that have been uploaded but have never been +published) will return {@code LICENSED} for all users, even if not listed as a test +user. Since the application has never been offered for download, it is assumed +that any users running it must have obtained it from an authorized channel for +testing purposes.

    + + + + +

    Server Response Extras

    + +

    To assist your application in managing access to the application across the application refund +period and provide other information, The licensing server includes several pieces of +information in the license responses. Specifically, the service provides recommended values for the +application's license validity period, retry grace period, maximum allowable retry count, and other +settings. If your application uses APK +expansion files, the response also includes the file names, sizes, and URLs. The server appends +the settings as key-value pairs in the license response "extras" field.

    + +

    Any {@code Policy} implementation can extract the extras settings from the license +response and use them as needed. The LVL default {@code Policy} implementation, {@code +ServerManagedPolicy}, serves as a working +implementation and an illustration of how to obtain, store, and use the +settings.

    + +

    Table 3. Summary of +license-management settings supplied by the Android Market server in a license +response.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ExtraDescription
    {@code VT}License validity timestamp. Specifies the date/time at which the current +(cached) license response expires and must be rechecked on the licensing server. See the section +below about License validity period. +
    {@code GT}Grace period timestamp. Specifies the end of the period during which a +Policy may allow access to the application, even though the response status is +{@code RETRY}.

    The value is managed by the server, however a typical value would be 5 +or more days. See the section +below about Retry period and maximum retry count.

    {@code GR}Maximum retries count. Specifies how many consecutive {@code RETRY} license checks +the {@code Policy} should allow, before denying the user access to the application. +

    The value is managed by the server, however a typical value would be "10" or +higher. See the section +below about Retry period and maximum retry count.

    {@code UT}Update timestamp. Specifies the day/time when the most recent update to +this application was uploaded and published.

    The server returns this extra +only for {@code LICENSED_OLD_KEYS} responses, to allow the {@code Policy} to determine how much +time has elapsed since an update was published with new licensing keys before +denying the user access to the application.

    {@code FILE_URL1} or {@code FILE_URL2}The URL for an expansion file (1 is for the main file, 2 is the patch file). Use this to +download the file over HTTP.
    {@code FILE_NAME1} or {@code FILE_NAME2}The expansion file's name (1 is for the main file, 2 is the patch file). You must use this +name when saving the file on the device.
    {@code FILE_SIZE1} or {@code FILE_SIZE2}The size of the file in bytes (1 is for the main file, 2 is the patch file). Use this to +assist with downloading and to ensure that enough space is available on the device's shared +storage location before downloading.
    + + + +

    License validity period

    + +

    The Android Market licensing server sets a license validity period for all +downloaded applications. The period expresses the interval of time over which an +application's license status should be considered as unchanging and cacheable by +a licensing {@code Policy} in the application. The licensing server includes the +validity period in its response to all license checks, appending an +end-of-validity timestamp to the response as an extra under the key {@code VT}. A +{@code Policy} can extract the VT key value and use it to conditionally allow access to +the application without rechecking the license, until the validity period +expires.

    + +

    The license validity signals to a licensing {@code Policy} when it must recheck the +licensing status with the licensing server. It is not intended to imply +whether an application is actually licensed for use. That is, when an +application's license validity period expires, this does not mean that the +application is no longer licensed for use — rather, it indicates only that +the {@code Policy} must recheck the licensing status with the server. It follows that, +as long as the license validity period has not expired, it is acceptable for the +{@code Policy} to cache the initial license status locally and return the cached license +status instead of sending a new license check to the server.

    + +

    The licensing server manages the validity period as a means of helping the +application properly enforce licensing across the refund period offered by +Android Market for paid applications. It sets the validity period based on +whether the application was purchased and, if so, how long ago. Specifically, +the server sets a validity period as follows:

    + + + +

    The {@code ServerManagedPolicy} implementation uses the extracted timestamp +(mValidityTimestamp) as a primary condition for determining whether +to recheck the license status with the server before allowing the user access to +the application.

    + + +

    Retry period and maximum retry count

    + +

    In some cases, system or network conditions can prevent an application's +license check from reaching the licensing server, or prevent the server's +response from reaching the Android Market client application. For example, the +user might launch an application when there is no cell network or data +connection available—such as when on an airplane—or when the +network connection is unstable or the cell signal is weak.

    + +

    When network problems prevent or interrupt a license check, the Android +Market client notifies the application by returning a {@code RETRY} response code to +the {@code Policy}'s processServerResponse() method. In the case of system +problems, such as when the application is unable to bind with Android Market's +{@code ILicensingService} implementation, the {@code LicenseChecker} library itself calls the +Policy processServerResonse() method with a {@code RETRY} response code. +

    + +

    In general, the {@code RETRY} response code is a signal to the application that an +error has occurred that has prevented a license check from completing. + +

    The Android Market server helps an application to manage licensing under +error conditions by setting a retry "grace period" and a recommended maximum +retries count. The server includes these values in all license check responses, +appending them as extras under the keys {@code GT} and {@code GR}.

    + +

    The application {@code Policy} can extract the {@code GT} and {@code GR} extras and use them to +conditionally allow access to the application, as follows:

    + + + +

    The {@code ServerManagedPolicy} uses the server-supplied {@code GT} and {@code GR} values as +described above. The example below shows the conditional handling of the retry +responses in the allow() method. The count of {@code RETRY} responses is +maintained in the processServerResponse() method, not shown.

    + + +
        
+public boolean allowAccess() {
+    long ts = System.currentTimeMillis();
+    if (mLastResponse == LicenseResponse.LICENSED) {
+        // Check if the LICENSED response occurred within the validity timeout.
+        if (ts <= mValidityTimestamp) {
+            // Cached LICENSED response is still valid.
+            return true;
+        }
+    } else if (mLastResponse == LicenseResponse.RETRY &&
+                ts < mLastResponseTime + MILLIS_PER_MINUTE) {
+        // Only allow access if we are within the retry period or we haven't used up our
+        // max retries.
+        return (ts <= mRetryUntil || mRetryCount <= mMaxRetries);
+    }
+    return false;
+}
    + diff --git a/docs/html/guide/market/licensing/overview.jd b/docs/html/guide/market/licensing/overview.jd new file mode 100644 index 0000000000000..3576e26653faf --- /dev/null +++ b/docs/html/guide/market/licensing/overview.jd @@ -0,0 +1,245 @@ +page.title=Licensing Overview +parent.title=Application Licensing +parent.link=index.html +@jd:body + + +
    +
    + +

    Quickview

    +
      +
    • Licensing allows you to verify your app was purchased from Android Market
      • +
    • Your app maintains control of how it enforces its licensing status
      • +
    • The service is free for all developers who publish on Android Market
      • +
    + +

    In this document

    +
      +
    1. License Responses are Secure
      2. +
    2. Licensing Verification Library
      3. +
    3. Requirements and Limitations
      4. +
    4. Replacement for Copy Protection
      5. +
    + +
    +
    + + +

    Android Market Licensing is a network-based service that lets an application query a trusted +Android Market licensing server to determine whether the application is licensed to the current +device user. The licensing service is based on the capability of the Android Market licensing server +to determine whether a given user is licensed to use a given application. Android Market considers a +user to be licensed if the user is a recorded purchaser of the application.

    + +

    The request starts when your application makes a request to a service hosted by +the Android Market client application. The Android Market application then sends a request to +the licensing server and receives the result. The Android Market application sends +the result to your application, which can allow or disallow further use of the +application as needed.

    + +

    Note: If a paid application has been uploaded to Android Market but +saved only as a draft application (the app is unpublished), the licensing server considers all users +to be licensed users of the application (because it's not even possible to purchase the app). +This exception is necessary in order for you to perform testing of your licensing +implementation.

    + + +
    + +

    Figure 1. Your application initiates a +license check through the License Verification Library and the Android Market +client, which handles communication with the Market server.

    +
    + + +

    To properly identify the user and determine the license status, the licensing server requires +information about the application and user—your application and the Android Market client work +together to assemble the information and the Android Market client passes it to the server.

    + +

    To help you add licensing to your application, the Android SDK provides a downloadable set of +library sources that you can include in your application project: the "Google Market Billing +package." The License Verification Library (LVL) is a library you can add to your application that +handles all of the licensing-related communication with the Android Market licensing service. With +the LVL added to your application, your application can determine its licensing status for the +current user by simply calling a method and implementing a callback that receives the status +response.

    + +

    Your application does not query the licensing server +directly, but instead calls the Android Market client over remote IPC to +initiate a license request. In the license request:

    + + + +

    You can choose when, and how often, you want your application to check its +license and you have full control over how it handles the response, verifies the +signed response data, and enforces access controls.

    + +

    Notice that during a license check, your application does not manage any +network connections or use any licensing related APIs in the Android platform.

    + + + + +

    License Responses are Secure

    + +

    To ensure the integrity of each license query, the server signs the license +response data using an RSA key pair that is shared exclusively between the Android Market +server and you.

    + +

    The licensing service generates a single licensing key pair for each +publisher account and exposes the public key in your account's profile page. You must copy the +public key from the web site and embed it in your application source code. The server retains the +private key internally and uses it to sign license responses for the applications you +publish with that account.

    + +

    When your application receives a signed response, it uses the embedded public +key to verify the data. The use of public key cryptography in the licensing +service makes it possible for the application to detect responses that have been +tampered with or that are spoofed.

    + + + + +

    Licensing Verification Library

    + +

    The Android SDK provides a downloadable component called the "Google Market Licensing package," +which includes the License Verification Library (LVL). The LVL greatly simplifies the process of +adding licensing to your application and helps ensure a more secure, robust implementation for your +application. The LVL provides internal classes that handle most of the standard operations of a +license query, such as contacting the Android Market client to initiate a license request and +verifying and validating the responses. It also exposes interfaces that let you easily plug in your +custom code for defining licensing policy and managing access as needed by your application. The key +LVL interfaces are:

    + +
    +
    {@code Policy}
    +
    Your implementation determines whether to allow access to the +application, based on the license response received from the server and any +other data available (such as from a backend server associated with your +application). The implementation can evaluate the various fields of the license +response and apply other constraints, if needed. The implementation also lets +you manage the handling of license checks that result in errors, such as network +errors.
    + +
    {@code LicenseCheckerCallback}
    +
    Your implementation manages access to the +application, based on the result of the {@code Policy} object's handling of the license +response. Your implementation can manage access in any way needed, including +displaying the license result in the UI or directing the user to purchase the +application (if not currently licensed).
    +
    + + +

    To help you get started with a {@code Policy}, the LVL provides two fully complete +{@code Policy} implementations that you can use without modification or adapt to your +needs:

    + +
    +
    {@code ServerManagedPolicy}
    +
    A flexible {@code Policy} +that uses settings provided by the licensing server to manage response caching +and access to the application while the device is offline (such as when the +user is on an airplane). For most applications, the use of +{@code ServerManagedPolicy} is highly recommended.
    + +
    {@code StrictPolicy}
    +
    A restrictive {@code Policy} that +does not cache any response data and allows the application access only +when the server returns a licensed response.
    +
    + +

    The LVL is available as a downloadable component of the Android SDK. The +component includes both the LVL itself and an example application that shows how +the library should be integrated with your application and how your application +should manage response data, UI interaction, and error conditions.

    + +

    The LVL sources are provided as an Android library project, which +means that you can maintain a single set of library sources and share them +across multiple applications. A full test environment is also available through +the SDK, so you can develop and test the licensing implementation in your +applications before publishing them, even if you don't have access to a +physical device.

    + + + + +

    Requirements and Limitations

    + +

    Android Market Licensing is designed to let you apply license controls to +applications that you publish through Android Market. The service is not +designed to let you control access to applications that are not published +through Android Market or that are run on devices that do not offer the Android +Market client.

    + +

    Here are some points to keep in mind as you implement licensing in your +application:

    + + + + + +

    Replacement for Copy Protection

    + +

    Android Market Licensing is a flexible, secure mechanism for controlling +access to your applications. It effectively replaces the Copy Protection +mechanism offered on Android Market and gives you wider distribution +potential for your applications.

    + + + +

    Although no license mechanism can completely prevent all unauthorized use, +the licensing service lets you control access for most types of normal usage, +across all compatible devices, locked or unlocked, that run Android 1.5 or +higher version of the platform.

    + +

    To begin adding application licensing to your application, continue to Setting Up for Licensing.

    + + + + + + diff --git a/docs/html/guide/market/licensing/setting-up.jd b/docs/html/guide/market/licensing/setting-up.jd new file mode 100644 index 0000000000000..c79f90b6a64dc --- /dev/null +++ b/docs/html/guide/market/licensing/setting-up.jd @@ -0,0 +1,707 @@ +page.title=Setting Up for Licensing +parent.title=Application Licensing +parent.link=index.html +@jd:body + + +
    + +
    + +

    Before you start adding license verification to your application, you need to set up your Android +Market publishing account, your development environment, and test accounts required to verify +your implementation.

    + + +

    Setting Up a Publisher Account

    + +

    If you don't already have a publisher account for Android Market, you need to register for one +using your Google account and agree to the terms of service on the Android Market publisher site:

    + +

    http://market.android.com/publish +

    + +

    For more information, see Publishing on Android Market.

    + +

    If you already have a publisher account on Android Market, use your existing +account to set up licensing.

    + +

    Using your publisher account on Android Market, you can:

    + + + +

    Administrative settings for licensing

    + +

    You can manage several +administrative controls for Android Market licensing on the publisher site. The controls are available +in the Edit Profile page, in the "Licensing" panel, shown in figure 1. The controls +let you:

    + + + + + +

    Figure 1. The Licensing +panel of your account's Edit Profile page lets you manage administrative +settings for licensing.

    + +

    For more information about how to work with test accounts and static test +responses, see Setting Up a Testing Environment, below. + + + +

    Setting Up the Development Environment

    + +

    Setting up your environment for licensing involves these tasks:

    + +
      +
    1. Setting up the runtime environment for development
      2. +
    2. Downloading the LVL into your SDK
      3. +
    3. Setting up the Licensing Verification Library
      4. +
    4. Including the LVL library project in your application
      5. +
    + +

    The sections below describe these tasks. When you are done with setup, +you can begin Adding +Licensing to Your App.

    + +

    To get started, you need to set up a proper runtime environment on which +you can run, debug, and test your application's implementation of license +checking and enforcement.

    + + +

    Setting up the runtime environment

    + +

    As described earlier, applications check licensing status not by contacting +the licensing server directly, but by binding to a service provided by the +Android Market application and initiating a license check request. The Android +Market service then handles the direct communication with the licensing server +and finally routes the response back to your application. To debug and test +licensing in your application, you need to set up a runtime environment that +includes the necessary Android Market service, so that your application is able +to send license check requests to the licensing server.

    + +

    There are two types of runtime environment that you can use:

    + + + +

    Running on a device

    + +

    To use an Android-powered device for +debugging and testing licensing, the device must:

    + + + +

    If Android Market is not preinstalled in the system image, your application won't +be able to communicate with the Android Market licensing server.

    + +

    For general information about how to set up a device for use in developing +Android applications, see Using Hardware Devices.

    + +

    Running on an Android emulator

    + +

    If you don't have a device available, you can use an Android emulator for debugging and testing +licensing.

    + +

    Because the Android platforms provided in the Android SDK do +not include Android Market, you need to download the Google APIs Add-On +platform, API level 8 (or higher), from the SDK repository. After downloading +the add-on, you need to create an AVD configuration that uses that system image. +

    + +

    The Google APIs Add-On does not include the full Android Market client. +However, it does provide:

    + + + +

    Several versions of the add-on are available through the SDK Manager, but only +Google APIs Add-On, API 8 (release 2) or higher includes the necessary Android +Market services.

    + + + +

    Figure 2. Google APIs +Add-On, API 8 (release 2) or higher lets you debug and test your licensing +implementation in an emulator.

    + +

    To set up an emulator for adding licensing to an application, follow +these steps:

    + +
      +
    1. Launch the Android SDK Manager.
      2. +
    2. In the Available Packages panel, select and download the +SDK component "Google APIs (Google Inc.) - API Level 8" (or higher) from the SDK +repository, as shown in figure 2. +

      When the download is complete, use the Android SDK Manager to +create a new AVD based on that component, described next.

      3. +
    3. In the Virtual +Devices panel of the Android SDK Manager, click +New and set the configuration details for the new AVD.
      4. +
    4. In the dialog that appears, assign a descriptive name to the AVD and then +use the "Target" menu to choose the "Google APIs (Google Inc.) - API Level 8" as +the system image to run on the new AVD. Set the other configuration details as +needed and then click Create AVD to finish. The SDK tools +create the new AVD configuration, which then appears in the list of available +Android Virtual Devices.
      5. +
    + +

    If you are not familiar with AVDs or how to use them, see Managing Virtual Devices.

    + +

    Updating your project configuration

    + +

    After you set up a runtime environment that meets the requirements described +above — either on an actual device or on an emulator — make sure to +update your application project or build scripts as needed, so that your compiled +.apk files that use licensing are deployed into that environment. +In particular, if you are developing in Eclipse, make sure that you set up a +Run/Debug Configuration that targets the appropriate device or AVD.

    + +

    You do not need to make any changes to your application's +build configuration, provided that the project is already configured to compile +against a standard Android 1.5 (API level 3) or higher library. For example: + +

    + +

    In general, adding licensing to an application should have no impact +whatsoever on the application's build configuration.

    + + +

    Downloading the LVL

    + +

    The License Verification Library (LVL) is a collection of helper classes that +greatly simplify the work that you need to do to add licensing to your +application. In all cases, we recommend that you download the LVL and use it as +the basis for the licensing implementation in your application.

    + +

    The LVL is available as a downloadable component of the Android SDK. The +component includes:

    + + + +

    To download the LVL component into your development environment, use the +Android SDK Manager. Launch the Android SDK Manager and then +select the "Market Licensing" component, as shown in figure 3. +Accept the terms and click Install Selected to begin the download.

    + + +

    Figure 3. The Market Licensing package contains the LVL and +the LVL sample application.

    + +

    When the download is complete, the Android SDK Manager installs both +the LVL library project and the example application into these directories:

    + +

    <sdk>/extras/google/market_licensing/library/ +  (the LVL library project)
    +<sdk>/extras/google/market_licensing/sample/  (the example +application)

    + +

    If you aren't familiar with how to download components into your SDK, see the +Adding SDK Components +document.

    + + +

    Setting Up the Licensing Verification Library

    + +

    After downloading the LVL to your computer, you need to set it up in your +development environment, either as an Android library project or by +copying (or importing) the library sources directly into your existing +application package. In general, using the LVL as a library project is recommended, +since it lets you reuse your licensing code across multiple applications and +maintain it more easily over time. Note that the LVL is not designed to be +compiled separately and added to an application as a static .jar file.

    + +

    Moving the library sources to a new location

    + +

    Because you will be customizing the LVL sources to some extent, you should +make sure to move or copy the library sources (the entire +directory at <sdk>/market_licensing/library/) +to a working directory outside of the SDK. You should then use the relocated +sources as your working set. If you are using a source-code management +system, add and track the sources that are in the working location rather +than those in default location in the SDK.

    + +

    Moving the library sources is important is because, when you later update the +Market licensing package, the SDK installs the new files to the same location as +the older files. Moving your working library files to a safe location ensures +that your work won't be inadvertently overwritten should you download a new +version of the LVL.

    + +

    Creating the LVL as a library project

    + +
    +
    +

    Working with library projects

    + +

    The LVL is provided as an Android library project, which means that you can +share its code and resources across multiple applications.

    + +

    If you aren't familiar with library projects or how +to use them, see +Managing Projects. +

    +
    +
    + +

    The recommended way of using the LVL is setting it up as a new Android +library project. A library project is a type of development project +that holds shared Android source code and resources. Other Android application +projects can reference the library project and, at build time, include its +compiled sources in their .apk files. In the context of licensing, +this means that you can do most of your licensing development once, in a library +project, then include the library sources in your various application projects. +In this way, you can easily maintain a uniform implementation of licensing +across all of your projects and maintain it centrally.

    + +

    The LVL is provided as a configured library project — once you have +downloaded it, you can start using it right away.

    + +

    If you are working in Eclipse with ADT, you need to add the LVL to your +workspace as a new development project, in the same way as you would a new +application project.

    + +
      +
    1. Use the New Project Wizard to create a new +project from existing sources. Select the LVL's library directory +(the directory containing the library's AndroidManifest.xml file) as the project +root.
      2. +
    2. When you are creating the library project, you can select any application +name, package, and set other fields as needed.
      3. +
    3. For the library's build target, select Android 1.5 (API level 3) or higher.
      4. +
    + +

    When created, the project is +predefined as a library project in its project.properties file, so +no further configuration is needed.

    + +

    For more information about how to create an application project or work with +library projects in Eclipse, see Managing Projects from +Eclipse with ADT.

    + + +

    Copying the LVL sources to your application

    + +

    As an alternative to adding the LVL as a library project, you can copy the +library sources directly into your application. To do so, copy (or import) the +LVL's library/src/com directory into your application's +src/ directory.

    + +

    If you add the LVL sources directly to your application, you can skip the +next section and start working with the library, as described in Adding +Licensing to Your App.

    + + +

    Including the LVL library project sources in your +application

    + +

    If you want to use the LVL sources as a library project, you need to add a +reference to the LVL library project in your application project properties. This tells +build tools to include the LVL library project sources in your application at +compile time. The process for adding a reference to a library project depends +on your development environment, as described below.

    + +

    If you are developing in Eclipse with ADT, you should already have added the +library project to your workspace, as described in the previous section. If you +haven't done that already, do it now before continuing.

    + +

    Next, open the application's project properties window, as shown below. +Select the "Android" properties group and click Add, then +choose the LVL library project (com_android_vending_licensing) and click +OK. For more information, see + +Managing Projects from Eclipse with ADT

    . + + + +

    Figure 4. If you are +working in Eclipse with ADT, you can add the LVL library project to your +application from the application's project properties.

    + + +

    If you are developing using the SDK command-line tools, navigate to the +directory containing your application project and open the +project.properties file. Add a line to the file that specifies the +android.library.reference.<n> key and the path to the +library. For example:

    + +
    android.library.reference.1=path/to/library_project
    + +

    Alternatively, you can use this command to update the project +properties, including the reference to the library project:

    + +
    android update lib-project
+--target <target_ID> \
+--path path/to/my/app_project \
+--library path/to/my/library_project
+
    + +

    For more information about working with library projects, +see +Setting up a Library Project.

    + + + + + + + + + + + + + + + + + + + + + +

    Setting Up the Testing Environment

    + +

    The Android Market publisher site provides configuration tools that let you +and others test licensing on your application before it is published. As you are +implementing licensing, you can make use of the publisher site tools to test +your application's Policy and handling of different licensing responses and +error conditions.

    + +

    The main components of the test environment for licensing include:

    + + + +

    Setting up the test environment properly involves:

    + +
      +
    1. Setting static test responses that are returned by the licensing server.
      2. +
    2. Setting up test accounts as needed.
      3. +
    3. Signing in properly to an emulator or device, before initiating a license check test.
      4. +
    + +

    The sections below provide more information.

    + + +

    Setting test responses for license checks

    + +

    Android Market provides a configuration setting in your publisher account +that lets you override the normal processing of a license check and return a +specified static response code. The setting is for testing only and applies +only to license checks for applications that you have uploaded, made by +any user signed in to an emulator or device using the credentials of the +publisher account or a registered test account. For other users, the server +always processes license checks according to normal rules.

    + +

    To set a test response for your account, sign in to your publisher account +and click "Edit Profile". In the Edit Profile page, locate the Test Response +menu in the Licensing panel, shown below. You can select from the full set of +valid server response codes to control the response or condition you want to +test in your application.

    + +

    In general, you should make sure to test your application's licensing +implementation with every response code available in the Test Response menu. +For a description of the codes, see Server +Response Codes in the Licensing Reference.

    + + +

    Figure 5. The Licensing +panel of your account's Edit Profile page, showing the Test Accounts field and the +Test Response menu.

    + +

    Note that the test response that you configure applies account-wide — +that is, it applies not to a single application, but to all +applications associated with the publisher account. If you are testing multiple +applications at once, changing the test response will affect all of those +applications on their next license check (if the user is signed in to +the emulator or device using the publisher account or a test account).

    + +

    Before you can successfully receive a test response for a license check, +you must sign in to the device or emulator on which the application +is installed, and from which it is querying the server. Specifically, you must +sign using either your publisher account or one of the test accounts that you +have set up. For more information about test accounts, see the next section.

    + +

    See Server +Response Codes for a list of +test responses available and their meanings.

    + + +

    Setting up test accounts

    + +

    In some cases, you might want to let multiple teams of developers test +licensing on applications that will ultimately be published through your +publisher account, but without giving them access to your publisher account's +sign-in credentials. To meet that need, the Android Market publisher site lets +you set up one or more optional test accounts — accounts that are +authorized to query the licensing server and receive static test responses from +your publisher account.

    + +

    Test accounts are standard Google accounts that you register on your +publisher account, such that they will receive the test response for +applications that you have uploaded. Developers can then sign in to their +devices or emulators using the test account credentials and initiate license +checks from installed applications. When the licensing server receives a license +check from a user of a test account, it returns the static test response +configured for the publisher account.

    + +

    Necessarily, there are limitations on the access and permissions given to +users signed in through test accounts, including:

    + + + +

    The table below summarizes the differences in capabilities, between the +publisher account, a test account, and any other account.

    + +

    Table 1. +Differences in account types for testing licensing.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Account TypeCan check license before upload?Can receive test response?Can set test response?
    Publisher accountYesYesYes
    Test accountNoYesNo
    OtherNoNoNo
    + +

    Registering test accounts on the publisher account

    + +

    To get started, you need to register each test account in your publisher +account. As shown in Figure 5, you +register test accounts in the Licensing panel of your publisher account's Edit +Profile page. Simply enter the accounts as a comma-delimited list and click +Save to save your profile changes.

    + +

    You can use any Google account as a test account. If you want to own and +control the test accounts, you can create the accounts yourself and distribute +the credentials to your developers or testers.

    + +

    Handling application upload and distribution for test +account users

    + +

    As mentioned above, users of test accounts can only receive static test +responses for applications that are uploaded to the publisher account. Since +those users do not have permission to upload applications, as the publisher you +will need to work with those users to collect apps for upload and distribute +uploaded apps for testing. You can handle collection and distribution in any way +that is convenient.

    + +

    Once an application is uploaded and becomes known to the licensing server, +developers and testers can continue modify the application in their local +development environment, without having to upload new versions. You only need to +upload a new version if the local application increments the +versionCode attribute in the manifest file.

    + +

    Distributing your public key to test account users

    + +

    The licensing server handles static test responses in the normal way, +including signing the license response data, adding extras parameters, and so +on. To support developers who are implementing licensing using test accounts, +rather than the publisher account, you will need to distribute +your public key to them. Developers without access to the publisher site do not +have access to your public key, and without the key they won't be able to +verify license responses.

    + +

    Note that if you decide to generate a new licensing key pair for your account +for some reason, you need to notify all users of test accounts. For +testers, you can embed the new key in the application package and distribute it +to users. For developers, you will need to distribute the new key to them +directly.

    + + +

    Signing in to an authorized account in the runtime +environment

    + +

    The licensing service is designed to determine whether a given user is +licensed to use a given application — during a license check, the Android +Market application gathers the user ID from the primary account on the system +and sends it to the server, together with the package name of the application +and other information. However, if there is no user information available, the +license check cannot succeed, so the Android Market application terminates the +request and returns an error to the application.

    + +

    During testing, to ensure that your application can successfully query the +licensing server, you must make sure that you sign in to an account on the +device or emulator using:

    + + + + +
    +
    +

    Signing in to a Google account on an emulator

    + +

    If you are testing licensing on an emulator, you need to sign in to a Google +account on the emulator. If you do not see an option to create a new Google +account, the problem might be that your AVD is running a standard Android system +image, rather than the Google APIs Add-On, API 8 (release 2) or higher.

    + +

    For more information, see Setting up the runtime environment, above.

    + +
    +
    + +

    Signing in using a publisher account offers the advantage of letting your +applications receive static test responses even before the applications are +uploaded to the publisher site.

    + +

    If you are part of a larger organization or are working with external groups +on applications that will be published through your site, you will more likely +want to distribute test accounts instead, then use those to sign in during +testing.

    + +

    To sign in on a device or emulator, follow the steps below. The preferred +approach is to sign in as the primary account — however, if there are +other accounts already in use on the device or emulator, you can create an +additional account and sign in to it using the publisher or test account +credentials.

    + +
      +
    1. Open Settings > Accounts & sync
      2. +
    2. Select Add Account and choose to add a "Google" account. +
      3. +
    3. Select Next and then Sign in.
      4. +
    4. Enter the username and password of either the publisher account or a test +account that is registered in the publisher account.
      5. +
    5. Select Sign in. The system signs you in to the new +account.
      6. +
    + +

    Once you are signed in, you can begin testing licensing in your application +(if you have completed the LVL integration steps above). When your application +initiates a license check, it will receive a response containing the static test +response configured on the publisher account.

    + +

    Note that, if you are using an emulator, you will need to sign in to the +publisher account or test account each time you wipe data when restarting the +emulator.

    + +

    Once you've completed the setup procedures, continue to Adding Licensing to Your App.

    + + + diff --git a/docs/html/guide/publishing/licensing.html b/docs/html/guide/publishing/licensing.html new file mode 100644 index 0000000000000..8e97f328da3c3 --- /dev/null +++ b/docs/html/guide/publishing/licensing.html @@ -0,0 +1,11 @@ + + + +Redirecting... + + +

    You should have been redirected. Please click here.

    + + \ No newline at end of file diff --git a/docs/html/guide/publishing/licensing.jd b/docs/html/guide/publishing/licensing.jd deleted file mode 100644 index 609241b7d0a2b..0000000000000 --- a/docs/html/guide/publishing/licensing.jd +++ /dev/null @@ -1,2388 +0,0 @@ -page.title=Application Licensing -@jd:body - -
    -
    - -

    Quickview

    -
      -
    • Licensing lets you protect your application on any device that includes Android Market.
      • -
    • Your app maintains control of how it enforces its licensing status.
      • -
    • Adding licensing to an app is straightforward, using the library available through the SDK.
      • -
    • The service is free and is available to all developers who publish on Android Market.
      • -
    - -

    In this document

    -
      -
    1. Setting Up A Publisher Account
      2. -
    2. Setting Up the Development Environment
      3. -
    3. Integrating the LVL with Your Application -
        -
      1. Including the LVL
        2. -
      2. Adding the licensing permission
        3. -
      3. Implementing a Policy
        4. -
      4. Implementing an Obfuscator
        5. -
      5. Checking the license
        6. -
      6. Implementing a DeviceLimiter
        7. -
      4. -
    4. Setting Up the Test Environment -
        -
      1. Test responses
        2. -
      2. Test accounts
        3. -
      3. Signing in on a device or emulator
        4. -
      5. -
    5. Obfuscating Your Application
      6. -
    6. Publishing a Licensed Application
      7. -
    7. Where to Get Support
      8. -
    - -

    Appendix

    -
      -
    1. Summary of LVL Classes and Interfaces
      2. -
    2. Server Response Codes
      3. -
    3. Server Response Extras
      4. -
    - -
    -
    - -

    Android Market offers a licensing service that lets you enforce licensing -policies for paid applications that you publish through Android Market. With -Android Market Licensing, your applications can query Android Market at run time to -obtain their licensing status for the current user, then allow or disallow -further use as appropriate.

    - -

    Using the service, you can apply a flexible licensing policy on an -application-by-application basis — each application can enforce licensing -in the way most appropriate for it. If necessary, an application can apply custom -constraints based on the licensing status obtained from Android Market. -For example, an application can check the licensing status and then apply custom -constraints that allow the user to run it unlicensed for a specific number -of times, or for a specific validity period. An application can also restrict use of the -application to a specific device, in addition to any other constraints.

    - -

    The licensing service is a secure means of controlling access to your -applications. When an application checks the licensing status, the Market server -signs the licensing status response using a key pair that is uniquely associated -with the publisher account. Your application stores the public key in its -compiled .apk file and uses it to verify the licensing status -response.

    - -

    Any application that you publish through Android Market can use the Android -Market Licensing service. No special account or registration is needed. -Additionally, because the service uses no dedicated framework APIs, you can add -licensing to any legacy application that uses a minimum API level of 3 or -higher.

    - -

    To help you add licensing to your application, the Android SDK provides -library sources that you can include in your application project. The -License Verification Library (LVL) handles all of -the licensing-related communication with the Android Market client and the -licensing service. With the LVL integrated, your application can determine its -licensing status for the current user by simply calling a library checker method -and implementing a callback that receives the status.

    - -

    This document explains how the licensing service works and how to add it to -your application.

    - - -

    Overview

    - -

    Android Market Licensing is a network-based service that lets an application -on an Android-powered device query a trusted licensing server, to determine -whether the application is licensed to the current device user. After receiving -the server response, the application can then allow or disallow further use of -the application as needed. In the service, the role of the licensing server is -to provide the license status for the current user; the application itself is -responsible for querying the server and conditionally granting access to the -application.

    - -

    Application, Android Market client, and server

    - -

    The licensing service is based on the capability of the Android Market server -to determine whether a given user is licensed to use a given application. The licensing server -considers a user to be licensed if the user is a recorded purchaser of an application. If a paid -application has been uploaded to Android Market but saved only as a draft application (in -other words, the app is unpublished), the licensing server considers all users to be licensed users -of the application. Keep in mind, you cannot implement Android Market Licensing in a free -application.

    - -

    To properly identify -the user and determine the license status, the server requires information about -the application and user — the application and the Android Market client -work together to assemble the information and pass it to the server.

    - -

    In the licensing service, an application does not query the licensing server -directly, but instead calls the Android Market client over remote IPC to -initiate a license request. In the license request:

    - - - -

    Notice that during a license check, the application does not manage any -network connections or use any licensing related APIs in the Android platform. -

    - -
    - -

    Figure 1. Your application initiates a -license check through the LVL and the Android Market -client, which handles communication with the Market server.

    -
    - -

    License responses secured through public key cryptography

    - -

    To ensure the integrity of each license query, the server signs the license -response data using an RSA key pair that is shared exclusively between the -server and the application publisher.

    - -

    The licensing service generates a single licensing key pair for each -publisher account and exposes the public key in the account's profile page. The -publisher copies the public key and embeds it in the application source code, -then compiles and publishes the .apk. The server retains the -private key internally and uses it to sign license responses for applications -published on that account.

    - -

    When the application receives a signed response, it uses the embedded public -key to verify the data. The use of public key cryptography in the licensing -service makes it possible for the application to detect responses that have been -tampered with or that are spoofed.

    - -

    Use of licensing in your application

    - -

    To use licensing in your application, add code to the application to -initiate a license check request and handle the response when it is received. -You can choose when, and how often, you want your application to check its -license and you have full control over how it handles the response, verifies the -signed response data, and enforces access controls.

    - -

    To simplify the process of adding support for licensing, download and -integrate the Licensing Verification Library, described below. Integration is -straightforward.

    - -

    When you are finished integrating the LVL, use a test environment -provided by the publisher site to test your application's handling of server -responses.

    - -

    Finally, publish the application .apk on Market using the -normal process. If you previously used the copy-protection provided by Android -Market, you can remove it from applications that use licensing.

    - -

    Licensing Verification Library simplifies implementation

    - -

    The Android SDK includes a License Verification Library (LVL) that you can -download and use as the basis for your application's licensing implementation. -The LVL greatly simplifies the process of adding licensing to your application -and helps ensure a more secure, robust implementation for your application. The -LVL provides internal classes that handle most of the standard operations of a -license query, such as contacting Android Market to initiate a license request -and verifying and validating the responses. It also exposes key interfaces that -let you easily plug in your custom code for defining licensing policy and -managing access as needed by your application. The key LVL interfaces are:

    - - - -

    To help you get started with a Policy, the LVL provides two fully complete -Policy implementations that you can use without modification or adapt to your -needs:

    - - - -

    The LVL is available as a downloadable component of the Android SDK. The -component includes both the LVL itself and an example application that shows how -the library should be integrated with your application and how your application -should manage response data, UI interaction, and error conditions.

    - -

    The LVL sources are provided as an Android library project, which -means that you can maintain a single set of library sources and share them -across multiple applications. A full test environment is also available through -the SDK, so you can develop and test the licensing implementation in your -applications before publishing them, even if you don't have access to a -physical device.

    - -

    Requirements and limitations

    - -

    Android Market Licensing is designed to let you apply license controls to -applications that you publish through Android Market. The service is not -designed to let you control access to applications that are not published -through Android Market or that are run on devices that do not offer the Android -Market client.

    - -

    Here are some points to keep in mind as you implement licensing in your -application:

    - - - -

    Replacement for Copy Protection

    - -

    Android Market Licensing is a flexible, secure mechanism for controlling -access to your applications. It effectively replaces the Copy Protection -mechanism offered on Android Market and gives you wider distribution -potential for your applications.

    - - - -

    Although no license mechanism can completely prevent all unauthorized use, -the licensing service lets you control access for most types of normal usage, -across all compatible devices, locked or unlocked, that run Android 1.5 or -higher version of the platform.

    - -

    The sections below describe how to add Android Market licensing to your -applications.

    - -

    Setting Up a Publisher Account

    - -

    Android Market licensing lets you manage access to applications that -users have downloaded from Android Market. To use licensing in an application, -you need to have a publisher account on Android Market so that you can -publish the application to users.

    - -

    If you don't already have a publisher account, you need to register for one -using your Google account and agree to the terms of service. Once you are -registered, you can upload applications at your convenience and begin debugging -and testing your licensing implementation. For more information about publishing -on Android Market, see Publishing Your -Applications

    - -

    To register as an Android Market developer and set up your publisher account, -visit the Android Market publisher site:

    - -

    http://market.android.com/publish -

    - -

    If you already have a publisher account on Android Market, use your existing -account to set up licensing. You do not need to register for a new -account to support licensing (and doing so is not recommended, especially if you -are adding licensing support to applications that you have already published). -In all cases, if you have published applications, you manage licensing for those -applications through the account on which the applications are published.

    - -

    Once your publisher account is set up, use the account to:

    - - - -

    Administrative settings for licensing

    - -

    Once you are signed into your publisher account, you can manage several -administrative controls for Android Market licensing. The controls are available -in the Edit Profile page, in the "Licensing" panel, shown below. The controls -let you:

    - - - -
    - - -
    Figure 2. The Licensing -panel of your account's Edit Profile page lets you manage administrative -settings for licensing.
    -
    - -

    For more information about how to work with test accounts and static test -responses, see Setting Up a Testing Environment, below. - -

    Setting Up the Development Environment

    - -

    Once you've set up your publisher account on Android Market, the next step is -to set up your development environment for licensing.

    - -

    Setting up your environment for licensing involves these tasks:

    - -
      -
    1. Downloading the latest SDK, if you haven't already done so
      2. -
    2. Setting up the runtime environment for development
      3. -
    3. Downloading the Market Licensing component into your SDK
      4. -
    4. Setting up the Licensing Verification Library
      5. -
    5. Including the LVL library project in your application
      6. -
    - -

    The sections below describe these tasks. When you are done with setup, -you can begin integrating the LVL into your applications.

    - -

    To get started, you need to set up a proper runtime environment on which -you can run, debug and test your application's implementation of license -checking and enforcement.

    - - -

    Downloading the latest SDK

    - -
    -
    -

    Licensing sample application

    - -

    To work with Android Market licensing, you need a functioning Android -application to which you can add licensing support.

    - -

    If you are new to Android -and don't yet have a functioning application, the LVL component includes a sample -application that you can set up as a new application project. The sample provides -a complete, working example of how licensing works. For more information, see Downloading the LVL.

    - -
    -
    - -

    If you haven't done so, you need to download the Android SDK before you can -develop Android applications. The SDK provides the tools that you need to build -and debug Android applications, including applications that use Android Market -licensing. For complete information, including installation instructions, see -the Android SDK.

    - -

    If you have already installed the SDK, make sure to update the -SDK tools and ADT Plugin to the latest versions. You can update the SDK tools -using the Android SDK and AVD Manager and ADT through Help > -Software Updates... in Eclipse.

    - -

    After you've installed the latest SDK and tools, set up your development -environment as described below.

    - - -

    Setting up the runtime environment

    - -

    As described earlier, applications check licensing status not by contacting -the licensing server directly, but by binding to a service provided by the -Android Market application and initiating a license check request. The Android -Market service then handles the direct communication with the licensing server -and finally routes the response back to your application. To debug and test -licensing in your application, you need to set up a runtime environment that -includes the necessary Android Market service, so that your application is able -to send license check requests to the licensing server.

    - -

    There are two types of runtime environment that you can use:

    - - - -

    The sections below provide more information.

    - -

    Running on a device

    - -

    You can use an Android-powered device as the runtime environment for -debugging and testing licensing on your application.

    - -

    The device you use must:

    - - - -

    If Android Market is not preinstalled in the system image, your application won't -be able to communicate with the Android Market licensing server.

    - -

    For general information about how to set up a device for use in developing -Android applications, see Developing on a Device.

    - -

    Running on an Android emulator

    - -

    You can also use an Android emulator as your runtime -environment for debugging and testing licensing.

    - -

    Because the standard Android platforms provided in the Android SDK do -not include Android Market, you need to download the Google APIs Add-On -platform, API Level 8 (or higher), from the SDK repository. After downloading -the add-on, you need to create an AVD configuration that uses that system image. -

    - -

    The Google APIs Add-On does not include the full Android Market client. -However, it does provide:

    - - - -

    Several versions of the add-on are available in the SDK repository, but only -Google APIs Add-On, API 8 (release 2) or higher version of the -add-on includes the necessary Android Market services. This means that you -cannot use Google APIs Add-On API 7 or lower as a runtime environment for -developing licensing on an emulator.

    - -
    - - -
    Figure 3. Google APIs -Add-On, API 8 (release 2) or higher lets you debug and test your licensing -implementation in an emulator.
    -
    - -

    To set up an emulator for adding licensing to an application, follow -these steps:

    - -
      -
    1. Launch the Android SDK and AVD Manager.
      2. -
    2. In the Available Packages panel, select and download the -SDK component "Google APIs (Google Inc.) - API Level 8" (or higher) from the SDK -repository, as shown in the figure above. -

      When the download is complete, use the Android SDK and AVD Manager to -create a new AVD based on that component, described next.

      3. -
    3. In the Virtual -Devices panel of the Android SDK and AVD Manager, click -New and set the configuration details for the new AVD.
      4. -
    4. In the dialog that appears, assign a descriptive name to the AVD and then -use the "Target" menu to choose the "Google APIs (Google Inc.) - API Level 8" as -the system image to run on the new AVD. Set the other configuration details as -needed and then click Create AVD to finish. The SDK tools -create the new AVD configuration, which then appears in the list of available -Android Virtual Devices.
      5. -
    - -

    If you are not familiar with AVDs or how to use them, see Managing Virtual Devices.

    - -

    Updating your project configuration

    - -

    After you set up a runtime environment that meets the requirements described -above — either on an actual device or on an emulator — make sure to -update your application project or build scripts as needed, so that your compiled -.apk files that use licensing are deployed into that environment. -In particular, if you are developing in Eclipse, make sure that you set up a -Run/Debug Configuration that targets the appropriate device or AVD.

    - -

    You do not need to make any changes to your application's -build configuration, provided that the project is already configured to compile -against a standard Android 1.5 (API level 3) or higher library. For example: - -

    - -

    In general, adding licensing to an application should have no impact -whatsoever on the application's build configuration.

    - - -

    Downloading the LVL

    - -

    The License Verification Library (LVL) is a collection of helper classes that -greatly simplify the work that you need to do to add licensing to your -application. In all cases, we recommend that you download the LVL and use it as -the basis for the licensing implementation in your application.

    - -

    The LVL is available as a downloadable component of the Android SDK. The -component includes:

    - - - -

    To download the LVL component into your development environment, use the -Android SDK and AVD Manager. Launch the Android SDK and AVD Manager and then -select the "Market Licensing" component, as shown in the figure below. -Accept the terms and click Install Selected to begin the download.

    - -
    - - -
    Figure 4. The Market -Licensing package contains the LVL and the LVL sample application.
    -
    - -

    When the download is complete, the Android SDK and AVD Manager installs both -the LVL library project and the example application into these directories:

    - -

    <sdk>/extras/google/market_licensing/library/ -  (the LVL library project)
    -<sdk>/extras/google/market_licensing/sample/  (the example -application)

    - -

    If you aren't familiar with how to download components into your SDK, see the -Adding SDK Components -document.

    - - -

    Setting Up the Licensing Verification Library

    - -

    After downloading the LVL to your computer, you need to set it up in your -development environment, either as an Android library project or by -copying (or importing) the library sources directly into your existing -application package. In general, using the LVL as a library project is recommended, -since it lets you reuse your licensing code across multiple applications and -maintain it more easily over time. Note that the LVL is not designed to be -compiled separately and added to an application as a static .jar file.

    - -

    Moving the library sources to a new location

    - -

    Because you will be customizing the LVL sources to some extent, you should -make sure to move or copy the library sources (the entire -directory at <sdk>/market_licensing/library/) -to a working directory outside of the SDK. You should then use the relocated -sources as your working set. If you are using a source-code management -system, add and track the sources that are in the working location rather -than those in default location in the SDK.

    - -

    Moving the library sources is important is because, when you later update the -Market licensing package, the SDK installs the new files to the same location as -the older files. Moving your working library files to a safe location ensures -that your work won't be inadvertently overwritten should you download a new -version of the LVL.

    - -

    Creating the LVL as a library project

    - -
    -
    -

    Working with library projects

    - -

    The LVL is provided as an Android library project, which means that you can -share its code and resources across multiple applications.

    - -

    If you aren't familiar with library projects or how -to use them, see -Managing Projects. -

    -
    -
    - -

    The recommended way of using the LVL is setting it up as a new Android -library project. A library project is a type of development project -that holds shared Android source code and resources. Other Android application -projects can reference the library project and, at build time, include its -compiled sources in their .apk files. In the context of licensing, -this means that you can do most of your licensing development once, in a library -project, then include the library sources in your various application projects. -In this way, you can easily maintain a uniform implementation of licensing -across all of your projects and maintain it centrally.

    - -

    The LVL is provided as a configured library project — once you have -downloaded it, you can start using it right away.

    - -

    If you are working in Eclipse with ADT, you need to add the LVL to your -workspace as a new development project, in the same way as you would a new -application project.

    - -
      -
    1. Use the New Project Wizard to create a new -project from existing sources. Select the LVL's library directory -(the directory containing the library's AndroidManifest.xml file) as the project -root.
      2. -
    2. When you are creating the library project, you can select any application -name, package, and set other fields as needed.
      3. -
    3. For the library's build target, select Android 1.5 (API level 3) or higher.
      4. -
    - -

    When created, the project is -predefined as a library project in its project.properties file, so -no further configuration is needed.

    - -

    For more information about how to create an application project or work with -library projects in Eclipse, see Managing Projects from -Eclipse with ADT

    . - -

    Copying the LVL sources to your application

    - -

    As an alternative to adding the LVL as a library project, you can copy the -library sources directly into your application. To do so, copy (or import) the -LVL's library/src/com directory into your application's -src/ directory.

    - -

    If you add the LVL sources directly to your application, you can skip the -next section and start working with the library, as described in .

    - - -

    Including the LVL library project sources in your -application

    - -

    If you want to use the LVL sources as a library project, you need to add a -reference to the LVL library project in your application project properties. This tells -build tools to include the LVL library project sources in your application at -compile time. The process for adding a reference to a library project depends -on your development environment, as described below.

    - -

    If you are developing in Eclipse with ADT, you should already have added the -library project to your workspace, as described in the previous section. If you -haven't done that already, do it now before continuing.

    - -

    Next, open the application's project properties window, as shown below. -Select the "Android" properties group and click Add, then -choose the LVL library project (com_android_vending_licensing) and click -OK. For more information, see - -Managing Projects from Eclipse with ADT

    . - -
    - - -
    Figure 5. If you are -working in Eclipse with ADT, you can add the LVL library project to your -application from the application's project properties.
    -
    - -

    If you are developing using the SDK command-line tools, navigate to the -directory containing your application project and open the -project.properties file. Add a line to the file that specifies the -android.library.reference.<n> key and the path to the -library. For example:

    - -
    android.library.reference.1=path/to/library_project
    - -

    Alternatively, you can use this command to update the project -properties, including the reference to the library project:

    - -
    android update lib-project
---target <target_ID> \
---path path/to/my/app_project \
---library path/to/my/library_project
-
    - -

    For more information about working with library projects, -see -Managing Projects from the Command Line

    . - - -

    Integrating the LVL with Your Application

    - -

    Once you've followed the steps above to set up a publisher account and -development environment, you are ready to begin integrating the LVL with your -application.

    - -

    Integrating the LVL with your application code involves these tasks:

    - -
      -
    1. Adding the licensing permission your application's manifest.
      2. -
    2. Implementing a Policy — you can choose one of the full implementations provided in the LVL or create your own.
      3. -
    3. Implementing an Obfuscator, if your Policy will cache any license response data.
      4. -
    4. Adding code to check the license in your application's main Activity
      5. -
    5. Implementing a DeviceLimiter (optional and not recommended for most applications)
      6. -
    - -

    The sections below describe these tasks. When you are done with the -integration, you should be able to compile your application successfully and you -can begin testing, as described in Setting Up the Test -Environment.

    - -

    For an overview of the full set of source files included in the LVL, see Summary of LVL Classes and Interfaces.

    - - -

    Adding the licensing permission to your -AndroidManifest.xml

    - -

    To use the Android Market application for sending a license check to the -server, your application must request the proper permission, -com.android.vending.CHECK_LICENSE. If your application does -not declare the licensing permission but attempts to initiate a license check, -the LVL throws a security exception.

    - -

    To request the licensing permission in your application, declare a <uses-permission> -element as a child of <manifest>, as follows:

    - -

    <uses-permission -android:name="com.android.vending.CHECK_LICENSE">

    - -

    For example, here's how the LVL sample application declares the permission: -

    - -
    <?xml version="1.0" encoding="utf-8"?>
-
-<manifest xmlns:android="http://schemas.android.com/apk/res/android" ...">
-    <!-- Devices >= 3 have version of Android Market that supports licensing. -->
-    <uses-sdk android:minSdkVersion="3" />
-    <!-- Required permission to check licensing. -->
-    <uses-permission android:name="com.android.vending.CHECK_LICENSE" />
-    ...
-</manifest>
-
    - -

    Note: Currently, you cannot declare the -CHECK_LICENSE permission in the LVL library project's manifest, -because the SDK Tools will not merge it into the manifests of dependent -applications. Instead, you must declare the permission in each dependent -application's manifest.

    - - -

    Implementing a Policy

    - -
    -
    -

    ServerManagedPolicy

    - -

    The LVL includes a complete Policy implementation called ServerManagedPolicy -that makes use of license-management settings provided by the Android Market -server.

    - -

    Use of ServerManagedPolicy as the basis for your -Policy is strongly recommended. For more information, see ServerManagedPolicy section, below.

    - -
    -
    - -

    Android Market licensing service does not itself determine whether a -given user with a given license should be granted access to your application. -Rather, that responsibility is left to a Policy implementation that you provide -in your application.

    - -

    Policy is an interface declared by the LVL that is designed to hold your -application's logic for allowing or disallowing user access, based on the result -of a license check. To use the LVL, your application must provide an -implementation of Policy.

    - -

    The Policy interface declares two methods, allowAccess() and -processServerResponse(), which are called by a LicenseChecker -instance when processing a response from the license server. It also declares an -enum called LicenseResponse, which specifies the license response -value passed in calls to processServerResponse().

    - - - -

    To simplify the process of adding licensing to your application and to -provide an illustration of how a Policy should be designed, the LVL includes -two full Policy implementations that you can use without modification or -adapt to your needs:

    - - - -

    For most applications, the use of ServerManagedPolicy is highly -recommended. ServerManagedPolicy is the LVL default and is integrated with -the LVL sample application.

    - - -

    Guidelines for custom policies

    - -

    In your licensing implementation, you can use one of the complete policies -provided in the LVL (ServerManagedPolicy or StrictPolicy) or you can create a -custom policy. For any type of custom policy, there are several important design -points to understand and account for in your implementation.

    - -

    The licensing server applies general request limits to guard against overuse -of resources that could result in denial of service. When an application exceeds -the request limit, the licensing server returns a 503 response, which gets -passed through to your application as a general server error. This means that no -license response will be available to the user until the limit is reset, which -can affect the user for an indefinite period.

    - -

    If you are designing a custom policy, we recommend that the Policy: -

      - -
    1. Caches (and properly obfuscates) the most recent successful license response -in local persistent storage.
      2. -
    2. Returns the cached response for all license checks, for as long as the -cached response is valid, rather than making a request to the licensing server. -Setting the response validity according to the server-provided VT -extra is highly recommended. See Server Response Extras -for more information.
      3. -
    3. Uses an exponential backoff period, if retrying any requests the result in -errors. Note that the Android Market client automatically retries failed -requests, so in most cases there is no need for your Policy to retry them.
      4. -
    4. Provides for a "grace period" that allows the user to access your -application for a limited time or number of uses, while a license check is being -retried. The grace period benefits the user by allowing access until the next -license check can be completed successfully and it benefits you by placing a -hard limit on access to your application when there is no valid license response -available.
      5. -
    - -

    Designing your Policy according to the guidelines listed above is critical, -because it ensures the best possible experience for users while giving you -effective control over your application even in error conditions.

    - -

    Note that any Policy can use settings provided by the licensing server to -help manage validity and caching, retry grace period, and more. Extracting the -server-provided settings is straightforward and making use of them is highly -recommended. See the ServerManagedPolicy implementation for an example of how to -extract and use the extras. For a list of server settings and information about -how to use them, see Server Response Extras in the -Appendix of this document.

    - -

    ServerManagedPolicy

    - -
    -
    -

    Server Response Extras

    - -

    For certain types of licensing responses, the licensing server appends extra -settings to the responses, to help the application manage licensing effectively. -

    - -

    See Server Response Extras for -a list of settings and ServerManagedPolicy.java for information -about how a Policy can use the extras.

    - -
    -
    - -

    The LVL includes a full and recommended implementation of the Policy -interface called ServerManagedPolicy. The implementation is integrated with the -LVL classes and serves as the default Policy in the library.

    - -

    ServerManagedPolicy provides all of the handling for license and retry -responses. It caches all of the response data locally in a -{@link android.content.SharedPreferences} file, obfuscating it with the -application's Obfuscator implementation. This ensures that the license response -data is secure and persists across device power cycles. ServerManagedPolicy -provides concrete implementations of the interface methods -processServerResponse() and allowAccess() and also -includes a set of supporting methods and types for managing license -responses.

    - -

    Importantly, a key feature of ServerMangedPolicy is its use of -server-provided settings as the basis for managing licensing across an -application's refund period and through varying network and error conditions. -When an application contacts the Android Market server for a license check, the -server appends several settings as key-value pairs in the extras field of certain -license response types. For example, the server provides recommended values for the -application's license validity period, retry grace period, and maximum allowable -retry count, among others. ServerManagedPolicy extracts the values from the -license response in its processServerResponse() method and checks -them in its allowAccess() method. For a list of the server-provided -settings used by ServerManagedPolicy, see Server Response -Extras in the Appendix of this document.

    - -

    For convenience, best performance, and the benefit of using license settings -from the Android Market server, using ServerManagedPolicy as your -licensing Policy is strongly recommended.

    - -

    If you are concerned about the security of license response data that is -stored locally in SharedPreferences, you can use a stronger obfuscation -algorithm or design a stricter Policy that does not store license data. The LVL -includes an example of such a Policy — see StrictPolicy for more information.

    - -

    To use ServerManagedPolicy, simply import it to your Activity, create an -instance, and pass a reference to the instance when constructing your -LicenseChecker. See Instantiate LicenseChecker and -LicenseCheckerCallback for more information.

    - -

    StrictPolicy

    - -

    The LVL includes an alternative full implementation of the Policy interface -called StrictPolicy. The StrictPolicy implementation provides a more restrictive -Policy than ServerManagedPolicy, in that it does not allow the user to access -the application unless a license response is received from the server at the -time of access that indicates that the user is licensed.

    - -

    The principal feature of StrictPolicy is that it does not store any -license response data locally, in a persistent store. Because no data is stored, -retry requests are not tracked and cached responses can not be used to fulfill -license checks. The Policy allows access only if:

    - - - -

    Using StrictPolicy is appropriate if your primary concern is to ensure that, -in all possible cases, no user will be allowed to access the application unless -the user is confirmed to be licensed at the time of use. Additionally, the -Policy offers slightly more security than ServerManagedPolicy — since -there is no data cached locally, there is no way a malicious user could tamper -with the cached data and obtain access to the application.

    - -

    At the same time, this Policy presents a challenge for normal users, since it -means that they won't be able to access the application when there is no network -(cell or wi-fi) connection available. Another side-effect is that your -application will send more license check requests to the server, since using a -cached response is not possible.

    - -

    Overall, this policy represents a tradeoff of some degree of user convenience -for absolute security and control over access. Consider the tradeoff carefully -before using this Policy.

    - -

    To use StrictPolicy, simply import it to your Activity, create an instance, -and pass a reference to it when constructing your LicenseChecker. See -Instantiate LicenseChecker and LicenseCheckerCallback -for more information.

    - -

    Implementing an Obfuscator

    - -
    -
    -

    AESObfuscator

    - -

    The LVL includes a full Obfuscator implementation in the -AESObfuscator.java file. The Obfuscator uses AES encryption to -obfuscate/unobfuscate data. If you are using a Policy (such as -ServerManagedPolicy) that caches license response data, using AESObfuscator as -basis for your Obfuscator implementation is highly recommended.

    - -
    -
    - -

    A typical Policy implementation needs to save the license response data for -an application to a persistent store, so that it is accessible across -application invocations and device power cycles. For example, a Policy would -maintain the timestamp of the last successful license check, the retry count, -the license validity period, and similar information in a persistent store, -rather than resetting the values each time the application is launched. The -default Policy included in the LVL, ServerManagedPolicy, stores license response -data in a {@link android.content.SharedPreferences} instance, to ensure that the -data is persistent.

    - -

    Because the Policy will use stored license response data to determine whether -to allow or disallow access to the application, it must ensure that any -stored data is secure and cannot be reused or manipulated by a root user on a -device. Specifically, the Policy must always obfuscate the data before storing -it, using a key that is unique for the application and device. Obfuscating using -a key that is both application-specific and device-specific is critical, because -it prevents the obfuscated data from being shared among applications and -devices.

    - -

    The LVL assists the application with storing its license response data in a -secure, persistent manner. First, it provides an Obfuscator -interface that lets your application supply the obfuscation algorithm of its -choice for stored data. Building on that, the LVL provides the helper class -PreferenceObfuscator, which handles most of the work of calling the -application's Obfuscator class and reading and writing the obfuscated data in a -SharedPreferences instance.

    - -

    The LVL provides a full Obfuscator implementation called -AESObfuscator that uses AES encryption to obfuscate data. You can -use AESObfuscator in your application without modification or you -can adapt it to your needs. For more information, see the next section.

    - - -

    AESObfuscator

    - -

    The LVL includes a full and recommended implementation of the Obfuscator -interface called AESObfuscator. The implementation is integrated with the -LVL sample application and serves as the default Obfuscator in the library.

    - -

    AESObfuscator provides secure obfuscation of data by using AES to -encrypt and decrypt the data as it is written to or read from storage. -The Obfuscator seeds the encryption using three data fields provided -by the application:

    - -
      -
    1. A salt — an array of random bytes to use for each (un)obfuscation.
      2. -
    2. An application identifier string, typically the package name of the application.
      3. -
    3. A device identifier string, derived from as many device-specific sources -as possible, so as to make it as unique.
      4. -
    - -

    To use AESObfuscator, first import it to your Activity. Declare a private -static final array to hold the salt bytes and initialize it to 20 randomly -generated bytes.

    - -
        ...
-    // Generate 20 random bytes, and put them here.
-    private static final byte[] SALT = new byte[] {
-     -46, 65, 30, -128, -103, -57, 74, -64, 51, 88, -95,
-     -45, 77, -117, -36, -113, -11, 32, -64, 89
-     };
-    ...
-
    - -

    Next, declare a variable to hold a device identifier and generate a value for -it in any way needed. For example, the sample application included in the LVL -queries the system settings for the -android.Settings.Secure.ANDROID_ID, which is unique to each device. -

    - -

    Note that, depending on the APIs you use, your application might need to -request additional permissions in order to acquire device-specific information. -For example, to query the {@link android.telephony.TelephonyManager} to obtain -the device IMEI or related data, the application will also need to request the -android.permission.READ_PHONE_STATE permission in its manifest.

    - -

    Before requesting new permissions for the sole purpose of acquiring -device-specific information for use in your Obfuscator, consider -how doing so might affect your application or its filtering on Android Market -(since some permissions can cause the SDK build tools to add -the associated <uses-feature>).

    - -

    Finally, construct an instance of AESObfuscator, passing the salt, -application identifier, and device identifier. You can construct the instance -directly, while constructing your Policy and LicenseChecker. For example:

    - -
        ...
-    // Construct the LicenseChecker with a Policy.
-    mChecker = new LicenseChecker(
-        this, new ServerManagedPolicy(this,
-            new AESObfuscator(SALT, getPackageName(), deviceId)),
-        BASE64_PUBLIC_KEY  // Your public licensing key.
-        );
-    ...
-
    - -

    For a complete example, see MainActivity in the LVL sample application.

    - - -

    Checking the license from your application's main Activity

    - -

    Once you've implemented a Policy for managing access to your application, the -next step is to add a license check to your application, which initiates a query -to the licensing server if needed and manages access to the application based on -the license response. All of the work of adding the license check and handling -the response takes place in your main {@link android.app.Activity} source file. -

    - -

    To add the license check and handle the response, you must:

    - -
      -
    1. Add imports
      2. -
    2. Implement LicenseCheckerCallback as a private inner class
      3. -
    3. Create a Handler for posting from LicenseCheckerCallback to the UI thread
      4. -
    4. Instantiate LicenseChecker and LicenseCheckerCallback
      5. -
    5. Call checkAccess() to initiate the license check
      6. -
    6. Embed your public key for licensing
      7. -
    7. Call your LicenseChecker's onDestroy() method to close IPC connections.
      8. -
    - -

    The sections below describe these tasks.

    - -

    Overview of license check and response

    - -
    -
    -

    Example: MainActivity

    - -

    The sample application included with the LVL provides a full example of how -to initiate a license check and handle the result, in the -MainActivity.java file.

    - -
    -
    - -

    In most cases, you should add the license check to your application's main -{@link android.app.Activity}, in the onCreate() method. This -ensures that when the user launches your application directly, the license check -will be invoked immediately. In some cases, you can add license checks in other -locations as well. For example, if your application includes multiple Activity -components that other applications can start by {@link android.content.Intent}, -you could add license checks in those Activities.

    - -

    A license check consists of two main actions:

    - - - -
    - - -
    Figure 6. Overview of a -typical license check interaction.
    -
    - -

    The diagram above illustrates how a typical license check takes place:

    - -
      -
    1. Code in the application's main Activity instantiates LicenseCheckerCallback -and LicenseChecker objects. When constructing LicenseChecker, the code passes in -{@link android.content.Context}, a Policy implementation to use, and the -publisher account's public key for licensing as parameters.
      2. -
    2. The code then calls the checkAccess() method on the -LicenseChecker object. The method implementation calls the Policy to determine -whether there is a valid license response cached locally, in -{@link android.content.SharedPreferences}. -
        -
      • If so, the checkAccess() implementation calls -allow().
        • -
      • Otherwise, the LicenseChecker initiates a license check request that is sent -to the licensing server.
        • -
      -

      Note: The licensing server always returns -LICENSED when you perform a license check of a draft application.

      -
      3. -
    3. When a response is received, LicenseChecker creates a LicenseValidator that -verifies the signed license data and extracts the fields of the response, then -passes them to your Policy for further evaluation. -
        -
      • If the license is valid, the Policy caches the response in -SharedPreferences and notifies the validator, which then calls the -allow() method on the LicenseCheckerCallback object.
        • -
      • If the license not valid, the Policy notifies the validator, which calls -the dontAllow() method on LicenseCheckerCallback.
        • -
      -
      4. -
    4. In case of a recoverable local or server error, such as when the network is -not available to send the request, LicenseChecker passes a RETRY response to -your Policy's processServerResponse() method.
      5. -
    5. In case of a application error, such as when the application attempts to -check the license of an invalid package name, LicenseChecker passes an error -response to the LicenseCheckerCallback's applicationError() -method.
      6. -
    - -

    Note that, in addition to initiating the license check and handling the -result, which are described in the sections below, your application also needs -to provide a Policy implementation and, if the Policy -stores response data (such as ServerManagedPolicy), an Obfuscator implementation.

    - - -

    Add imports

    - -

    First, open the class file of the application's main Activity and import -LicenseChecker and LicenseCheckerCallback from the LVL package.

    - -
        import com.android.vending.licensing.LicenseChecker;
-    import com.android.vending.licensing.LicenseCheckerCallback;
    - -

    If you are using the default Policy implementation provided with the LVL, -ServerManagedPolicy, import it also, together with the AESObfuscator. If you are -using a custom Policy or Obfuscator, import those instead.

    - -
        import com.android.vending.licensing.ServerManagedPolicy;
-    import com.android.vending.licensing.AESObfuscator;
    - -

    Implement LicenseCheckerCallback as a private inner class

    - -

    LicenseCheckerCallback is an interface provided by the LVL for handling -result of a license check. To support licensing using the LVL, you must -implement LicenseCheckerCallback and -its methods to allow or disallow access to the application.

    - -

    The result of a license check is always a call to one of the -LicenseCheckerCallback methods, made based on the validation of the response -payload, the server response code itself, and any additional processing provided -by your Policy. Your application can implement the methods in any way needed. In -general, it's best to keep the methods simple, limiting them to managing UI -state and application access. If you want to add further processing of license -responses, such as by contacting a backend server or applying custom constraints, -you should consider incorporating that code into your Policy, rather than -putting it in the LicenseCheckerCallback methods.

    - -

    In most cases, you should declare your implementation of -LicenseCheckerCallback as a private class inside your application's main -Activity class.

    - -

    Implement the allow() and dontAllow() methods as -needed. To start with, you can use simple result-handling behaviors in the -methods, such as displaying the license result in a dialog. This helps you get -your application running sooner and can assist with debugging. Later, after you -have determined the exact behaviors you want, you can add more complex handling. -

    - -

    Some suggestions for handling unlicensed responses in -dontAllow() include:

    - - - -

    The example below shows how the LVL sample application implements -LicenseCheckerCallback, with methods that display the license check result in a -dialog.

    - -
        private class MyLicenseCheckerCallback implements LicenseCheckerCallback {
-        public void allow() {
-            if (isFinishing()) {
-                // Don't update UI if Activity is finishing.
-                return;
-            }
-            // Should allow user access.
-            displayResult(getString(R.string.allow));
-        }
-
-        public void dontAllow() {
-            if (isFinishing()) {
-                // Don't update UI if Activity is finishing.
-                return;
-            }
-            displayResult(getString(R.string.dont_allow));
-            // Should not allow access. An app can handle as needed,
-            // typically by informing the user that the app is not licensed
-            // and then shutting down the app or limiting the user to a
-            // restricted set of features.
-            // In this example, we show a dialog that takes the user to Market.
-            showDialog(0);
-        }
-    }
-
    - -

    Additionally, you should implement the applicationError() -method, which the LVL calls to let your application handle errors that are not -retryable. For a list of such errors, see Server Response Codes in the Appendix of this -document. You can implement the method in any way needed. In most cases, the -method should log the error code and call dontAllow().

    - -

    Create a Handler for posting from LicenseCheckerCallback -to the UI thread

    - -

    During a license check, the LVL passes the request to the Android Market -application, which handles communication with the licensing server. The LVL -passes the request over asynchronous IPC (using {@link android.os.Binder}) so -the actual processing and network communication do not take place on a thread -managed by your application. Similarly, when the Android Market application -receives the result, it invokes a callback method over IPC, which in turn -executes in an IPC thread pool in your application's process.

    - -

    The LicenseChecker class manages your application's IPC communication with -the Android Market application, including the call that sends the request and -the callback that receives the response. LicenseChecker also tracks open license -requests and manages their timeouts.

    - -

    So that it can handle timeouts properly and also process incoming responses -without affecting your application's UI thread, LicenseChecker spawns a -background thread at instantiation. In the thread it does all processing of -license check results, whether the result is a response received from the server -or a timeout error. At the conclusion of processing, the LVL calls your -LicenseCheckerCallback methods from the background thread.

    - -

    To your application, this means that:

    - -
      -
    1. Your LicenseCheckerCallback methods will be invoked, in many cases, from a -background thread.
      2. -
    2. Those methods won't be able to update state or invoke any processing in the -UI thread, unless you create a Handler in the UI thread and have your callback -methods post to the Handler.
      3. -
    - -

    If you want your LicenseCheckerCallback methods to update the UI thread, -instantiate a {@link android.os.Handler} in the main Activity's -{@link android.app.Activity#onCreate(android.os.Bundle) onCreate()} method, -as shown below. In this example, the LVL sample application's -LicenseCheckerCallback methods (see above) call displayResult() to -update the UI thread through the Handler's -{@link android.os.Handler#post(java.lang.Runnable) post()} method.

    - -
    private Handler mHandler;
-
-    @Override
-    public void onCreate(Bundle savedInstanceState) {
-        ...
-        mHandler = new Handler();
-    }
-
    - -

    Then, in your LicenseCheckerCallback methods, you can use Handler methods to -post Runnable or Message objects to the Handler. Here's how the sample -application included in the LVL posts a Runnable to a Handler in the UI thread -to display the license status.

    - -
        private void displayResult(final String result) {
-        mHandler.post(new Runnable() {
-            public void run() {
-                mStatusText.setText(result);
-                setProgressBarIndeterminateVisibility(false);
-                mCheckLicenseButton.setEnabled(true);
-            }
-        });
-    }
-
    - -

    Instantiate LicenseChecker and LicenseCheckerCallback

    - -

    In the main Activity's -{@link android.app.Activity#onCreate(android.os.Bundle) onCreate()} method, -create private instances of LicenseCheckerCallback and LicenseChecker. You must -instantiate LicenseCheckerCallback first, because you need to pass a reference -to that instance when you call the contructor for LicenseChecker.

    - -

    When you instantiate LicenseChecker, you need to pass in these parameters:

    - - - -

    If you are using ServerManagedPolicy, you won't need to access the class -directly, so you can instantiate it in the LicenseChecker constructor, -as shown in the example below. Note that you need to pass a reference to a new -Obfuscator instance when you construct ServerManagedPolicy.

    - -

    The example below shows the instantiation of LicenseChecker and -LicenseCheckerCallback from the onCreate() method of an Activity -class.

    - -
    public class MainActivity extends Activity {
-    ...
-    private LicenseCheckerCallback mLicenseCheckerCallback;
-    private LicenseChecker mChecker;
-
-    @Override
-    public void onCreate(Bundle savedInstanceState) {
-        super.onCreate(savedInstanceState);
-        ...
-        // Construct the LicenseCheckerCallback. The library calls this when done.
-        mLicenseCheckerCallback = new MyLicenseCheckerCallback();
-
-        // Construct the LicenseChecker with a Policy.
-        mChecker = new LicenseChecker(
-            this, new ServerManagedPolicy(this,
-                new AESObfuscator(SALT, getPackageName(), deviceId)),
-            BASE64_PUBLIC_KEY  // Your public licensing key.
-            );
-        ...
-    }
-}
-
    - - -

    Note that LicenseChecker calls the LicenseCheckerCallback methods from the UI -thread only if there is valid license response cached locally. If the -license check is sent to the server, the callbacks always originate from the -background thread, even for network errors.

    - - -

    Call checkAccess() to initiate the license check

    - -

    In your main Activity, add a call to the checkAccess() method of the -LicenseChecker instance. In the call, pass a reference to your -LicenseCheckerCallback instance as a parameter. If you need to handle any -special UI effects or state management before the call, you might find it useful -to call checkAccess() from a wrapper method. For example, the LVL -sample application calls checkAccess() from a -doCheck() wrapper method:

    - -
        @Override
-    public void onCreate(Bundle savedInstanceState) {
-        super.onCreate(savedInstanceState);
-        ...
-        // Call a wrapper method that initiates the license check
-        doCheck();
-        ...
-    }
-    ...
-    private void doCheck() {
-        mCheckLicenseButton.setEnabled(false);
-        setProgressBarIndeterminateVisibility(true);
-        mStatusText.setText(R.string.checking_license);
-        mChecker.checkAccess(mLicenseCheckerCallback);
-    }
-
    - - -

    Embed your public key for licensing

    - -

    For each publisher account, the Android Market service automatically -generates a 2048-bit RSA public/private key pair that is used exclusively for -licensing. The key pair is uniquely associated with the publisher account and is -shared across all applications that are published through the account. Although -associated with a publisher account, the key pair is not the same as -the key that you use to sign your applications (or derived from it).

    - -

    The Android Market publisher site exposes the public key for licensing to any -developer signed in to the publisher account, but it keeps the private key -hidden from all users in a secure location. When an application requests a -license check for an application published in your account, the licensing server -signs the license response using the private key of your account's key pair. -When the LVL receives the response, it uses the public key provided by the -application to verify the signature of the license response.

    - -

    To add licensing to an application, you must obtain your publisher account's -public key for licensing and copy it into your application. Here's how to find -your account's public key for licensing:

    - -
      -
    1. Go to the Android Market publisher site and sign in. -Make sure that you sign in to the account from which the application you are -licensing is published (or will be published).
      2. -
    2. In the account home page, locate the "Edit profile" link and click it.
      3. -
    3. In the Edit Profile page, locate the "Licensing" pane, shown below. Your -public key for licensing is given in the "Public key" text box.
      4. -
    - -

    To add the public key to your application, simply copy/paste the key string -from the text box into your application as the value of the String variable -BASE64_PUBLIC_KEY. When you are copying, make sure that you have -selected the entire key string, without omitting any characters.

    - -

    Here's an example from the LVL sample application:

    - -
        public class MainActivity extends Activity {
-        private static final String BASE64_PUBLIC_KEY = "MIIBIjANBgkqhkiG ... "; //truncated for this example
-    ...
-    }
-
    - -

    Call your LicenseChecker's onDestroy() method -to close IPC connections

    - -

    Finally, to let the LVL clean up before your application -{@link android.content.Context} changes, add a call to the LicenseChecker's -onDestroy() method from your Activity's -{@link android.app.Activity#onDestroy()} implementation. The call causes the -LicenseChecker to properly close any open IPC connection to the Android Market -application's ILicensingService and removes any local references to the service -and handler.

    - -

    Failing to call the LicenseChecker's onDestroy() method -can lead to problems over the lifecycle of your application. For example, if the -user changes screen orientation while a license check is active, the application -{@link android.content.Context} is destroyed. If your application does not -properly close the LicenseChecker's IPC connection, your application will crash -when the response is received. Similarly, if the user exits your application -while a license check is in progress, your application will crash when the -response is received, unless it has properly called the -LicenseChecker's onDestroy() method to disconnect from the service. -

    - -

    Here's an example from the sample application included in the LVL, where -mChecker is the LicenseChecker instance:

    - -
        @Override
-    protected void onDestroy() {
-        super.onDestroy();
-        mChecker.onDestroy();
-        ...
-    }
-
    - -

    If you are extending or modifying LicenseChecker, you might also need to call -the LicenseChecker's finishCheck() method, to clean up any open IPC -connections.

    - -

    Implementing a DeviceLimiter

    - -

    In some cases, you might want your Policy to limit the number of actual -devices that are permitted to use a single license. This would prevent a user -from moving a licensed application onto a number of devices and using the -application on those devices under the same account ID. It would also prevent a -user from "sharing" the application by providing the account information -associated with the license to other individuals, who could then sign in to that -account on their devices and access the license to the application.

    - -

    The LVL supports per-device licensing by providing a -DeviceLimiter interface, which declares a single method, -allowDeviceAccess(). When a LicenseValidator is handling a response -from the licensing server, it calls allowDeviceAccess(), passing a -user ID string extracted from the response.

    - -

    If you do not want to support device limitation, no work is -required — the LicenseChecker class automatically uses a default -implementation called NullDeviceLimiter. As the name suggests, NullDeviceLimiter -is a "no-op" class whose allowDeviceAccess() method simply returns -a LICENSED response for all users and devices.

    - -
    -

    Caution: Per-device licensing is not recommended for -most applications because:

    - -
    - - -

    Setting Up the Testing Environment

    - -

    The Android Market publisher site provides configuration tools that let you -and others test licensing on your application before it is published. As you are -implementing licensing, you can make use of the publisher site tools to test -your application's Policy and handling of different licensing responses and -error conditions.

    - -

    The main components of the test environment for licensing include:

    - - - -

    Setting up the test environment properly involves:

    - -
      -
    1. Setting static test responses that are returned by the licensing server.
      2. -
    2. Setting up test accounts as needed.
      3. -
    3. Signing in properly to an emulator or device, before initiating a license check test.
      4. -
    - -

    The sections below provide more information.

    - - -

    Setting test responses for license checks

    - -

    Android Market provides a configuration setting in your publisher account -that lets you override the normal processing of a license check and return a -specified static response code. The setting is for testing only and applies -only to license checks for applications that you have uploaded, made by -any user signed in to an emulator or device using the credentials of the -publisher account or a registered test account. For other users, the server -always processes license checks according to normal rules.

    - -

    To set a test response for your account, sign in to your publisher account -and click "Edit Profile". In the Edit Profile page, locate the Test Response -menu in the Licensing panel, shown below. You can select from the full set of -valid server response codes to control the response or condition you want to -test in your application.

    - -

    In general, you should make sure to test your application's licensing -implementation with every response code available in the Test Response menu. -For a description of the codes, see Server -Response Codes in the Appendix of this document.

    - -
    - - -
    Figure 7. The Licensing -panel of your account's Edit Profile page, showing the Test Accounts field and the -Test Response menu.
    -
    - -

    Note that the test response that you configure applies account-wide — -that is, it applies not to a single application, but to all -applications associated with the publisher account. If you are testing multiple -applications at once, changing the test response will affect all of those -applications on their next license check (if the user is signed into -the emulator or device using the publisher account or a test account).

    - -

    Before you can successfully receive a test response for a license check, -you must sign in to the device or emulator on which the application -is installed, and from which it is querying the server. Specifically, you must -sign using either your publisher account or one of the test accounts that you -have set up. For more information about test accounts, see the next section.

    - -

    See Server Response Codes for a list of -test responses available and their meanings.

    - - -

    Setting up test accounts

    - -

    In some cases, you might want to let multiple teams of developers test -licensing on applications that will ultimately be published through your -publisher account, but without giving them access to your publisher account's -sign-in credentials. To meet that need, the Android Market publisher site lets -you set up one or more optional test accounts — accounts that are -authorized to query the licensing server and receive static test responses from -your publisher account.

    - -

    Test accounts are standard Google accounts that you register on your -publisher account, such that they will receive the test response for -applications that you have uploaded. Developers can then sign in to their -devices or emulators using the test account credentials and initiate license -checks from installed applications. When the licensing server receives a license -check from a user of a test account, it returns the static test response -configured for the publisher account.

    - -

    Necessarily, there are limitations on the access and permissions given to -users signed in through test accounts, including:

    - - - -

    The table below summarizes the differences in capabilities, between the -publisher account, a test account, and any other account.

    - -

    Table 1. -Differences in account types for testing licensing.

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Account TypeCan check license before upload?Can receive test response?Can set test response?
    Publisher accountYesYesYes
    Test accountNoYesNo
    OtherNoNoNo
    - -

    Registering test accounts on the publisher account

    - -

    To get started, you need to register each test account in your publisher -account. As shown in Figure 7, above, you -register test accounts in the Licensing panel of your publisher account's Edit -Profile page. Simply enter the accounts as a comma-delimited list and click -Save to save your profile changes.

    - -

    You can use any Google account as a test account. If you want to own and -control the test accounts, you can create the accounts yourself and distribute -the credentials to your developers or testers.

    - -

    Handling application upload and distribution for test -account users

    - -

    As mentioned above, users of test accounts can only receive static test -responses for applications that are uploaded to the publisher account. Since -those users do not have permission to upload applications, as the publisher you -will need to work with those users to collect apps for upload and distribute -uploaded apps for testing. You can handle collection and distribution in any way -that is convenient.

    - -

    Once an application is uploaded and becomes known to the licensing server, -developers and testers can continue modify the application in their local -development environment, without having to upload new versions. You only need to -upload a new version if the local application increments the -versionCode attribute in the manifest file.

    - -

    Distributing your public key to test account users

    - -

    The licensing server handles static test responses in the normal way, -including signing the license response data, adding extras parameters, and so -on. To support developers who are implementing licensing using test accounts, -rather than the publisher account, you will need to distribute -your public key to them. Developers without access to the publisher site do not -have access to your public key, and without the key they won't be able to -verify license responses.

    - -

    Note that if you decide to generate a new licensing key pair for your account -for some reason, you need to notify all users of test accounts. For -testers, you can embed the new key in the application package and distribute it -to users. For developers, you will need to distribute the new key to them -directly.

    - - -

    Signing in to an authorized account in the runtime -environment

    - -

    The licensing service is designed to determine whether a given user is -licensed to use a given application — during a license check, the Android -Market application gathers the user ID from the primary account on the system -and sends it to the server, together with the package name of the application -and other information. However, if there is no user information available, the -license check cannot succeed, so the Android Market application terminates the -request and returns an error to the application.

    - -

    During testing, to ensure that your application can successfully query the -licensing server, you must make sure that you sign in to an account on the -device or emulator using:

    - - - - -
    -
    -

    Signing in to a Google account on an emulator

    - -

    If you are testing licensing on an emulator, you need to sign in to a Google -account on the emulator. If you do not see an option to create a new Google -account, the problem might be that your AVD is running a standard Android system -image, rather than the Google APIs Add-On, API 8 (release 2) or higher.

    - -

    For more information, see Setting up the runtime environment, above.

    - -
    -
    - -

    Signing in using a publisher account offers the advantage of letting your -applications receive static test responses even before the applications are -uploaded to the publisher site.

    - -

    If you are part of a larger organization or are working with external groups -on applications that will be published through your site, you will more likely -want to distribute test accounts instead, then use those to sign in during -testing.

    - -

    To sign in on a device or emulator, follow the steps below. The preferred -approach is to sign in as the primary account — however, if there are -other accounts already in use on the device or emulator, you can create an -additional account and sign in to it using the publisher or test account -credentials.

    - -
      -
    1. Open Settings > Accounts & sync
      2. -
    2. Select Add Account and choose to add a "Google" account. -
      3. -
    3. Select Next and then Sign in.
      4. -
    4. Enter the username and password of either the publisher account or a test -account that is registered in the publisher account.
      5. -
    5. Select Sign in. The system signs you in to the new -account.
      6. -
    - -

    Once you are signed in, you can begin testing licensing in your application -(if you have completed the LVL integration steps above). When your application -initiates a license check, it will receive a response containing the static test -response configured on the publisher account.

    - -

    Note that, if you are using an emulator, you will need to sign in to the -publisher account or test account each time you wipe data when restarting the -emulator.

    - -
    - - -
    Figure 8. Example of -setting up a Google account on a device or emulator.
    -
    - -

    Obfuscating Your Application

    - -

    To ensure the security of your application, particularly for a paid -application that uses licensing and/or custom constraints and protections, it's -very important to obfuscate your application code. Properly obfuscating your -code makes it more difficult for a malicious user to decompile the application's -bytecode, modify it — such as by removing the license check — -and then recompile it.

    - -

    Several obfuscator programs are available for Android applications, including -ProGuard, which also offers -code-optimization features. The use of ProGuard or a similar program to obfuscate -your code is strongly recommended for all applications that use Android -Market Licensing.

    - -

    Publishing a Licensed Application

    - -

    When you are finished testing your license implementation, you are ready to -publish the application on Android Market. Follow the normal steps to prepare, sign, and then publish the application. -

    - -

    Removing Copy Protection

    - -

    After uploading your licensed application, remember to remove copy protection -from the application, if it is currently used. To check and remove copy -protection, sign in to the publisher site and go the application's upload -details page. In the Publishing options section, make sure that the Copy -Protection radio button selection is "Off".

    - -

    Considerations for Free Apps

    - -

    Licensing is currently supported only for paid applications. If you already -published your application as free, you won't be able to upload an updated -version that includes licensing (that is, an application that uses the same -package name and that includes the licensing -permission). Here are some points to keep in mind:

    - - - -

    Where to Get Support

    - -

    If you have questions or encounter problems while implementing or deploying -publishing in your applications, please use the support resources listed in the -table below. By directing your queries to the correct forum, you can get the -support you need more quickly.

    - -

    Table 2. Developer support resources -for Android Market Licensing Service.

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Support TypeResourceRange of Topics
    Development and testing issuesGoogle Groups: android-developers -LVL download and integration, library projects, Policy -questions, user experience ideas, handling of responses, Obfuscator, IPC, test -environment setup
    Stack Overflow: http://stackoverflow.com/questions/tagged/android
    Accounts, publishing, and deployment issuesAndroid -Market Help ForumPublisher accounts, licensing key pair, test accounts, server -responses, test responses, application deployment and results
    Market -Licensing Support FAQ
    LVL issue trackerMarketlicensing -project issue trackerBug and issue reports related specifically to the LVL source code classes -and interface implementations
    - -

    For general information about how to post to the groups listed above, see Developer Forums document -in the Resources tab.

    - -

    Summary of LVL Classes and Interfaces

    - -

    The table below lists all of the source files in the License Verification -Library (LVL) available through the Android SDK. All of the files are part of -the com.android.vending.licensing package.

    - -

    Table A-1. Summary of LVL library -classes and interfaces.

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    CategoryNameDescription
    License check and resultLicenseCheckerClass that you instantiate (or subclass) to initiate a license check.
    LicenseCheckerCallbackInterface that you implement to handle result of the license check.
    PolicyPolicyInterface that you implement to determine whether to allow -access to the application, based on the license response.
    ServerManagedPolicyDefault Policy implementation. Uses settings provided by the -licensing server to manage local storage of license data, license validity, -retry.
    StrictPolicyAlternative Policy implementation. Enforces licensing based on a direct -license response from the server only. No caching or request retry.
    Data obfuscation
    (optional)    		ObfuscatorInterface that you implement if you are using a Policy (such as -ServerManagedPolicy) that caches license response data in a persistent store. -Applies an obfuscation algorithm to encode and decode data being written or -read.
    AESObfuscatorDefault Obfuscator implementation that uses AES encryption/decryption -algorithm to obfuscate/unobfuscate data.
    Device limitation
    (optional)    		DeviceLimiterInterface that you implement if you want to restrict use of an -application to a specific device. Called from LicenseValidator. Implementing -DeviceLimiter is not recommended for most applications because it requires a -backend server and may cause the user to lose access to licensed applications, -unless designed with care.
    NullDeviceLimiterDefault DeviceLimiter implementation that is a no-op (allows access to all -devices).
    Library core, no integration neededResponseDataClass that holds the fields of a license response.
    LicenseValidatorClass that decrypts and verifies a response received from the licensing -server.
    ValidationExceptionClass that indicates errors that occur when validating the integrity of data -managed by an Obfuscator.
    PreferenceObfuscatorUtility class that writes/reads obfuscated data to the system's -{@link android.content.SharedPreferences} store.
    ILicensingServiceOne-way IPC interface over which a license check request is passed to the -Android Market client.
    ILicenseResultListenerOne-way IPC callback implementation over which the application receives an -asynchronous response from the licensing server.
    -
    - - -

    Server Response Codes

    - -

    The table below lists all of the license response codes supported by the -licensing server. In general, an application should handle all of these response -codes. By default, the LicenseValidator class in the LVL provides all of the -necessary handling of these response codes for you.

    - -

    Table A-2. Summary of response codes -returned by the Android Market server in a license response.

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Response CodeDescriptionSigned?ExtrasComments
    LICENSEDThe application is licensed to the user. The user has purchased the -application or the application only exists as a draft.YesVT, GT, GRAllow access according to Policy constraints.
    LICENSED_OLD_KEYThe application is licensed to the user, but there is an updated application -version available that is signed with a different key. Yes VT, GT, GR, UTOptionally allow access according to Policy constraints. -

    Can indicate that the key pair used by the installed -application version is invalid or compromised. The application can allow access -if needed or inform the user that an upgrade is available and limit further use -until upgrade.

    -
    NOT_LICENSEDThe application is not licensed to the user.NoDo not allow access.
    ERROR_CONTACTING_SERVERLocal error — the Android Market application was not able to reach the -licensing server, possibly because of network availability problems. NoRetry the license check according to Policy retry limits.
    ERROR_SERVER_FAILUREServer error — the server could not load the publisher account's key -pair for licensing.NoRetry the license check according to Policy retry limits. -
    ERROR_INVALID_PACKAGE_NAMELocal error — the application requested a license check for a package -that is not installed on the device. No Do not retry the license check. -

    Typically caused by a development error.

    -
    ERROR_NON_MATCHING_UIDLocal error — the application requested a license check for a package -whose UID (package, user ID pair) does not match that of the requesting -application. No Do not retry the license check. -

    Typically caused by a development error.

    -
    ERROR_NOT_MARKET_MANAGEDServer error — the application (package name) was not recognized by -Android Market. NoDo not retry the license check. -

    Can indicate that the application was not published -through Android Market or that there is an development error in the licensing -implementation.

    -
    - -

    Note: As documented in -Setting Up The Testing Environment, the response code can be manually -overridden for the application developer and any registered test users via the -Android Market publisher site. -

    -Additionally, as noted above, applications that are in draft mode (in other -words, applicaitons that have been uploaded but have never been -published) will return LICENSED for all users, even if not listed as a test -user. Since the application has never been offered for download, it is assumed -that any users running it must have obtained it from an authorized channel for -testing purposes.

    - -

    Server Response Extras

    - -

    The licensing server includes several settings in certain types of license -responses, to assist the application and its Policy in managing access to the -application across the 24-hour refund period and other conditions. Specifically, -the server provides recommended values for the application's license validity -period, retry grace period, maximum allowable retry count, and other settings. -The server appends the settings as key-value pairs in the license response -"extras" field.

    - -

    Any Policy implementation can extract the extras settings from the license -response and use them as needed. The LVL default Policy implementation, ServerManagedPolicy, serves as a working -implementation and an illustration of how to obtain, store, and use the -settings.

    - -

    Table A-3. Summary of -license-management settings supplied by the Android Market server in a license -response.

    - - - - - - - - - - - - - - - - - - - - - - - -
    ExtraDescription
    VTLicense validity timestamp. Specifies the date/time at which the current -(cached) license response expires and must be rechecked on the licensing server. -
    GTGrace period timestamp. Specifies the end of the period during which a -Policy may allow access to the application, even though the response status is -RETRY.

    The value is managed by the server, however a typical value would be 5 -or more days.

    GRMaximum retries count. Specifies how many consecutive RETRY license checks -the Policy should allow, before denying the user access to the application. -

    The value is managed by the server, however a typical value would be "10" or -higher.

    UTUpdate timestamp. Specifies the day/time when the most recent update to -this application was uploaded and published.

    The server returns this extra -only for LICENSED_OLD_KEYS responses, to allow the Policy to determine how much -time has elapsed since an update was published with new licensing keys before -denying the user access to the application.

    - -

    The sections below provide more information about the server-provided -settings and how to use them.

    - -

    License validity period

    - -

    The Android Market licensing server sets a license validity period for all -downloaded applications. The period expresses the interval of time over which an -application's license status should be considered as unchanging and cacheable by -a licensing Policy in the application. The licensing server includes the -validity period in its response to all license checks, appending an -end-of-validity timestamp to the response as an extra under the key "VT". A -Policy can extract the VT key value and use it to conditionally allow access to -the application without rechecking the license, until the validity period -expires.

    - -

    The license validity signals to a licensing Policy when it must recheck the -licensing status with the licensing server. It is not intended to imply -whether an application is actually licensed for use. That is, when an -application's license validity period expires, this does not mean that the -application is no longer licensed for use — rather, it indicates only that -the Policy must recheck the licensing status with the server. It follows that, -as long as the license validity period is not expired, it is acceptable for the -Policy to cache the initial license status locally and return the cached license -status instead of sending a new license check to the server.

    - -

    The licensing server manages the validity period as a means of helping the -application properly enforce licensing across the refund period offered by -Android Market for paid applications. It sets the validity period based on -whether the application was purchased and, if so, how long ago. Specifically, -the server sets a validity period as follows:

    - - - -

    The ServerManagedPolicy implementation uses the extracted timestamp -(mValidityTimestamp) as a primary condition for determining whether -to recheck the license status with the server before allowing the user access to -the application.

    - -

    Retry period and maximum retry count

    - -

    In some cases, system or network conditions can prevent an application's -license check from reaching the licensing server, or prevent the server's -response from reaching the Android Market client application. For example, the -user might launch an application when there is no cell network or data -connection available — such as when on an airplane — or when the -network connection is unstable or the cell signal is weak.

    - -

    When network problems prevent or interrupt a license check, the Android -Market client notifies the application by returning a "RETRY" response code to -the Policy's processServerResponse() method. In the case of system -problems, such as when the application is unable to bind with Android Market's -ILicensingService implementation, the LicenseChecker library itself calls the -Policy processServerResonse() method with a "RETRY" response code. -

    - -

    In general, the RETRY response code is a signal to the application that an -error has occurred that has prevented a license check from completing. - -

    The Android Market server helps an application to manage licensing under -error conditions by setting a retry "grace period" and a recommended maximum -retries count. The server includes these values in all license check responses, -appending them as extras under the keys "GT" and "GR".

    - -

    The application Policy can extract the GT and GR extras and use them to -conditionally allow access to the application, as follows:

    - - - -

    The ServerManagedPolicy uses the server-supplied GT and GR values as -described above. The example below shows the conditional handling of the retry -responses in the allow() method. The count of RETRY responses is -maintained in the processServerResponse() method, not shown.

    - - -
        public boolean allowAccess() {
-        long ts = System.currentTimeMillis();
-        if (mLastResponse == LicenseResponse.LICENSED) {
-            // Check if the LICENSED response occurred within the validity timeout.
-            if (ts <= mValidityTimestamp) {
-                // Cached LICENSED response is still valid.
-                return true;
-            }
-        } else if (mLastResponse == LicenseResponse.RETRY &&
-                   ts < mLastResponseTime + MILLIS_PER_MINUTE) {
-            // Only allow access if we are within the retry period or we haven't used up our
-            // max retries.
-            return (ts <= mRetryUntil || mRetryCount <= mMaxRetries);
-        }
-        return false;
-    }
    - diff --git a/docs/html/guide/publishing/preparing.jd b/docs/html/guide/publishing/preparing.jd index 83aa5eedcdb8b..c355479922a27 100644 --- a/docs/html/guide/publishing/preparing.jd +++ b/docs/html/guide/publishing/preparing.jd @@ -291,7 +291,8 @@ current user has purchased it. Using Android Market Licensing is optional even i releasing your app through Android Market.

    For more information about Android Market Licensing Service and how to use it in your -application, see Application Licensing.

    +application, see Application +Licensing.

    Building Your Application for Release

    diff --git a/docs/html/guide/publishing/publishing.jd b/docs/html/guide/publishing/publishing.jd index 49b34d8d2fd6b..27a87f944bc16 100644 --- a/docs/html/guide/publishing/publishing.jd +++ b/docs/html/guide/publishing/publishing.jd @@ -74,7 +74,7 @@ Android Market you have access to a suite of developer tools that let you analyz identify market trends, and control who your applications are being distributed to. You also have access to several revenue-enhancing features, such as in-app billing and -application licensing.

    +application licensing.

    Before you can publish applications on Android Market, you need to register as an Android Market developer. During the @@ -254,7 +254,7 @@ higher.

    For complete information about Android Market Licensing Service and how to use it in your application, read Application Licensing.

    +href="{@docRoot}guide/market/licensing/index.html">Application Licensing.

    Using Android Market In-app Billing

    diff --git a/docs/html/guide/publishing/publishing_overview.jd b/docs/html/guide/publishing/publishing_overview.jd index 79199c5c674a5..c94d20181cb50 100755 --- a/docs/html/guide/publishing/publishing_overview.jd +++ b/docs/html/guide/publishing/publishing_overview.jd @@ -130,7 +130,8 @@ Android Market you have access to a suite of developer tools that let you analyz identify market trends, and control who your applications are being distributed to. You also have access to several revenue-enhancing features that are not available anywhere else, such as in-app billing and application licensing. This rich array of tools +href="{@docRoot}guide/market/licensing/index.html">application licensing. This rich array of +tools and features, coupled with numerous end-user community features, makes Android Market the premier marketplace for selling and buying Android applications.

    diff --git a/docs/html/guide/topics/manifest/manifest-element.jd b/docs/html/guide/topics/manifest/manifest-element.jd index d737a67a9058b..c970c72441402 100644 --- a/docs/html/guide/topics/manifest/manifest-element.jd +++ b/docs/html/guide/topics/manifest/manifest-element.jd @@ -152,7 +152,7 @@ either internal or external storage through the system settings.

    Caution: If your application uses the Android Market's Copy Protection feature, it cannot be installed to a device's SD card. However, if you use Android - Market's Application Licensing instead, + Market's Application Licensing instead, your application can be installed to internal or external storage, including SD cards.

    Note: By default, your application will be installed on the diff --git a/docs/html/sitemap.txt b/docs/html/sitemap.txt index 0298a8ed28c16..182e958fc450a 100644 --- a/docs/html/sitemap.txt +++ b/docs/html/sitemap.txt @@ -108,7 +108,7 @@ http://developer.android.com/guide/topics/testing/activity_testing.html http://developer.android.com/guide/topics/testing/contentprovider_testing.html http://developer.android.com/guide/topics/testing/service_testing.html http://developer.android.com/guide/topics/testing/what_to_test.html -http://developer.android.com/guide/publishing/licensing.html +http://developer.android.com/guide/market/licensing/index.html http://developer.android.com/guide/market/billing/index.html http://developer.android.com/guide/market/billing/billing_about.html http://developer.android.com/guide/market/billing/billing_overview.html From 93dc642eaf48e3db58c4929df26283fbc5fd663f Mon Sep 17 00:00:00 2001 From: Scott Main Date: Fri, 24 Feb 2012 12:04:06 -0800 Subject: [PATCH 02/17] docs: fix misc bugs from external tracker Change-Id: I2be617be23d0ac50baabac561d510633fa9f162a --- core/java/android/view/LayoutInflater.java | 4 +- core/java/android/widget/RemoteViews.java | 49 +++--- .../html/guide/developing/devices/emulator.jd | 2 +- docs/html/guide/developing/tools/emulator.jd | 2 +- .../guide/topics/fundamentals/activities.jd | 2 +- .../guide/topics/fundamentals/fragments.jd | 2 +- docs/html/guide/topics/wireless/bluetooth.jd | 32 ++-- .../tutorials/notepad/notepad-ex2.jd | 2 +- .../tutorials/views/hello-formstuff.jd | 164 +++++++++--------- .../tutorials/views/hello-mapview.jd | 2 +- 10 files changed, 136 insertions(+), 125 deletions(-) diff --git a/core/java/android/view/LayoutInflater.java b/core/java/android/view/LayoutInflater.java index 9628d6b0f9fe4..3c0ee12799b6a 100644 --- a/core/java/android/view/LayoutInflater.java +++ b/core/java/android/view/LayoutInflater.java @@ -34,8 +34,8 @@ import java.lang.reflect.Constructor; import java.util.HashMap; /** - * This class is used to instantiate layout XML file into its corresponding View - * objects. It is never be used directly -- use + * Instantiates a layout XML file into its corresponding {@link android.view.View} + * objects. It is never used directly. Instead, use * {@link android.app.Activity#getLayoutInflater()} or * {@link Context#getSystemService} to retrieve a standard LayoutInflater instance * that is already hooked up to the current context and correctly configured diff --git a/core/java/android/widget/RemoteViews.java b/core/java/android/widget/RemoteViews.java index 1592061906ab7..efb8729966ba2 100644 --- a/core/java/android/widget/RemoteViews.java +++ b/core/java/android/widget/RemoteViews.java @@ -1183,7 +1183,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Equivalent to calling ImageView.setImageBitmap * - * @param viewId The id of the view whose drawable should change + * @param viewId The id of the view whose bitmap should change * @param bitmap The new Bitmap for the drawable */ public void setImageViewBitmap(int viewId, Bitmap bitmap) { @@ -1206,7 +1206,7 @@ public class RemoteViews implements Parcelable, Filter { * and {@link Chronometer#start Chronometer.start()} or * {@link Chronometer#stop Chronometer.stop()}. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the {@link Chronometer} to change * @param base The time at which the timer would have read 0:00. This * time should be based off of * {@link android.os.SystemClock#elapsedRealtime SystemClock.elapsedRealtime()}. @@ -1227,7 +1227,7 @@ public class RemoteViews implements Parcelable, Filter { * * If indeterminate is true, then the values for max and progress are ignored. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the {@link ProgressBar} to change * @param max The 100% value for the progress bar * @param progress The current value of the progress bar. * @param indeterminate True if the progress bar is indeterminate, @@ -1333,7 +1333,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Equivalent to calling {@link android.widget.TextView#setTextColor(int)}. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view whose text color should change * @param color Sets the text color for all the states (normal, selected, * focused) to be this color. */ @@ -1346,7 +1346,7 @@ public class RemoteViews implements Parcelable, Filter { * * @param appWidgetId The id of the app widget which contains the specified view. (This * parameter is ignored in this deprecated method) - * @param viewId The id of the view whose text should change + * @param viewId The id of the {@link AbsListView} * @param intent The intent of the service which will be * providing data to the RemoteViewsAdapter * @deprecated This method has been deprecated. See @@ -1361,7 +1361,7 @@ public class RemoteViews implements Parcelable, Filter { * Equivalent to calling {@link android.widget.AbsListView#setRemoteViewsAdapter(Intent)}. * Can only be used for App Widgets. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the {@link AbsListView} * @param intent The intent of the service which will be * providing data to the RemoteViewsAdapter */ @@ -1372,7 +1372,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Equivalent to calling {@link android.widget.AbsListView#smoothScrollToPosition(int, int)}. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view to change * @param position Scroll to this adapter position */ public void setScrollPosition(int viewId, int position) { @@ -1382,7 +1382,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Equivalent to calling {@link android.widget.AbsListView#smoothScrollToPosition(int, int)}. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view to change * @param offset Scroll by this adapter position offset */ public void setRelativeScrollPosition(int viewId, int offset) { @@ -1392,7 +1392,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Call a method taking one boolean on a view in the layout for this RemoteViews. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view on which to call the method. * @param methodName The name of the method to call. * @param value The value to pass to the method. */ @@ -1403,7 +1403,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Call a method taking one byte on a view in the layout for this RemoteViews. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view on which to call the method. * @param methodName The name of the method to call. * @param value The value to pass to the method. */ @@ -1414,7 +1414,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Call a method taking one short on a view in the layout for this RemoteViews. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view on which to call the method. * @param methodName The name of the method to call. * @param value The value to pass to the method. */ @@ -1425,7 +1425,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Call a method taking one int on a view in the layout for this RemoteViews. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view on which to call the method. * @param methodName The name of the method to call. * @param value The value to pass to the method. */ @@ -1436,7 +1436,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Call a method taking one long on a view in the layout for this RemoteViews. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view on which to call the method. * @param methodName The name of the method to call. * @param value The value to pass to the method. */ @@ -1447,7 +1447,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Call a method taking one float on a view in the layout for this RemoteViews. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view on which to call the method. * @param methodName The name of the method to call. * @param value The value to pass to the method. */ @@ -1458,7 +1458,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Call a method taking one double on a view in the layout for this RemoteViews. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view on which to call the method. * @param methodName The name of the method to call. * @param value The value to pass to the method. */ @@ -1469,7 +1469,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Call a method taking one char on a view in the layout for this RemoteViews. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view on which to call the method. * @param methodName The name of the method to call. * @param value The value to pass to the method. */ @@ -1480,7 +1480,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Call a method taking one String on a view in the layout for this RemoteViews. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view on which to call the method. * @param methodName The name of the method to call. * @param value The value to pass to the method. */ @@ -1491,7 +1491,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Call a method taking one CharSequence on a view in the layout for this RemoteViews. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view on which to call the method. * @param methodName The name of the method to call. * @param value The value to pass to the method. */ @@ -1502,7 +1502,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Call a method taking one Uri on a view in the layout for this RemoteViews. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view on which to call the method. * @param methodName The name of the method to call. * @param value The value to pass to the method. */ @@ -1516,7 +1516,7 @@ public class RemoteViews implements Parcelable, Filter { *

    The bitmap will be flattened into the parcel if this object is * sent across processes, so it may end up using a lot of memory, and may be fairly slow.

    * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view on which to call the method. * @param methodName The name of the method to call. * @param value The value to pass to the method. */ @@ -1527,7 +1527,7 @@ public class RemoteViews implements Parcelable, Filter { /** * Call a method taking one Bundle on a view in the layout for this RemoteViews. * - * @param viewId The id of the view whose text should change + * @param viewId The id of the view on which to call the method. * @param methodName The name of the method to call. * @param value The value to pass to the method. */ @@ -1536,10 +1536,11 @@ public class RemoteViews implements Parcelable, Filter { } /** + * Call a method taking one Intent on a view in the layout for this RemoteViews. * - * @param viewId - * @param methodName - * @param value + * @param viewId The id of the view on which to call the method. + * @param methodName The name of the method to call. + * @param value The {@link android.content.Intent} to pass the method. */ public void setIntent(int viewId, String methodName, Intent value) { addAction(new ReflectionAction(viewId, methodName, ReflectionAction.INTENT, value)); diff --git a/docs/html/guide/developing/devices/emulator.jd b/docs/html/guide/developing/devices/emulator.jd index 02dcb68fd1535..c217790e19cf0 100644 --- a/docs/html/guide/developing/devices/emulator.jd +++ b/docs/html/guide/developing/devices/emulator.jd @@ -78,7 +78,7 @@ preinstalled applications (such as the dialer) that you can access from your applications. You can choose what version of the Android system you want to run in the emulator by configuring AVDs, and you can also customize the mobile device skin and key mappings. When launching the emulator and at runtime, -you can use a variety of commands and options to control the its behaviors. +you can use a variety of commands and options to control its behavior.

    The Android system image distributed in the SDK contains ARM machine code for diff --git a/docs/html/guide/developing/tools/emulator.jd b/docs/html/guide/developing/tools/emulator.jd index 5151ec14db472..09e41c3a17c2e 100644 --- a/docs/html/guide/developing/tools/emulator.jd +++ b/docs/html/guide/developing/tools/emulator.jd @@ -516,7 +516,7 @@ the keys of your keyboard.

    Audio volume up button - KEYPAD_PLUS, Ctrl-5 + KEYPAD_PLUS, Ctrl-F5 diff --git a/docs/html/guide/topics/fundamentals/activities.jd b/docs/html/guide/topics/fundamentals/activities.jd index 8736aa89ed4ce..b79136cbb8c05 100644 --- a/docs/html/guide/topics/fundamentals/activities.jd +++ b/docs/html/guide/topics/fundamentals/activities.jd @@ -62,7 +62,7 @@ is presented to the user when launching the application for the first time. Each activity can then start another activity in order to perform different actions. Each time a new activity starts, the previous activity is stopped, but the system preserves the activity in a stack (the "back stack"). When a new activity starts, it is pushed onto the back stack and -takes user focus. The back stack abides to the basic "last in, first out" queue mechanism, +takes user focus. The back stack abides to the basic "last in, first out" stack mechanism, so, when the user is done with the current activity and presses the Back button, it is popped from the stack (and destroyed) and the previous activity resumes. (The back stack is discussed more in the Tasks diff --git a/docs/html/guide/topics/fundamentals/fragments.jd b/docs/html/guide/topics/fundamentals/fragments.jd index d4f9342dd632f..e0740aac44701 100644 --- a/docs/html/guide/topics/fundamentals/fragments.jd +++ b/docs/html/guide/topics/fundamentals/fragments.jd @@ -129,7 +129,7 @@ handset design.

    For example—to continue with the news application example—the application can embed two fragments in Activity A, when running on a tablet-sized device. However, on a -handset-sized screen, there's not be enough room for both fragments, so Activity A includes +handset-sized screen, there's not enough room for both fragments, so Activity A includes only the fragment for the list of articles, and when the user selects an article, it starts Activity B, which includes the second fragment to read the article. Thus, the application supports both tablets and handsets by reusing fragments in different combinations, as illustrated in diff --git a/docs/html/guide/topics/wireless/bluetooth.jd b/docs/html/guide/topics/wireless/bluetooth.jd index 76da08eebe4b0..0567799565e2d 100644 --- a/docs/html/guide/topics/wireless/bluetooth.jd +++ b/docs/html/guide/topics/wireless/bluetooth.jd @@ -249,12 +249,20 @@ if (!mBluetoothAdapter.isEnabled()) {

    A dialog will appear requesting user permission to enable Bluetooth, as shown in Figure 1. If the user responds "Yes," the system will begin to enable Bluetooth and focus will return to your application once the process completes (or fails).

    -

    If enabling Bluetooth succeeds, your Activity will receive the {@link + +

    The {@code REQUEST_ENABLE_BT} constant passed to {@link +android.app.Activity#startActivityForResult(Intent,int) startActivityForResult()} is a locally +defined integer (which must be greater than 0), that the system passes back to you in your +{@link +android.app.Activity#onActivityResult(int,int,Intent) onActivityResult()} implementation as the +requestCode parameter.

    + +

    If enabling Bluetooth succeeds, your activity receives the {@link android.app.Activity#RESULT_OK} result code in the {@link android.app.Activity#onActivityResult(int,int,Intent) onActivityResult()} callback. If Bluetooth was not enabled -due to an error (or the user responded "No") then the result code will be {@link -android.app.Activity#RESULT_CANCELED}.

    +due to an error (or the user responded "No") then the result code is {@link +android.app.Activity#RESULT_CANCELED}.

    @@ -431,11 +439,11 @@ startActivity(discoverableIntent);

    A dialog will be displayed, requesting user permission to make the device discoverable, as shown in Figure 2. If the user responds "Yes," then the device -will become discoverable for the specified amount of time. Your Activity will +will become discoverable for the specified amount of time. Your activity will then receive a call to the {@link android.app.Activity#onActivityResult(int,int,Intent) onActivityResult())} callback, with the result code equal to the duration that the device is discoverable. If the user responded "No" or if an error occurred, the result code will -be Activity.RESULT_CANCELLED.

    +be {@link android.app.Activity#RESULT_CANCELED}.

    Note: If Bluetooth has not been enabled on the device, then enabling device discoverability will automatically enable Bluetooth.

    @@ -568,7 +576,7 @@ socket.

    The {@link android.bluetooth.BluetoothServerSocket#accept()} call should not -be executed in the main Activity UI thread because it is a blocking call and +be executed in the main activity UI thread because it is a blocking call and will prevent any other interaction with the application. It usually makes sense to do all work with a {@link android.bluetooth.BluetoothServerSocket} or {@link android.bluetooth.BluetoothSocket} in a new @@ -696,7 +704,7 @@ android.bluetooth.BluetoothSocket#connect()} method times out (after about 12 seconds), then it will throw an exception.

    Because {@link android.bluetooth.BluetoothSocket#connect()} is a blocking call, this connection -procedure should always be performed in a thread separate from the main Activity +procedure should always be performed in a thread separate from the main activity thread.

    Note: You should always ensure that the device is not performing device discovery when you call {@link @@ -838,7 +846,7 @@ private class ConnectedThread extends Thread { try { // Read from the InputStream bytes = mmInStream.read(buffer); - // Send the obtained bytes to the UI Activity + // Send the obtained bytes to the UI activity mHandler.obtainMessage(MESSAGE_READ, bytes, -1, buffer) .sendToTarget(); } catch (IOException e) { @@ -847,14 +855,14 @@ private class ConnectedThread extends Thread { } } - /* Call this from the main Activity to send data to the remote device */ + /* Call this from the main activity to send data to the remote device */ public void write(byte[] bytes) { try { mmOutStream.write(bytes); } catch (IOException e) { } } - /* Call this from the main Activity to shutdown the connection */ + /* Call this from the main activity to shutdown the connection */ public void cancel() { try { mmSocket.close(); @@ -866,12 +874,12 @@ private class ConnectedThread extends Thread {

    The constructor acquires the necessary streams and once executed, the thread will wait for data to come through the InputStream. When {@link java.io.InputStream#read(byte[])} returns with -bytes from the stream, the data is sent to the main Activity using a member +bytes from the stream, the data is sent to the main activity using a member Handler from the parent class. Then it goes back and waits for more bytes from the stream.

    Sending outgoing data is as simple as calling the thread's -write() method from the main Activity and passing in the bytes to +write() method from the main activity and passing in the bytes to be sent. This method then simply calls {@link java.io.OutputStream#write(byte[])} to send the data to the remote device.

    diff --git a/docs/html/resources/tutorials/notepad/notepad-ex2.jd b/docs/html/resources/tutorials/notepad/notepad-ex2.jd index ed0677862a90b..1334d7af85926 100644 --- a/docs/html/resources/tutorials/notepad/notepad-ex2.jd +++ b/docs/html/resources/tutorials/notepad/notepad-ex2.jd @@ -87,7 +87,7 @@ Open the Notepadv2 class.

    menu callback used for the options menu. Here, we add just one line, which will add a menu item to delete a note. Call menu.add() like so: 
    -public void onCreateContextMenu(Menu menu, View v, ContextMenuInfo menuInfo) {
+public void onCreateContextMenu(ContextMenu menu, View v, ContextMenuInfo menuInfo) {
     super.onCreateContextMenu(menu, v, menuInfo);
     menu.add(0, DELETE_ID, 0, R.string.menu_delete);
 }
    diff --git a/docs/html/resources/tutorials/views/hello-formstuff.jd b/docs/html/resources/tutorials/views/hello-formstuff.jd index b9f6c16dd7499..1ddd1df7fe844 100644 --- a/docs/html/resources/tutorials/views/hello-formstuff.jd +++ b/docs/html/resources/tutorials/views/hello-formstuff.jd @@ -91,31 +91,30 @@ android.widget.Button} element: android:layout_width="wrap_content" android:layout_height="wrap_content" android:padding="10dp" - android:background="@drawable/android_button" /> + android:background="@drawable/android_button" + android:onClick="onButtonClicked"/>

    The android:background attribute specifies the drawable resource to use for the button background (which, when saved at res/drawable/android.xml, is referenced as @drawable/android). This replaces the normal background image -used for buttons throughout the system. In order for the drawable to change its image based on -the button state, the image must be applied to the background.

    +applied by the system with the drawable created above, which changes its image based on +the button state.

    +

    The attribute android:onClick specifies the name of a method in your activity +that the system should call when the user clicks the button. You'll create that method next.

  • To make the button do something when pressed, add the following -code at the end of the {@link android.app.Activity#onCreate(Bundle) onCreate()} method: +method inside your {@link android.app.Activity} class: 
    -final Button button = (Button) findViewById(R.id.button);
-button.setOnClickListener(new OnClickListener() {
-    public void onClick(View v) {
-        // Perform action on clicks
-        Toast.makeText(HelloFormStuff.this, "Beep Bop", Toast.LENGTH_SHORT).show();
-    }
-});
+public void onButtonClicked(View v) {
+    // Do something when the button is clicked
+    Toast.makeText(HelloFormStuff.this, "Button clicked", Toast.LENGTH_SHORT).show();
+}
    -

    This captures the {@link android.widget.Button} from the layout, then adds an {@link -android.view.View.OnClickListener}. The {@link android.view.View.OnClickListener} -must implement the {@link android.view.View.OnClickListener#onClick(View)} callback method, which -defines the action to be made when the button is clicked. In this example, a -{@link android.widget.Toast} message will be displayed.

    +

    When you specify this kind of method, which is used in your layout file with the {@code +android:onClick} attribute, the method must be public, have a void return +value, and accept a single {@code android.view.View} parameter. When the system calls this method, +it passes the {@code android.view.View} that was clicked.

  • Now run the application.
    • @@ -183,34 +182,33 @@ element (inside the {@link android.widget.LinearLayout}): <CheckBox android:id="@+id/checkbox" android:layout_width="wrap_content" android:layout_height="wrap_content" - android:text="check it out" /> + android:text="check it out" + android:onClick="onCheckboxClicked"/> +

    The attribute android:onClick specifies the name of a method in your activity +that the system should call when the user clicks the check box. You'll create that method next.

    -
  • To do something when the state is changed, add the following code -to the end of the {@link android.app.Activity#onCreate(Bundle) onCreate()} method: +
  • To do something when the state is changed, add the following method inside your {@link +android.app.Activity} class:

    + 
    -final CheckBox checkbox = (CheckBox) findViewById(R.id.checkbox);
-checkbox.setOnClickListener(new OnClickListener() {
-    public void onClick(View v) {
-        // Perform action on clicks, depending on whether it's now checked
-        if (((CheckBox) v).isChecked()) {
-            Toast.makeText(HelloFormStuff.this, "Selected", Toast.LENGTH_SHORT).show();
-        } else {
-            Toast.makeText(HelloFormStuff.this, "Not selected", Toast.LENGTH_SHORT).show();
-        }
+public void onCheckboxClicked(View v) {
+    // Perform action on clicks, depending on whether it's now checked
+    if (((CheckBox) v).isChecked()) {
+        Toast.makeText(HelloFormStuff.this, "Selected", Toast.LENGTH_SHORT).show();
+    } else {
+        Toast.makeText(HelloFormStuff.this, "Not selected", Toast.LENGTH_SHORT).show();
     }
-});
+}
    -

    This captures the {@link android.widget.CheckBox} element from the layout, then adds an {@link -android.view.View.OnClickListener}. The {@link android.view.View.OnClickListener} must implement the -{@link android.view.View.OnClickListener#onClick(View)} callback method, which -defines the action to be made when the checkbox is clicked. When clicked, {@link -android.widget.CompoundButton#isChecked()} is called to check the new state of the check box. If it -has been checked, then a {@link android.widget.Toast} displays the message "Selected", otherwise it -displays "Not selected". Note that the {@link android.view.View} object that is passed in the {@link -android.view.View.OnClickListener#onClick(View)} callback must be cast to a {@link -android.widget.CheckBox} because the {@link android.widget.CompoundButton#isChecked()} method is -not defined by the parent {@link android.view.View} class. The {@link android.widget.CheckBox} + +

    When you specify this kind of method, which is used in your layout file with the {@code +android:onClick} +attribute, the method must be public, have a void return value, and +accept a single {@code android.view.View} parameter. When the system calls this method, it +passes the {@code android.view.View} that was clicked. In this example, the {@code +android.view.View} is cast to a {@link android.widget.CheckBox} to determine whether the widget +has been checked or unchecked. The {@link android.widget.CheckBox} widget handles its own state changes, so you only need to query the current state.

  • Run it.
    • @@ -240,44 +238,44 @@ android.widget.LinearLayout}): <RadioButton android:id="@+id/radio_red" android:layout_width="wrap_content" android:layout_height="wrap_content" - android:text="Red" /> + android:text="Red" + android:onClick="onRadioButtonClicked"/> <RadioButton android:id="@+id/radio_blue" android:layout_width="wrap_content" android:layout_height="wrap_content" - android:text="Blue" /> + android:text="Blue" + android:onClick="onRadioButtonClicked"/> </RadioGroup>

    It's important that the {@link android.widget.RadioButton}s are grouped together by the {@link android.widget.RadioGroup} element so that no more than one can be selected at a time. This logic is automatically handled by the Android system. When one {@link android.widget.RadioButton} within a group is selected, all others are automatically deselected.

    +

    The attribute android:onClick specifies the name of a method in your activity +that the system should call when the user clicks the radio button. You'll create that method +next.

    -
  • To do something when each {@link android.widget.RadioButton} is selected, you need an -{@link android.view.View.OnClickListener}. In this case, you want the listener to be re-usable, so -add the following code to create a new member in the HelloFormStuff Activity: +
  • To do something when each {@link android.widget.RadioButton} is selected, add the following +method inside your {@link android.app.Activity} class:

    + 
    -private OnClickListener radio_listener = new OnClickListener() {
-    public void onClick(View v) {
-        // Perform action on clicks
-        RadioButton rb = (RadioButton) v;
-        Toast.makeText(HelloFormStuff.this, rb.getText(), Toast.LENGTH_SHORT).show();
-    }
-};
+public void onRadioButtonClicked(View v) {
+    // Perform action on clicks
+    RadioButton rb = (RadioButton) v;
+    Toast.makeText(HelloFormStuff.this, rb.getText(), Toast.LENGTH_SHORT).show();
+}
    -

    First, the {@link android.view.View} that is passed to the {@link -android.view.View.OnClickListener#onClick(View)} method is cast into a RadioButton. Then a -{@link android.widget.Toast} message displays the selected radio button's text.

    -
  • Now, at the bottom of the {@link android.app.Activity#onCreate(Bundle) onCreate()} method, add -the following: -
    -  final RadioButton radio_red = (RadioButton) findViewById(R.id.radio_red);
-  final RadioButton radio_blue = (RadioButton) findViewById(R.id.radio_blue);
-  radio_red.setOnClickListener(radio_listener);
-  radio_blue.setOnClickListener(radio_listener);
-
    -

    This captures each of the {@link android.widget.RadioButton}s from the layout and adds the -newly-created {@link android.view.View.OnClickListener} to each.

    + +

    When you specify this kind of method, which is used in your layout file with the {@code +android:onClick} +attribute, the method must be public, have a void return value, and +accept a single {@code android.view.View} parameter. When the system calls this method, it +passes the {@code android.view.View} that was clicked.

    +

    Because each {@link android.widget.RadioButton} widget is grouped into a {@link +android.widget.RadioGroup}, each widget handles its own state changes when a new button is +selected.

    +
  • Run the application.
    • @@ -303,31 +301,35 @@ element (inside the {@link android.widget.LinearLayout}): android:layout_width="wrap_content" android:layout_height="wrap_content" android:textOn="Vibrate on" - android:textOff="Vibrate off"/> + android:textOff="Vibrate off" + android:onClick="onToggleClicked"/>

    The attributes android:textOn and android:textOff specify the text for the button when the button has been toggled on or off. The default values are "ON" and "OFF".

    +

    The attribute android:onClick specifies the name of a method in your activity +that the system should call when the user clicks the button. You'll create that method next.

    -
  • To do something when the state is changed, add the following code -to the end of the {@link android.app.Activity#onCreate(Bundle) onCreate()} method: +
  • To do something when the user clicks the button, add the following +method inside your {@link android.app.Activity} class:

    + 
    -final ToggleButton togglebutton = (ToggleButton) findViewById(R.id.togglebutton);
-togglebutton.setOnClickListener(new OnClickListener() {
-    public void onClick(View v) {
-        // Perform action on clicks
-        if (togglebutton.isChecked()) {
-            Toast.makeText(HelloFormStuff.this, "Checked", Toast.LENGTH_SHORT).show();
-        } else {
-            Toast.makeText(HelloFormStuff.this, "Not checked", Toast.LENGTH_SHORT).show();
-        }
+public void onToggleClicked(View v) {
+    // Perform action on clicks
+    if (((ToggleButton) v).isChecked()) {
+        Toast.makeText(HelloFormStuff.this, "Toggle on", Toast.LENGTH_SHORT).show();
+    } else {
+        Toast.makeText(HelloFormStuff.this, "Toggle off", Toast.LENGTH_SHORT).show();
     }
-});
+}
    -

    This captures the {@link android.widget.ToggleButton} element from the layout, then adds an -{@link android.view.View.OnClickListener}. The {@link android.view.View.OnClickListener} must -implement the {@link android.view.View.OnClickListener#onClick(View)} callback method, which -defines the action to perform when the button is clicked. In this example, the callback + +

    When you specify this kind of method, which is used in your layout file with the {@code +android:onClick} +attribute, the method must be public, have a void return value, and +accept a single {@code android.view.View} parameter. When the system calls this method, it +passes the {@code android.view.View} that was clicked.

    +

    In this example, the callback method checks the new state of the button, then shows a {@link android.widget.Toast} message that indicates the current state.

    diff --git a/docs/html/resources/tutorials/views/hello-mapview.jd b/docs/html/resources/tutorials/views/hello-mapview.jd index ac5e826e41c2e..7a0bedf5dd699 100644 --- a/docs/html/resources/tutorials/views/hello-mapview.jd +++ b/docs/html/resources/tutorials/views/hello-mapview.jd @@ -208,7 +208,7 @@ public int size() { new class constructor: 
     public HelloItemizedOverlay(Drawable defaultMarker, Context context) {
-  super(defaultMarker);
+  super(boundCenterBottom(defaultMarker));
   mContext = context;
 }
    From 837a5d83f592db503da03d94632f125414d77aba Mon Sep 17 00:00:00 2001 From: Scott Main Date: Mon, 5 Mar 2012 10:56:39 -0800 Subject: [PATCH 03/17] docs: updates to OBB guide for naming; plus other edits Change-Id: I0a3afa0388f89d7464471917fec7d767748a870e --- docs/html/guide/market/expansion-files.jd | 166 ++++++++++++---------- 1 file changed, 87 insertions(+), 79 deletions(-) diff --git a/docs/html/guide/market/expansion-files.jd b/docs/html/guide/market/expansion-files.jd index 09f1d2e090671..5aaf9f1607480 100644 --- a/docs/html/guide/market/expansion-files.jd +++ b/docs/html/guide/market/expansion-files.jd @@ -25,8 +25,8 @@ page.title=APK Expansion Files
  • Rules and Limitations
  • Downloading the Expansion Files
      -
    1. About the Expansion Downloader Library
      2. -
    2. Preparing to use the Expansion Downloader Library
      3. +
    3. About the Downloader Library
      4. +
    4. Preparing to use the Downloader Library
    5. Declaring user permissions
    6. Implementing the downloader service
    7. Implementing the alarm receiver
      8. @@ -91,15 +91,19 @@ Conceptually, each expansion file plays a different role:

    8. The main expansion file is the primary expansion file for additional resources required by your application.
    9. The patch expansion file is optional and intended for small updates to the -main expansion file. Using the patch file allows you to deliver updates without requiring that the -user re-download the main expansion again. Thus, the patch expansion -contains only the updates to the expansion file data. -

      However, even if your application update requires only a new patch expansion file, you must +main expansion file.

      10. + + +

      While you can use the two expansion files any way you wish, we recommend that the main +expansion file deliver the primary assets and should rarely if ever updated; the patch expansion +file should be smaller and serve as a “patch carrier,” getting updated with each major +release or as necessary.

      + +

      However, even if your application update requires only a new patch expansion file, you still must upload a new APK with an updated {@code versionCode} in the manifest. (The Android Market -Developer Console does not allow you to upload an expansion file to an existing APK.)

      - +Developer Console does not allow you to upload an expansion file to an existing APK.)

      Note: The patch expansion file is semantically the same as the main expansion file—you can use each file any way you want. The system does @@ -160,12 +164,6 @@ itself, you must save the files to the exact same location.

    10. {@code <package-name>} is your application's Java-style package name, available from {@link android.content.Context#getPackageName()}.
      11. -

      - -

      Note: The location of the shared storage may be -different on different devices, so you should never refer to the shared storage space using an -absolute URI path. Always use {@link android.os.Environment#getExternalStorageDirectory} to -retrieve the root directory of the shared storage location.

      For each application, there are never more than two expansion files in this directory. One is the main expansion file and the other is the patch expansion file (if necessary). Previous @@ -180,7 +178,10 @@ the file instead of requiring you to unpack the data. For example, we've provide project called the APK Expansion Zip Library that reads your data directly from the ZIP file.

      -

      Note: If you're packaging media files into a ZIP, you can use media +

      Note: Unlike APK files, any files saved on the shared storage can +be read by the user and other applications.

      + +

      Tip: If you're packaging media files into a ZIP, you can use media playback calls on the files with offset and length controls (such as {@link android.media.MediaPlayer#setDataSource(FileDescriptor,long,long) MediaPlayer.setDataSource()} and {@link android.media.SoundPool#load(FileDescriptor,long,long,int) SoundPool.load()}) without the @@ -261,7 +262,7 @@ are on the device upon start-up. If the files are not on the device, use Android href="{@docRoot}guide/market/licensing/index.html">Application Licensing service to request URLs for the expansion files, then download and save them.

      To greatly reduce the amount of code you must write and ensure a good user experience -during the download, we recommend you use the Expansion Downloader +during the download, we recommend you use the Downloader Library to implement your download behavior.

      If you build your own download service instead of using the library, be aware that you must not change the name of the expansion files and must save them to the proper @@ -344,7 +345,8 @@ href="#StorageLocation">shared storage location (in the

    11. If the expansion files are there, you're all set and your application can continue.
    12. If the expansion files are not there:
        -
      1. Perform a request using the License Verification Library to get your +
      2. Perform a request using Android Market's Application Licensing to get your app's expansion file names, sizes, and URLs.
      3. Use the URLs provided by Android Market to download the expansion files and save the expansion files. You must save the files to the

        Note: Whether your application is free or not, Android Market returns the expansion file URLs only if the user acquired your application from Android Market.

        -

        To simplify this work for you, we've built the Expansion Downloader -Library, which requests the expansion file URLs through the licensing service and -downloads the expansion files for you. By adding this library and a few code hooks to your -application, almost all the work to download the expansion files is already coded for you, including -a status notification that tracks the download progress. As such, in order to provide the best user -experience with minimal effort on your behalf, we recommend you use the -Expansion Downloader Library to download your expansion files. The information in the following -sections explain how to integrate the library into your application.

        - -

        If you'd rather develop your own solution to download the expansion files using the Android -Market URLs, you must follow the Application -Licensing documentation to perform a license request, then retrieve the expansion file names, -sizes, and URLs from the response extras. You should use the {@code -APKExpansionPolicy} class (included in the License Verification Library) as your licensing -policy, which captures the expansion file names, sizes, and URLs from the licensing service..

        - - - -

        About the Expansion Downloader Library

        - -

        To use APK expansion files with your application and provide the best user experience with -minimal effort on your behalf, we recommend you use the Android Market Expansion Downloader -Library.

        - -

        As mentioned above, in order to use expansion files hosted by Android Market, you must use -the Android Market License Verification Library (LVL) to request the URLs from which to download the -expansion files. In addition to the LVL, you need a set of code that downloads the expansion files +

        In addition to the LVL, you need a set of code that downloads the expansion files over an HTTP connection and saves them to the proper location on the device's shared storage. As you build this procedure into your application, there are several issues you should take into consideration:

        @@ -422,9 +398,34 @@ indicates the download progress, notifies the user when it's done, and takes the your application when selected.
        4. -

        Fortunately, the Android Market Expansion Downloader Library handles all of this work for you -and also allows your app to pause and resume the download. To implement expansion file downloads -using the library, all you need to do is:

        + +

        To simplify this work for you, we've built the Downloader Library, +which requests the expansion file URLs through the licensing service, downloads the expansion files, +performs all of the tasks listed above, and even allows your activity to pause and resume the +download. By adding the Downloader Library and a few code hooks to your application, almost all the +work to download the expansion files is already coded for you. As such, in order to provide the best +user experience with minimal effort on your behalf, we recommend you use the Downloader Library to +download your expansion files. The information in the following sections explain how to integrate +the library into your application.

        + +

        If you'd rather develop your own solution to download the expansion files using the Android +Market URLs, you must follow the Application +Licensing documentation to perform a license request, then retrieve the expansion file names, +sizes, and URLs from the response extras. You should use the {@code +APKExpansionPolicy} class (included in the License Verification Library) as your licensing +policy, which captures the expansion file names, sizes, and URLs from the licensing service..

        + + + +

        About the Downloader Library

        + +

        To use APK expansion files with your application and provide the best user experience with +minimal effort on your behalf, we recommend you use the Downloader Library that's included in the +Android Market APK Expansion Library package. This library downloads your expansion files in a +background service, shows a user notification with the download status, handles network +connectivity loss, resumes the download when possible, and more.

        + +

        To implement expansion file downloads using the Downloader Library, all you need to do is:

        • Extend a special {@link android.app.Service} subclass and {@link @@ -437,36 +438,39 @@ progress UI.
          • receives updates about the download progress.
        +

        The following sections explain how to set up your app using the Downloader Library.

        -

        Preparing to use the Expansion Downloader Library

        +

        Preparing to use the Downloader Library

        -

        To use the Expansion Downloader Library, you need to +

        To use the Downloader Library, you need to download two packages from the SDK Manager and add the appropriate libraries to your application.

        First, open the Android SDK Manager, expand Extras and download:

        • Google Market Licensing package
          • -
        • Google Market Expansion Downloader package
          • +
        • Google Market APK Expansion Library package

        If you're using Eclipse, create a project for each library and add it to your app:

          -
        1. Create a new Library Project for the License Verification Library and Expansion Downloader +
        2. Create a new Library Project for the License Verification Library and Downloader Library. For each library:
          1. Begin a new Android project.
          2. Select Create project from existing -source and choose the library from the {@code <sdk>/extras/google/} directory.
            3. +source and choose the library from the {@code <sdk>/extras/google/} directory +({@code market_licensing/} for the License Verification Library or {@code +market_apk_expansion/downloader_library/} for the Downloader Library).
          3. Specify a Project Name such as "Android Market License Library" and "Market Downloader Library"
          4. Click Finish.
          -

          Note: The Expansion Downloader Library depends on the License +

          Note: The Downloader Library depends on the License Verification Library. Be sure to add the License -Verification Library to the Expansion Downloader Library's project properties (same process as +Verification Library to the Downloader Library's project properties (same process as steps 2 and 3 below).

        3. Right-click the Android project in which you want to use APK expansion files and @@ -483,29 +487,31 @@ LVL and the Downloader Library to your project. For example: 
           android update project --path ~/Android/MyApp \
 --library ~/android_sdk/extras/google/market_licensing \
---library ~/android_sdk/extras/google/market_downloader
+--library ~/android_sdk/extras/google/market_apk_expansion/downloader_library
        -

        With both the License Verification Library and Expansion Downloader Library added to your +

        With both the License Verification Library and Downloader Library added to your application, you'll be able to quickly integrate the ability to download expansion files from Android Market. The format that you choose for the expansion files and how you read them from the shared storage is a separate implementation that you should consider based on your application needs.

        -

        Tip: The Expansion Downloader package includes a sample application -that shows how to use the Expansion Downloader library in an app. The sample uses a third library -available in the Expansion Downloader package called the APK Expansion Zip Library. If you plan on +

        Tip: The APK Expansion Library package includes a sample +application +that shows how to use the Downloader Library in an app. The sample uses a third library +available in the APK Expansion Library package called the APK Expansion Zip Library. If +you plan on using ZIP files for your expansion files, we suggest you also add the APK Expansion Zip Library to -your application. You might want to use the sample application as a starting point for your -implementation.

        +your application. For more information, see the section below +about Using the APK Expansion Zip Library.

        Declaring user permissions

        -

        In order to download the expansion files, the Expansion Downloader Library +

        In order to download the expansion files, the Downloader Library requires several permissions that you must declare in your application's manifest file. They are:

        @@ -532,13 +538,13 @@ are:

        </manifest> -

        Note: By default, the Expansion Downloader Library requires API +

        Note: By default, the Downloader Library requires API level 4, but the APK Expansion Zip Library requires API level 5.

        Implementing the downloader service

        -

        In order to perform downloads in the background, the Expansion Downloader Library provides its +

        In order to perform downloads in the background, the Downloader Library provides its own {@link android.app.Service} subclass called {@code DownloaderService} that you should extend. In addition to downloading the expansion files for you, the {@code DownloaderService} also:

        @@ -626,7 +632,7 @@ your downloads.

        {@code DownloaderService} schedules an {@link android.app.AlarmManager#RTC_WAKEUP} alarm that delivers an {@link android.content.Intent} to a {@link android.content.BroadcastReceiver} in your application. You must define the {@link android.content.BroadcastReceiver} to call an API -from the Expansion Downloader Library that checks the status of the download and restarts +from the Downloader Library that checks the status of the download and restarts it if necessary.

        You simply need to override the {@link android.content.BroadcastReceiver#onReceive @@ -668,19 +674,19 @@ in your service's {@code getAlarmReceiverClassName()} method (see the previous s responsible for verifying whether the expansion files are already on the device and initiating the download if they are not.

        -

        Starting the download using the Expansion Downloader library requires the following +

        Starting the download using the Downloader Library requires the following procedures:

        1. Check whether the files have been downloaded. -

          The Expansion Downloader library includes some APIs in the {@code Helper} class to +

          The Downloader Library includes some APIs in the {@code Helper} class to help with this process:

          • {@code getExtendedAPKFileName(Context, c, boolean mainFile, int versionCode)}
          • {@code doesFileExist(Context c, String fileName, long fileSize)}
          -

          For example, the sample app provided in the Expansion Downloader package calls the +

          For example, the sample app provided in the APK Expansion Library package calls the following method in the activity's {@link android.app.Activity#onCreate onCreate()} method to check whether the expansion files already exist on the device:

          @@ -725,7 +731,7 @@ but have not been downloaded.
          2. same and you normally don't need to be concerned about them. In your main activity that calls {@code startDownloadServiceIfRequired()}, you can simply check whether or not the response is {@code NO_DOWNLOAD_REQUIRED}. If the response is anything other than {@code NO_DOWNLOAD_REQUIRED}, -the Expansion Downloader library begins the download and you should update your activity UI to +the Downloader Library begins the download and you should update your activity UI to display the download progress (see the next step). If the response is {@code NO_DOWNLOAD_REQUIRED}, then the files are available and your application can start.

          For example:

          @@ -855,7 +861,7 @@ download begins or completes. by one of the {@code IDownloaderClient} class's {@code STATE_*} constants.

          To provide a useful message to your users, you can request a corresponding string for each state by calling {@code Helpers.getDownloaderStringResourceIDFromState()}. This -returns the resource ID for one of the strings bundled with the Expansion Downloader +returns the resource ID for one of the strings bundled with the Downloader Library. For example, the string "Download paused because you are roaming" corresponds to {@code STATE_PAUSED_ROAMING}.

          {@code onDownloadProgress(DownloadProgressInfo progress)}
          @@ -892,14 +898,14 @@ mRemoteService.setDownloadFlags(IDownloaderService.FLAGS_DOWNLOAD_OVER_CELLULAR)

          Using APKExpansionPolicy

          If you decide to build your own downloader service instead of using the Android Market -Expansion Downloader Library, you should still use the {@code +Downloader Library, you should still use the {@code APKExpansionPolicy} that's provided in the License Verification Library. The {@code APKExpansionPolicy} class is nearly identical to {@code ServerManagedPolicy} (available in the Android Market License Verification Library) but includes additional handling for the APK expansion file response extras.

          Note: If you do use the Expansion Downloader Library as discussed in the previous section, the +href="#AboutLibraries">Downloader Library as discussed in the previous section, the library performs all interaction with the {@code APKExpansionPolicy} so you don't have to use this class directly.

          @@ -915,7 +921,7 @@ expansion files:

          For more information about how to use the {@code APKExpansionPolicy} when you're not using the Expansion Downloader Library, see the documentation for Downloader Library, see the documentation for Adding Licensing to Your App, which explains how to implement a license policy such as this one.

          @@ -1030,8 +1036,10 @@ option to specify the file suffixes that should not be compressed:

          -

          The Android Market Expansion Downloader package includes a library called the APK -Expansion Zip Library. This is an optional library that helps you read your expansion +

          The Android Market APK Expansion Library package includes a library called the APK +Expansion Zip Library (located in {@code +<sdk>/extras/google/google_market_apk_expansion/zip_file/}). This is an optional library that +helps you read your expansion files when they're saved as ZIP files. Using this library allows you to easily read resources from your ZIP expansion files as a virtual file system.

          @@ -1080,7 +1088,7 @@ android.content.ContentProvider} that marshals the data from the ZIP files throu provider {@link android.net.Uri} in order to provide file access for certain Android APIs that expect {@link android.net.Uri} access to media files.

          The sample application available in the -Expansion Downloader package demonstrates a scenario in which this class is useful +APK Expansion Library package demonstrates a scenario in which this class is useful to specify a video with {@link android.widget.VideoView#setVideoURI VideoView.setVideoURI()}. See the sample app's class {@code SampleZipfileProvider} for an example of how to extend this class to use in your application.

          @@ -1212,7 +1220,8 @@ the Android system nor Android Market perform actual patching between your main files. Your application code must perform any necessary patches itself.

          If you use ZIP files as your expansion files, the APK Expansion Zip -Library that's included with the Expansion Downloader package includes the ability to merge your +Library that's included with the APK Expansion Library package includes the ability to merge +your patch file with the main expansion file.

          Note: Even if you only need to make changes to the patch @@ -1234,14 +1243,13 @@ file and one patch expansion file. During an update to a file, Android Market de previous version (and so must your application when performing manual updates).

        2. When adding a patch expansion file, the Android system does not actually patch your application or main expansion file. You must design your application to support the patch data. -However, the Android Market Expansion Downloader package includes a library for using ZIP files +However, the APK Expansion Library package includes a library for using ZIP files as expansion files, which merges the data from the patch file into the main expansion file so you can easily read all the expansion file data.
          3. - 1058.1% + Android 2.3.7 1061.5% Android 3.0 Honeycomb 110.1% -Android 3.1121.4% -Android 3.2131.9% +Android 3.1121.1% +Android 3.2132.1% Android 4.0 -
          Android 4.0.2           - Ice Cream Sandwich140.3% -Android 4.0.3150.7% + Ice Cream Sandwich140.4% +Android 4.0.3151.2% -

          Data collected during a 14-day period ending on February 1, 2012

          +

          Data collected during a 14-day period ending on March 5, 2012

          @@ -108,9 +108,9 @@ Android Market within a 14-day period ending on the date indicated on the x-axis
          +src="http://chart.apis.google.com/chart?&cht=lc&chs=660x250&chxt=x,x,y,r&chxr=0,0,12|1,0,12|2,0,100|3,0,100&chxl=0%3A%7C09/01%7C09/15%7C10/01%7C10/15%7C11/01%7C11/15%7C12/01%7C12/15%7C01/01%7C01/15%7C02/01%7C02/15%7C03/01%7C1%3A%7C2011%7C%7C%7C%7C%7C%7C%7C%7C2012%7C%7C%7C%7C2012%7C2%3A%7C0%25%7C25%25%7C50%25%7C75%25%7C100%25%7C3%3A%7C0%25%7C25%25%7C50%25%7C75%25%7C100%25&chxp=0,0,1,2,3,4,5,6,7,8,9,10,11,12&chxtc=0,5&chd=t:97.9,97.9,97.7,97.6,97.5,99.4,99.4,99.2,98.9,98.8,99.2,98.9,98.9|96.9,96.9,96.6,96.6,96.5,98.6,98.6,98.5,98.3,98.2,98.6,98.4,98.4|95.1,95.2,95.1,95.4,95.2,97.2,97.3,97.3,97.2,97.2,97.6,97.5,97.6|81.8,82.7,83.3,84.4,84.6,87.0,87.7,88.1,88.7,89.2,89.9,90.3,90.8|30.6,34.1,37.8,40.8,43.5,48.4,52.4,55.2,58.2,60.1,62.0,63.7,65.2|0.0,0.0,0.0,0.0,0.0,2.0,2.3,2.6,3.5,3.6,4.0,4.1,4.3|0.0,0.0,0.0,0.0,0.0,1.0,1.2,1.3,2.0,2.2,2.6,3.0,3.2|0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.3,0.4,0.7,0.8,1.1&chm=b,c3df9b,0,1,0|b,b8dc82,1,2,0|tAndroid%202.1,608920,2,0,15,,t::-5|b,addb67,2,3,0|tAndroid%202.2,517617,3,0,15,,t::-5|b,a3db4b,3,4,0|tAndroid%202.3.3,426210,4,0,15,,t::-5|b,98dc2e,4,5,0|b,8cd41b,5,6,0|b,7ec113,6,7,0|B,6fad0c,7,8,0&chg=7,25&chdl=Android%201.5|Android%201.6|Android%202.1|Android%202.2|Android%202.3.3|Android%203.1|Android%203.2|Android%204.0.3&chco=add274,a2d15a,97d13e,8bcb28,7dba1e,6ea715,5f920e,507d08" /> -

          Last historical dataset collected during a 14-day period ending on February 1, 2012

          +

          Last historical dataset collected during a 14-day period ending on March 5, 2012

          diff --git a/docs/html/resources/dashboard/screens.jd b/docs/html/resources/dashboard/screens.jd index ae5cdc7359150..6c04f7e3af4a7 100644 --- a/docs/html/resources/dashboard/screens.jd +++ b/docs/html/resources/dashboard/screens.jd @@ -60,7 +60,7 @@ ending on the data collection date noted below.

          +src="http://chart.googleapis.com/chart?cht=p&chs=400x250&chco=c4df9b,6fad0c&chl=Xlarge%20/%20mdpi|Large%20/%20ldpi|Large%20/%20mdpi|Normal%20/%20hdpi|Normal%20/%20ldpi|Normal%20/%20mdpi|Normal%20/%20xhdpi|Small%20/%20hdpi|Small%20/%20ldpi&chd=t%3A4.9,0.2,2.8,66.4,0.7,18.5,2.5,2.4,1.7" /> @@ -71,31 +71,31 @@ src="http://chart.googleapis.com/chart?cht=p&chs=400x250&chco=c4df9b,6fad0c&chl= - + - + - - - + + + - + - +
          xhdpi
          small1.6% 1.7% 2.5% 2.4%
          normal 0.7% 18.4% 67.1% 1.8% 18.5% 66.3% 2.5%
          large 0.2% 2.9% 2.8%
          xlarge 4.8% 4.9%
          -

          Data collected during a 7-day period ending on February 1, 2012

          +

          Data collected during a 7-day period ending on March 4, 2012

          From 290684ac2eadf786d2f478d3d280eb3058627789 Mon Sep 17 00:00:00 2001 From: Scott Main Date: Mon, 5 Mar 2012 17:35:36 -0800 Subject: [PATCH 06/17] docs: fix expansion library package name Change-Id: I38303b5650fd924ac25281baf4a7da51aa939394 --- docs/html/guide/market/expansion-files.jd | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/docs/html/guide/market/expansion-files.jd b/docs/html/guide/market/expansion-files.jd index cd9b57aa9ecbb..fad30e9a27d29 100644 --- a/docs/html/guide/market/expansion-files.jd +++ b/docs/html/guide/market/expansion-files.jd @@ -421,7 +421,7 @@ policy, which captures the expansion file names, sizes, and URLs from the licens

          To use APK expansion files with your application and provide the best user experience with minimal effort on your behalf, we recommend you use the Downloader Library that's included in the -Android Market APK Expansion Library package. This library downloads your expansion files in a +Google Market Apk Expansion package. This library downloads your expansion files in a background service, shows a user notification with the download status, handles network connectivity loss, resumes the download when possible, and more.

          @@ -447,10 +447,11 @@ receives updates about the download progress. download two packages from the SDK Manager and add the appropriate libraries to your application.

          -

          First, open the Android SDK Manager, expand Extras and download:

          +

          First, open the Android SDK Manager, expand +Extras and download:

          • Google Market Licensing package
            • -
          • Google Market APK Expansion Library package
            • +
          • Google Market Apk Expansion package

          If you're using Eclipse, create a project for each library and add it to your app:

          @@ -498,10 +499,10 @@ Android Market. The format that you choose for the expansion files and how you r from the shared storage is a separate implementation that you should consider based on your application needs.

          -

          Tip: The APK Expansion Library package includes a sample +

          Tip: The Apk Expansion package includes a sample application that shows how to use the Downloader Library in an app. The sample uses a third library -available in the APK Expansion Library package called the APK Expansion Zip Library. If +available in the Apk Expansion package called the APK Expansion Zip Library. If you plan on using ZIP files for your expansion files, we suggest you also add the APK Expansion Zip Library to your application. For more information, see the section below @@ -686,7 +687,7 @@ help with this process:

          versionCode)}
        3. {@code doesFileExist(Context c, String fileName, long fileSize)}
          4. -

          For example, the sample app provided in the APK Expansion Library package calls the +

          For example, the sample app provided in the Apk Expansion package calls the following method in the activity's {@link android.app.Activity#onCreate onCreate()} method to check whether the expansion files already exist on the device:

          @@ -872,7 +873,7 @@ current speed, overall progress, and total so you can update the download progre
 
 
          Tip: For examples of these callbacks that update the download
 progress UI, see the {@code SampleDownloaderActivity} in the sample app provided with the
-APK Expansion Library package.
          
+Apk Expansion package.
          
 
 
          Some public methods for the {@code IDownloaderService} interface you might find useful are:
          
 
@@ -1037,7 +1038,7 @@ option to specify the file suffixes that should not be compressed:
          
 
 
 
-
          The Android Market APK Expansion Library package includes a library called the APK
+
          The Google Market Apk Expansion package includes a library called the APK
 Expansion Zip Library (located in {@code
 <sdk>/extras/google/google_market_apk_expansion/zip_file/}). This is an optional library that
 helps you read your expansion
@@ -1089,7 +1090,7 @@ android.content.ContentProvider} that marshals the data from the ZIP files throu
 provider {@link android.net.Uri} in order to provide file access for certain Android APIs that
 expect {@link android.net.Uri} access to media files.
       
          The sample application available in the
-APK Expansion Library package demonstrates a scenario in which this class is useful
+Apk Expansion package demonstrates a scenario in which this class is useful
 to specify a video with {@link android.widget.VideoView#setVideoURI
 VideoView.setVideoURI()}. See the sample app's class {@code SampleZipfileProvider} for an
 example of how to extend this class to use in your application.
          
@@ -1226,7 +1227,7 @@ the Android system nor Android Market perform actual patching between your main
 files. Your application code must perform any necessary patches itself.
          
 
 
          If you use ZIP files as your expansion files, the APK Expansion Zip
-Library that's included with the APK Expansion Library package includes the ability to merge
+Library that's included with the Apk Expansion package includes the ability to merge
 your
 patch file with the main expansion file.
          
 
@@ -1249,7 +1250,7 @@ file and one patch expansion file. During an update to a file, Android Market de
 previous version (and so must your application when performing manual updates).
   
        4. When adding a patch expansion file, the Android system does not actually patch your
 application or main expansion file. You must design your application to support the patch data.
-However, the APK Expansion Library package includes a library for using ZIP files
+However, the Apk Expansion package includes a library for using ZIP files
 as expansion files, which merges the data from the patch file into the main expansion file so
 you can easily read all the expansion file data.
          5. 
 

From e606cb460272cd99bac05b4477a5e489827b368b Mon Sep 17 00:00:00 2001
From: Scott Main 
Date: Mon, 5 Mar 2012 20:14:16 -0800
Subject: [PATCH 07/17] docs: fix api dashboard

Change-Id: Ifbd596860f3368811e31494176682571be919459
---
 docs/html/resources/dashboard/platform-versions.jd | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/html/resources/dashboard/platform-versions.jd b/docs/html/resources/dashboard/platform-versions.jd
index 9631059ada71a..acb8472e88650 100644
--- a/docs/html/resources/dashboard/platform-versions.jd
+++ b/docs/html/resources/dashboard/platform-versions.jd
@@ -52,7 +52,7 @@ Android Market within a 14-day period ending on the data collection date noted b
 
          
 
 
+src="http://chart.apis.google.com/chart?&cht=p&chs=460x250&chd=t:0.4,0.8,6.6,25.2,0.5,61.4,0.1,1.1,2.1,0.4,1.2&chl=Android%201.5|Android%201.6|Android%202.1|Android%202.2|Android%202.3|Android%202.3.3|Android%203.0|Android%203.1|Android%203.2|Android%204.0|Android%204.0.3&chco=c4df9b,6fad0c" />
 
 

From 4d7bc65538c7cd9fbb1fbbcf22d1da47fcee1219 Mon Sep 17 00:00:00 2001
From: Dirk Dougherty 
Date: Fri, 27 Jan 2012 17:56:49 -0800
Subject: [PATCH 08/17] Doc change: String changes for Android Market

Change-Id: I823812a4fd24021bec906ad856479c92a8d2a759
---
 .../android/app/ApplicationErrorReport.java   |   2 +-
 core/java/android/content/Intent.java         |   2 +-
 core/java/android/nfc/NdefRecord.java         |   2 +-
 core/java/android/os/StrictMode.java          |   2 +-
 core/java/android/provider/Settings.java      |   4 +-
 .../html/design/building-blocks/progress.html |   2 +-
 docs/html/design/building-blocks/tabs.html    |   2 +-
 docs/html/design/patterns/actionbar.html      |   2 +-
 docs/html/design/patterns/app-structure.html  |   6 +-
 docs/html/design/patterns/navigation.html     |   8 +-
 docs/html/design/style/iconography.html       |   2 +-
 docs/html/guide/appendix/install-location.jd  |   6 +-
 docs/html/guide/appendix/market-filters.jd    | 148 +++++-----
 docs/html/guide/developing/building/index.jd  |   4 +-
 docs/html/guide/guide_toc.cs                  |  10 +-
 .../guide/market/billing/billing_admin.jd     |  62 ++---
 .../market/billing/billing_best_practices.jd  |   6 +-
 .../guide/market/billing/billing_integrate.jd | 174 ++++++------
 .../guide/market/billing/billing_overview.jd  | 120 ++++----
 .../guide/market/billing/billing_reference.jd |  56 ++--
 .../guide/market/billing/billing_testing.jd   |  60 ++--
 docs/html/guide/market/billing/index.jd       |  16 +-
 docs/html/guide/market/expansion-files.jd     | 126 ++++-----
 .../market/licensing/adding-licensing.jd      |  52 ++--
 docs/html/guide/market/licensing/index.jd     |  18 +-
 .../market/licensing/licensing-reference.jd   |  28 +-
 docs/html/guide/market/licensing/overview.jd  |  66 ++---
 .../html/guide/market/licensing/setting-up.jd |  62 ++---
 .../guide/market/publishing/multiple-apks.jd  |  72 ++---
 docs/html/guide/practices/compatibility.jd    |  42 +--
 .../guide/practices/design/accessibility.jd   |   7 +-
 .../guide/practices/optimizing-for-3.0.jd     |  14 +-
 .../guide/practices/screens-distribution.jd   |  14 +-
 docs/html/guide/practices/screens_support.jd  |   4 +-
 .../ui_guidelines/activity_task_design.jd     |   2 +-
 .../ui_guidelines/icon_design_launcher.jd     |  30 +-
 .../icon_design_launcher_archive.jd           |  12 +-
 docs/html/guide/publishing/app-signing.jd     |  10 +-
 docs/html/guide/publishing/preparing.jd       |  45 ++-
 docs/html/guide/publishing/publishing.jd      | 256 +++++++++---------
 .../guide/publishing/publishing_overview.jd   |  51 ++--
 docs/html/guide/publishing/versioning.jd      |   2 +-
 docs/html/guide/topics/admin/device-admin.jd  |   4 +-
 docs/html/guide/topics/data/backup.jd         |   4 +-
 docs/html/guide/topics/fundamentals.jd        |  10 +-
 docs/html/guide/topics/graphics/opengl.jd     |   8 +-
 .../guide/topics/manifest/activity-element.jd |   4 +-
 .../manifest/compatible-screens-element.jd    |  14 +-
 .../guide/topics/manifest/manifest-element.jd |   6 +-
 .../manifest/supports-gl-texture-element.jd   |  36 +--
 .../manifest/supports-screens-element.jd      |   6 +-
 .../topics/manifest/uses-feature-element.jd   | 122 ++++-----
 .../topics/manifest/uses-library-element.jd   |   8 +-
 .../manifest/uses-permission-element.jd       |  10 +-
 .../guide/topics/manifest/uses-sdk-element.jd |  16 +-
 docs/html/guide/topics/media/camera.jd        |  10 +-
 docs/html/guide/topics/network/sip.jd         |   2 +-
 docs/html/guide/topics/nfc/nfc.jd             |  10 +-
 .../guide/topics/resources/localization.jd    |   8 +-
 .../guide/topics/sensors/sensors_overview.jd  |   8 +-
 docs/html/guide/topics/ui/actionbar.jd        |   2 +-
 docs/html/index.jd                            |  10 +-
 docs/html/intl/ja/community/index.jd          |   2 +-
 docs/html/intl/ja/index.jd                    |   6 +-
 .../intl/ja/resources/community-groups.jd     |   2 +-
 .../articles/can-i-use-this-intent.jd         |   2 +-
 docs/html/resources/articles/contacts.jd      |  10 +-
 .../resources/articles/live-wallpapers.jd     |  12 +-
 docs/html/resources/articles/speech-input.jd  |   4 +-
 docs/html/resources/articles/tts.jd           |   2 +-
 docs/html/resources/articles/ui-1.6.jd        |   2 +-
 docs/html/resources/community-groups.jd       |   8 +-
 docs/html/resources/dashboard/opengl.jd       |   2 +-
 .../resources/dashboard/platform-versions.jd  |   4 +-
 docs/html/resources/dashboard/screens.jd      |   2 +-
 docs/html/sdk/android-1.6-highlights.jd       |  10 +-
 docs/html/sdk/android-2.1.jd                  |   2 +-
 docs/html/sdk/android-2.2-highlights.jd       |   2 +-
 docs/html/sdk/android-2.3.3.jd                |   2 +-
 docs/html/sdk/android-2.3.4.jd                |   2 +-
 docs/html/sdk/android-2.3.jd                  |   8 +-
 docs/html/sdk/android-3.0.jd                  |   2 +-
 docs/html/sdk/android-3.1.jd                  |  10 +-
 docs/html/sdk/android-3.2.jd                  |   8 +-
 docs/html/sdk/android-4.0-highlights.jd       |   4 +-
 docs/html/sdk/android-4.0.jd                  |   4 +-
 docs/html/sdk/ndk/index.jd                    |   4 +-
 docs/html/sdk/ndk/overview.jd                 |   2 +-
 docs/html/sdk/oem-usb.jd                      |   2 +-
 docs/html/training/camera/photobasics.jd      |   4 +-
 docs/html/training/camera/videobasics.jd      |   2 +-
 docs/html/training/id-auth/custom_auth.jd     |   2 +-
 docs/html/training/multiple-apks/api.jd       |  21 +-
 docs/html/training/multiple-apks/index.jd     |   6 +-
 docs/html/training/multiple-apks/multiple.jd  |  20 +-
 .../html/training/multiple-apks/screensize.jd |  20 +-
 docs/html/training/multiple-apks/texture.jd   |  14 +-
 docs/html/training/sharing/receive.jd         |   2 +-
 .../codecs/m4v_h263/dec/src/vop.cpp           |   2 +-
 99 files changed, 1059 insertions(+), 1061 deletions(-)

diff --git a/core/java/android/app/ApplicationErrorReport.java b/core/java/android/app/ApplicationErrorReport.java
index 588125d0cc922..ebf426190d092 100644
--- a/core/java/android/app/ApplicationErrorReport.java
+++ b/core/java/android/app/ApplicationErrorReport.java
@@ -98,7 +98,7 @@ public class ApplicationErrorReport implements Parcelable {
     /**
      * Package name of the application which installed the application this
      * report pertains to.
-     * This identifies which Market the application came from.
+     * This identifies which market the application came from.
      */
     public String installerPackageName;
 
diff --git a/core/java/android/content/Intent.java b/core/java/android/content/Intent.java
index e3b1f541d2113..34966bbdfd996 100644
--- a/core/java/android/content/Intent.java
+++ b/core/java/android/content/Intent.java
@@ -1136,7 +1136,7 @@ public class Intent implements Parcelable, Cloneable {
     /**
      * Activity Action: The user pressed the "Report" button in the crash/ANR dialog.
      * This intent is delivered to the package which installed the application, usually
-     * the Market.
+     * Google Play.
      * 
          Input: No data is specified. The bug report is passed in using
      * an {@link #EXTRA_BUG_REPORT} field.
      * 
          Output: Nothing.
diff --git a/core/java/android/nfc/NdefRecord.java b/core/java/android/nfc/NdefRecord.java
index 26571ff04bf15..0f1f0604b5e4f 100644
--- a/core/java/android/nfc/NdefRecord.java
+++ b/core/java/android/nfc/NdefRecord.java
@@ -364,7 +364,7 @@ public final class NdefRecord implements Parcelable {
      * Ice Cream Sandwich.
      * 
          
      * If none of the applications are installed on the device,
-     * a Market link will be opened to the first application.
+     * a Google Play link to the first application will be opened.
      * 
          
      * Note that Android application records do not overrule
      * applications that have called
diff --git a/core/java/android/os/StrictMode.java b/core/java/android/os/StrictMode.java
index 99f58a0b91997..43a4a6c1536f6 100644
--- a/core/java/android/os/StrictMode.java
+++ b/core/java/android/os/StrictMode.java
@@ -106,7 +106,7 @@ import java.util.concurrent.atomic.AtomicInteger;
  * effort mechanism.  Notably, disk or network access from JNI calls
  * won't necessarily trigger it.  Future versions of Android may catch
  * more (or fewer) operations, so you should never leave StrictMode
- * enabled in shipping applications on the Android Market.
+ * enabled in applications distributed on Google Play.
  */
 public final class StrictMode {
     private static final String TAG = "StrictMode";
diff --git a/core/java/android/provider/Settings.java b/core/java/android/provider/Settings.java
index 124325147615c..d7fab37ed6045 100644
--- a/core/java/android/provider/Settings.java
+++ b/core/java/android/provider/Settings.java
@@ -2593,10 +2593,10 @@ public final class Settings {
 
         /**
          * Whether the package installer should allow installation of apps downloaded from
-         * sources other than the Android Market (vending machine).
+         * sources other than Google Play.
          *
          * 1 = allow installing from other sources
-         * 0 = only allow installing from the Android Market
+         * 0 = only allow installing from Google Play
          */
         public static final String INSTALL_NON_MARKET_APPS = "install_non_market_apps";
 
diff --git a/docs/html/design/building-blocks/progress.html b/docs/html/design/building-blocks/progress.html
index 32183bc401e43..500ccb1921970 100644
--- a/docs/html/design/building-blocks/progress.html
+++ b/docs/html/design/building-blocks/progress.html
@@ -147,7 +147,7 @@ available space.
          
       
        5. Activity bar (shown with the Holo Dark theme)
          
         
          
 
-An indeterminate activity bar is used at the start of an application download because Market hasn't
+An indeterminate activity bar is used at the start of an application download because Google Play hasn't
 been able to contact the server yet, and it's not possible to determine how long it will take for
 the download to begin.
 
diff --git a/docs/html/design/building-blocks/tabs.html b/docs/html/design/building-blocks/tabs.html
index d4b0e5244b8d5..029e484e7a581 100644
--- a/docs/html/design/building-blocks/tabs.html
+++ b/docs/html/design/building-blocks/tabs.html
@@ -130,7 +130,7 @@ to the next/previous view, swipe left or right.
          
       
     
     
          
-      Scrolling tabs in Android Market.
+      Scrolling tabs on Google Play.
       
           
          
     
          
 
diff --git a/docs/html/design/patterns/actionbar.html b/docs/html/design/patterns/actionbar.html
index 1566d047f3be6..e93498e6b73ed 100644
--- a/docs/html/design/patterns/actionbar.html
+++ b/docs/html/design/patterns/actionbar.html
@@ -281,7 +281,7 @@ themselves.
          
       
     
     
          
-      Scrolling tabs in Android Market.
+      Scrolling tabs on Google Play.
       
           
          
     
          
 
diff --git a/docs/html/design/patterns/app-structure.html b/docs/html/design/patterns/app-structure.html
index 1b48280eaa017..678059495552c 100644
--- a/docs/html/design/patterns/app-structure.html
+++ b/docs/html/design/patterns/app-structure.html
@@ -112,7 +112,7 @@ Android Design - Application Structure
   single screen
          6. 
 
        6. Apps such as Phone whose main purpose is to switch between different activities without deeper
   navigation
          7. 
-
        7. Apps such as Gmail or Market that combine a broad set of data views with deep navigation
          8. 
+
        8. Apps such as Gmail and Google Play that combine a broad set of data views with deep navigation
          9. 
 
 
          Your app's structure depends largely on the content and tasks you want to surface for your users.
          
 
          General Structure
          
@@ -165,7 +165,7 @@ layouts that are visually engaging and appropriate for the data type and screen
 
     
     
          
-      Market's start screen primarily allows navigation into the stores for Apps, Music, Books,
+      The Google Play app's start screen primarily allows navigation into the stores for Apps, Music, Books,
       Movies and Games. It is also enriched with tailored recommendations and promotions that
       surface content of interest to the user. Search is readily available from the action bar.
     
          
@@ -250,7 +250,7 @@ minimize navigational effort. Rule of thumb: no more than 5–7 tabs.
          
 
     
     
          
-      Market uses tabs to simultaneously show category choice and content. To navigate between
+      Google Play uses tabs to simultaneously show category choice and content. To navigate between
       categories, users can swipe left/right on the content.
     
          
 
diff --git a/docs/html/design/patterns/navigation.html b/docs/html/design/patterns/navigation.html
index 6287b5ec56f2b..5d1568e971118 100644
--- a/docs/html/design/patterns/navigation.html
+++ b/docs/html/design/patterns/navigation.html
@@ -167,7 +167,7 @@ navigation does not change the behavior of Up or Back.
          
 
 
 
          However, a notable exception to this occurs when browsing between "related" detail views not tied
-together by the referring list—for example, when browsing in the Market between apps from
+together by the referring list—for example, when browsing on Google Play between apps from
 the same developer, or albums by the same artist. In these cases, following each link does create
 history, causing the Back button to step through each screen of related content which has been
 viewed. Up should continue to bypass these related screens and navigate to the most recently viewed
@@ -176,7 +176,7 @@ container screen.
          
 
 
 
          You have the ability to make the Up behavior even smarter based on your knowledge of detail
-view. If we extend our Market sample from above, imagine the user has navigated from the last Book
+view. If we extend our Google Play sample from above, imagine the user has navigated from the last Book
 viewed to the details for the Movie adaptation. In that case, Up can return to a container (Movies)
 which the user had not previously navigated through.
          
 
@@ -200,10 +200,10 @@ return to the referring app.
          
 - If the destination screen is typically reached from one particular screen within your app, Up
   should navigate to that screen.
 - Otherwise, Up should navigate to the topmost ("Home") screen of your app.
          
-
          For example, after choosing to share a book being viewed in Market, the user navigates directly to
+
          For example, after choosing to share a book being viewed on Google Play, the user navigates directly to
 Gmail's compose screen. From there, Up returns to the Inbox (which happens to be both the
 typical referrer to compose, as well as the topmost screen of the app), while Back returns to
-Market.
          
+Google Play.
          
 
 
 
diff --git a/docs/html/design/style/iconography.html b/docs/html/design/style/iconography.html
index 96954de80a09a..0b2852e95cb18 100644
--- a/docs/html/design/style/iconography.html
+++ b/docs/html/design/style/iconography.html
@@ -146,7 +146,7 @@ any type of background.
          
       
        9. 
         
          Launcher icons on a mobile device must be 48x48 dp.
          10. 
       
        10. 
-        
          Launcher icons for display in Market must be 512x512 pixels.
          11. 
+        
          Launcher icons for display on Google Play must be 512x512 pixels.
          
     
 
   
diff --git a/docs/html/guide/appendix/install-location.jd b/docs/html/guide/appendix/install-location.jd
index e5ed226322d5e..63a3817e7c9f9 100644
--- a/docs/html/guide/appendix/install-location.jd
+++ b/docs/html/guide/appendix/install-location.jd
@@ -172,9 +172,9 @@ persist after external storage is remounted.
 before the external storage is mounted to the device. If your application is installed on the
 external storage, it can never receive this broadcast.
   
          Copy Protection
          
-    
          Your application cannot be installed to a device's SD card if it uses Android Market's 
-      Copy Protection feature. However, if you use Android Market's 
-      Application Licensing instead, your 
+    
          Your application cannot be installed to a device's SD card if it uses Google Play's 
+      Copy Protection feature. However, if you use Google Play's 
+      Application Licensing instead, your 
       application can be installed to internal or external storage, including SD cards.
          
 
 
diff --git a/docs/html/guide/appendix/market-filters.jd b/docs/html/guide/appendix/market-filters.jd
index d9b2155f8e465..3e502d7d5f19d 100644
--- a/docs/html/guide/appendix/market-filters.jd
+++ b/docs/html/guide/appendix/market-filters.jd
@@ -1,4 +1,4 @@
-page.title=Market Filters
+page.title=Filters on Google Play
 @jd:body
 
 
          
@@ -6,15 +6,15 @@ page.title=Market Filters
 
 
          Quickview
          
 
            
-
          • Android Market applies filters that control which Android-powered devices can access your
-application on Market.
            • 
+
          • Google Play applies filters that control which Android-powered devices can access your
+application when the user is visiting the store.
            • 
 
          • Filtering is determined by comparing device configurations that you declare in you app's
 manifest file to the configurations defined by the device, as well as other factors.
            •  
          
 
 
          In this document
          
 
 
            
-  
          1. How Filters Work in Android Market
            2. 
+  
          2. How Filters Work on Google Play
            3. 
   
          3. Filtering based on Manifest Elements
     
              
       
            1. Advanced manifest filters
              2. 
@@ -47,10 +47,10 @@ href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><uses-sdk>
   
   
              
-    
-    
              Interested in publishing your app on Android Market?
              
+    
+    
              Interested in publishing your app on Google Play?
              
     
              Go to Android Market to create a publisher
+href="http://play.google.com/apps/publish">Go to Google Play to create a publisher
 account and upload your app.
              
 
          
 
@@ -58,44 +58,44 @@ account and upload your app.
          
 
 
 
-
          When a user searches or browses in Android Market on an Android device, the results are filtered
+
          When a user searches or browses on Google Play on an Android device, the results are filtered
 based on which applications are compatible with that device. For example, if an application
-requires a camera (as specified in the application manifest file), then Android Market will not show
+requires a camera (as specified in the application manifest file), then Google Play will not show
 the app on any device that does not have a camera.
          
 
 
          Declarations in the manifest file that are compared to the device's configuration is not the
 only part of how applications are filtered. Filtering might also occur due to the user's country and
 carrier, the presence or absence of a SIM card, and other factors. 
          
 
-
          Changes to the Android Market filters are independent of changes to the Android platform itself.
-This document is updated periodically to reflect any changes that affect the way Android Market
+
          Changes to the Google Play filters are independent of changes to the Android platform itself.
+This document is updated periodically to reflect any changes that affect the way Google Play
 filters applications.
          
 
 
-
          How Filters Work in Android Market
          
+
          How Filters Work on Google Play
          
 
-
          Android Market uses the filter restrictions described below to determine
+
          Google Play uses the filter restrictions described below to determine
 whether to show your application to a user who is browsing or searching for
-applications from the Android Market app. When determining whether to display your app,
-Market checks the device's hardware and software configuration, as well as it's
+applications from the Google Play app. When determining whether to display your app,
+Google Play checks the device's hardware and software configuration, as well as it's
 carrier, location, and other characteristics. It then compares those against the
 restrictions and dependencies expressed by the application's
 manifest file and publishing details. If the application is
-compatible with the device according to the filter rules, Market displays the
-application to the user. Otherwise, Market hides your application from search
+compatible with the device according to the filter rules, Google Play displays the
+application to the user. Otherwise, Google Play hides your application from search
 results and category browsing, even if a user specifically requests
-the app by clicking a deep link that points directly to the app's ID within Market..
          
+the app by clicking a deep link that points directly to the app's ID within Google Play..
          
 
 
          Note: When users browse the Android Market web site, they can see all published
-applications. The Android Market web site compares the application requirements to each of the
+href="http://play.google.com/apps">Google Play web site, they can see all published
+applications. The Google Play web site compares the application requirements to each of the
 user's registered devices for compatibility, though, and only allows them to install the application
 if it's compatible with their device.
          
 
 
          You can use any combination of the available filters for your app. For example, you can set a
 minSdkVersion requirement of "4" and set smallScreens="false"
-in the app, then when uploading the app to Market you could target European countries (carriers)
-only. Android Market's filters will thus prevent the application from being available on any device
+in the app, then when uploading the app to Google Play you could target European countries (carriers)
+only. Google Play's filters will thus prevent the application from being available on any device
 that does not match all three of these requirements. 
          
 
 
          All filtering restrictions are associated with an application's version and can
@@ -106,15 +106,15 @@ available.
          
 
 
          Filtering based on Manifest Elements
          
 
-
          Most Market filters are triggered by elements within an application's
+
          Most filters are triggered by elements within an application's
 manifest file, AndroidManifest.xml
 (although not everything in the manifest file can trigger filtering).
-Table 1 lists the manifest elements that you should use to trigger Android
-Market filtering, and explains how the filtering for each element works.
          
+Table 1 lists the manifest elements that you should use to trigger
+filtering, and explains how the filtering for each element works.
          
 
 
          Table 1. Manifest elements that
-trigger filtering on Market.
          
+trigger filtering on Google Play.
          
 
          
 
          
@@ -129,19 +129,19 @@ trigger filtering on Market.
          An application indicates the screen sizes that it is capable of supporting by
 setting attributes of the <supports-screens> element. When
-the application is published, Market uses those attributes to determine whether
+the application is published, Google Play uses those attributes to determine whether
 to show the application to users, based on the screen sizes of their
 devices. 
          
 
-
          As a general rule, Market assumes that the platform on the device can adapt
+
          As a general rule, Google Play assumes that the platform on the device can adapt
 smaller layouts to larger screens, but cannot adapt larger layouts to smaller
 screens. Thus, if an application declares support for "normal" screen size only,
-Market makes the application available to both normal- and large-screen devices,
+Google Play makes the application available to both normal- and large-screen devices,
 but filters the application so that it is not available to small-screen
 devices.
          If an application does not declare attributes for
-<supports-screens>, Market uses the default values for those
+<supports-screens>, Google Play uses the default values for those
 attributes, which vary by API Level. Specifically: 
            
@@ -150,7 +150,7 @@ href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">android:
 minSdkVersion or android:
 targetSdkVersion to 3 or lower, the <supports-screens> element itself
-is undefined and no attributes are available. In this case, Market assumes that
+is undefined and no attributes are available. In this case, Google Play assumes that
 the application is designed for normal-size screens and shows the application to
 devices that have normal or larger screens. 
            
 
@@ -166,19 +166,19 @@ default.
     
            Example 1
            
     The manifest declares <uses-sdk android:minSdkVersion="3">
     and does not include a <supports-screens> element.
-    Result: Android Market does not show the app to a user of a
-    small-screen device, but does show it to users of normal and large-screen
-    devices, unless  other filters also exclude those devices. 
            
+    Result: Google Play will not show the app to a user of a
+    small-screen device, but will show it to users of normal and large-screen
+    devices, unless  other filters apply. 
            
     
            Example 2
            
                 The manifest declares <uses-sdk android:minSdkVersion="3"
     android:targetSdkVersion="4"> and does not include a
     <supports-screens> element.
-    Result: Android Market will show the app to users on all
+    Result: Google Play will show the app to users on all
     devices, unless other filters apply. 
            
     
            Example 3
            
                 The manifest declares <uses-sdk android:minSdkVersion="4">
     and does not include a <supports-screens> element.
-    Result: Android Market will show the app to all users,
+    Result: Google Play will show the app to all users,
     unless  other filters apply. 
            
     
            For more information on how to declare support for screen sizes in your
     application, see 
     Configuration: 
            
     keyboard, navigation, touch screen
     
          
@@ -218,16 +218,16 @@ Level 5).
          
       The manifest includes <uses-feature
 android:name="android.hardware.sensor.light" />, and a user
 is searching for apps on a device that does not have a light sensor.
-Result: Android Market will not show the app to the user. 
          
+Result: Google Play will not show the app to the user. 
          
       
          Example 2
          
                 The manifest does not include a <uses-feature>
-element. Result: Android Market will show the app to all users,
+element. Result: Google Play will show the app to all users,
 unless other filters apply.
          
       
          For complete information, see <uses-feature>
 .
          
-      
          Filtering based on implied features: In some cases, Android
-Market interprets permissions requested through
+      
          Filtering based on implied features: In some cases, Google
+Play interprets permissions requested through
 <uses-permission> elements as feature requirements equivalent
 to those declared in <uses-feature> elements. See <uses-permission>,
@@ -245,19 +245,19 @@ below.
          
       
          Example 1
          
                 An app
         requests multiple OpenGL-ES versions by specifying openGlEsVersion multiple times in the
-        manifest.  Result: Market assumes that the app requires the highest of the indicated versions.
          
+        manifest.  Result: Google Play assumes that the app requires the highest of the indicated versions.
          
 
          Example 2
          
           An app
-        requests OpenGL-ES version 1.1, and a user is searching for apps on a device that supports OpenGL-ES version 2.0. Result: Android Market will show the app to the user, unless other filters apply. If a
-  device reports that it supports OpenGL-ES version X,  Market assumes that it
+        requests OpenGL-ES version 1.1, and a user is searching for apps on a device that supports OpenGL-ES version 2.0. Result: Google Play will show the app to the user, unless other filters apply. If a
+  device reports that it supports OpenGL-ES version X,  Google Play assumes that it
   also supports any version earlier than X.
 
          
 
          Example 3
          
           A user is searching for apps on a device that does not
-        report an OpenGL-ES version (for example, a device running Android 1.5 or earlier). Result: Android Market assumes that the device
-  supports only OpenGL-ES 1.0. Market will only show the user apps that do not specify openGlEsVersion, or apps that do not specify an OpenGL-ES version higher than 1.0. 
          
+        report an OpenGL-ES version (for example, a device running Android 1.5 or earlier). Result: Google Play assumes that the device
+  supports only OpenGL-ES 1.0. Google Play will only show the user apps that do not specify openGlEsVersion, or apps that do not specify an OpenGL-ES version higher than 1.0. 
          
       
          Example 4
          
-                The manifest does not specify openGlEsVersion. Result: Android Market will show the app to all users, unless other filters apply. 
          
+      The manifest does not specify openGlEsVersion. Result: Google Play will show the app to all users, unless other filters apply. 
          
 
          For more details, see <uses-feature>.
          
   
@@ -268,28 +268,28 @@ href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses-
               
-    
@@ -316,7 +316,7 @@ href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">android:m
     
@@ -327,7 +327,7 @@ href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#max">android:m
 
 
          Advanced manifest filters
          
 
-
          In addition to the manifest elements in table 1, Android Market can also
+
          In addition to the manifest elements in table 1, Google Play can also
 filter applications based on the advanced manifest elements in table 2.
          
 
 
          These manifest elements and the filtering they trigger are for exceptional use-cases
@@ -336,14 +336,14 @@ require strict controls on application distribution. Most applications s
 these filters.
          
 
 
          Table 2. Advanced manifest elements for
-Android Market filtering.
          
+Google Play filtering.
          
 
          
   
          
     Manifest Element
 
 
 
 
 
 
          An application can
-    request certain hardware features, and Android Market will  show the app only on devices that have the required hardware.
          
+    request certain hardware features, and Google Play will  show the app only on devices that have the required hardware.
          
       
          Example 1
          
-                The manifest includes <uses-configuration android:reqFiveWayNav="true" />, and a user is searching for apps on a device that does not have a five-way navigational control. Result: Android Market will not show the app to the user. 
          
+      The manifest includes <uses-configuration android:reqFiveWayNav="true" />, and a user is searching for apps on a device that does not have a five-way navigational control. Result: Google Play will not show the app to the user. 
          
       
          Example 2
          
-                The manifest does not include a <uses-configuration> element. Result: Android Market will show the app to all users, unless other filters apply.
          
+      The manifest does not include a <uses-configuration> element. Result: Google Play will show the app to all users, unless other filters apply.
          
 
          For more details, see  <uses-configuration>.
          		
   
          An application can require specific
     shared libraries to be present on the device. 
          
       
          Example 1
          
-                An app requires the com.google.android.maps library, and a user is searching for apps on a device that does not have the com.google.android.maps library. Result: Android Market will not show the app to the user. 
          
+      An app requires the com.google.android.maps library, and a user is searching for apps on a device that does not have the com.google.android.maps library. Result: Google Play will not show the app to the user. 
          
       
          Example 2
          
-        The manifest does not include a <uses-library> element. Result: Android Market will show the app to all users, unless other filters apply.
          
+        The manifest does not include a <uses-library> element. Result: Google Play will show the app to all users, unless other filters apply.
          
 
          For more details, see <uses-library>.
          		
   
          
   
          
     <uses-permission>
      Strictly, Android Market does not filter based on
+    Strictly, Google Play does not filter based on
 <uses-permission> elements. However, it does read the
 elements to determine whether the application has hardware feature requirements
 that may not have been properly declared in <uses-feature>
 elements. For example, if an application requests the CAMERA
 permission but does not declare a <uses-feature> element for
-android.hardware.camera, Android Market considers that the
+android.hardware.camera, Google Play considers that the
 application requires a camera and should not be shown to users whose devices do
 not offer a camera.
          
     
          In general, if an application requests hardware-related permissions,
-Android Market assumes that the application requires the underlying hardware
+Google Play assumes that the application requires the underlying hardware
 features, even though there might be no corresponding to
-<uses-feature> declarations. Android Market then sets up
+<uses-feature> declarations. Google Play then sets up
 filtering based on the features implied by the <uses-feature>
 declarations.
          
     
          For a list of permissions that imply hardware features, see
@@ -305,9 +305,9 @@ element.
          
     
          An application can require a minimum API level.  
          
       
          Example 1
          
         The manifest includes <uses-sdk
-      android:minSdkVersion="3">, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. Result: Android Market will not show the app to the user. 
          
+      android:minSdkVersion="3">, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. Result: Google Play will not show the app to the user. 
          
       
          Example 2
          
-      The manifest does not include minSdkVersion, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. Result: Android Market assumes that minSdkVersion is "1" and that the app is compatible with all versions of Android. Market  shows the app to the user and allows the user to download the app. The app crashes at runtime. 
          
+      The manifest does not include minSdkVersion, and the app uses APIs that were introduced in API Level 3. A user is searching for apps on a device that has API Level 2. Result: Google Play assumes that minSdkVersion is "1" and that the app is compatible with all versions of Android. Google Play  shows the app to the user and allows the user to download the app. The app crashes at runtime. 
          
     
          Because you want to avoid this second scenario, we recommend that you always declare a minSdkVersion. For details, see android:minSdkVersion.
          		
   
          Deprecated. Android
     2.1 and later do not check or enforce the maxSdkVersion attribute, and
     the SDK will not compile if maxSdkVersion is set in an app's manifest. For devices already
-    compiled with maxSdkVersion, Market will respect it and use it for
+    compiled with maxSdkVersion, Google Play will respect it and use it for
     filtering.
          
 
           Declaring maxSdkVersion is not recommended. For details, see android:maxSdkVersion.
          
@@ -370,16 +370,16 @@ formats supported by the application are also supported by the device. 
          
 
 
          Other Filters
          
 
-
          Android Market uses other application characteristics to determine whether to show or hide an application for a particular user on a given device, as described in the table below. 
          
+
          Google Play uses other application characteristics to determine whether to show or hide an application for a particular user on a given device, as described in the table below. 
          
 
 
          Table 3. Application and publishing
-characteristics that affect filtering on Market.
          
+characteristics that affect filtering on Google Play.
          
 
          
   
          Manifest ElementSummary
          
   
          
     {@code
 <compatible-screens>}
     
-      
          Android Market filters the application if the device screen size and density does not match
+      
          Google Play filters the application if the device screen size and density does not match
 any of the screen configurations (declared by a {@code <screen>} element) in the {@code
 <compatible-screens>} element.
          
       
          Caution: Normally, you should not use
@@ -360,7 +360,7 @@ with alternative resources.
          
               		{@code
 <supports-gl-texture>}
     
-      
          Android Market filters the application unless one or more of the GL texture compression
+      
          Google Play filters the application unless one or more of the GL texture compression
 formats supported by the application are also supported by the device. 
          
               		
   
          
@@ -390,10 +390,10 @@ must have a SIM card and be running Android 1.1 or later, and it must be in a
 country (as determined by SIM carrier) in which paid apps are available.
          
            
@@ -404,22 +404,22 @@ country (as determined by SIM carrier) in which paid apps are available.
           
           
          
     Filter Name How It Works 
          
 
   
          
     Publishing Status 
          Only published applications will appear in
-      searches and browsing within Android Market.
           
          Even if an app is unpublished, it can
+      searches and browsing within Google Play.
           
          Even if an app is unpublished, it can
         be installed if users can see it in their Downloads area among their purchased,
         installed, or recently uninstalled apps.
           
          If an application has been
   suspended, users will not be able to reinstall or update it, even if it appears in their Downloads.
           
          
   Country / Carrier Targeting  
          When you upload your app to
-    the Android Market, you can select specific countries to target. The app will only
+    Google Play, you can select specific countries to target. The app will only
     be visible to the countries (carriers) that you select, as follows:
          
     
          • A device's country is determined based on the carrier, if a carrier is
-      available. If no carrier can be determined, the Market application tries to
+      available. If no carrier can be determined, Google Play tries to
       determine the country based on IP.
            •  
          • Carrier is determined based on
       the device's SIM (for GSM devices), not the current roaming carrier.
          
           		 
           
           
          
         Copy-Protected Applications 
          To
           copy protect an application, set copy protection to "On" when you configure publishing
-options for your application. Market will not show copy-protected applications on
+options for your application. Google Play will not show copy-protected applications on
 developer devices or unreleased devices.
          		 
           
          
 
 
 
 
          Publishing Multiple APKs with Different Filters
          
 
-
          Some specific Android Market filters allow you to publish multiple APKs for the same
+
          Some specific Google Play filters allow you to publish multiple APKs for the same
 application in order to provide a different APK to different device configurations. For example, if
 you're creating a video game that uses high-fidelity graphic assets, you might want to create
 two APKs that each support different texture compression formats. This way, you can reduce the
 size of the APK file by including only the textures that are required for each device
-configuration. Depending on each device's support for your texture compression formats, Android
-Market will deliver it the APK that you've declared to support that device.
          
+configuration. Depending on each device's support for your texture compression formats, Google
+Play will deliver it the APK that you've declared to support that device.
          
 
-
          Currently, Android Market allows you to publish multiple APKs for the same application only
+
          Currently, Google Play allows you to publish multiple APKs for the same application only
 when each APK provides different filters based on the following configurations:
          
 
            
   
          • OpenGL texture compression formats
@@ -440,7 +440,7 @@ href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code
 
          
 
 
          All other filters still work the same as usual, but these three are the only filters that can
-distinguish one APK from another within the same application listing on Android Market. For example,
+distinguish one APK from another within the same application listing on Google Play. For example,
 you cannot publish multiple APKs for the same application if the APKs differ only based on
 whether the device has a camera.
          
 
@@ -450,5 +450,5 @@ APK that supports a wide range of device configurations. Publishing mul
 requires that you follow specific rules within your filters and that you pay extra attention to the
 version codes for each APK to ensure proper update paths for each configuration.
          
 
-
          If you need more information about how to publish multiple APKs on Android Market, read If you need more information about how to publish multiple APKs on Google Play, read Multiple APK Support.
          
diff --git a/docs/html/guide/developing/building/index.jd b/docs/html/guide/developing/building/index.jd
index 59c46452a70d0..569cd28387b8a 100644
--- a/docs/html/guide/developing/building/index.jd
+++ b/docs/html/guide/developing/building/index.jd
@@ -27,8 +27,8 @@ page.title=Building and Running
   
          To run an application on an emulator or device, the application must be signed using debug or
   release mode. You typically want to sign your application in debug mode when you develop and test
   your application, because the build tools use a debug key with a known password so you do not have
-  to enter it every time you build. When you are ready to release the application to Android
-  Market, you must sign the application in release mode, using your own private key.
          
+  to enter it every time you build. When you are ready to release the application to Google
+  Play, you must sign the application in release mode, using your own private key.
          
 
   
          Fortunately, Eclipse or your Ant build script signs the application for you in debug mode
   when you build your application. You can also easily setup Eclipse or your Ant build to sign your
diff --git a/docs/html/guide/guide_toc.cs b/docs/html/guide/guide_toc.cs
index fd2ec93c0d87c..9d5064e4f8635 100644
--- a/docs/html/guide/guide_toc.cs
+++ b/docs/html/guide/guide_toc.cs
@@ -444,12 +444,12 @@
   
 
   
        11. 
-    
-      Android Market Topics
-    
+    
          
+      Google Play Topics
+    
          
     
       
          12. 
       
        12. 
-          Market Filters
+          Filters on Google Play
       
          13. 
       
        13. 
           Multiple APK Support
diff --git a/docs/html/guide/market/billing/billing_admin.jd b/docs/html/guide/market/billing/billing_admin.jd
index a84eb4e881391..0f869ab787957 100755
--- a/docs/html/guide/market/billing/billing_admin.jd
+++ b/docs/html/guide/market/billing/billing_admin.jd
@@ -38,19 +38,19 @@ parent.link=index.html
 few administrative tasks, including setting up and maintaining your product list on the publisher
 site, registering test accounts, and handling refunds when necessary.
          
 
-
          You must have an Android Market publisher account to register test accounts. And you must have a
+
          You must have a Google Play publisher account to register test accounts. And you must have a
 Google Checkout merchant account to create a product list and issue refunds to your users. If you
-already have a publisher account on Android Market, you can use your existing account. You do not
+already have a publisher account on Google Play, you can use your existing account. You do not
 need to register for a new account to support in-app billing. If you do not have a publisher
-account, you can register as an Android Market developer and set up a publisher account at the
-Android Market publisher site. If you do not have a
+account, you can register as a Google Play developer and set up a publisher account at the
+Google Play publisher site. If you do not have a
 Google Checkout merchant account, you can register for one at the Google Checkout site.
          
 
 
          Creating a Product List
          
 
-
          The Android Market publisher site provides a product list for each of your published
-applications. You can sell an item using Android Market's in-app billing feature only if the item is
+
          The Google Play publisher site provides a product list for each of your published
+applications. You can sell an item using Google Play's in-app billing feature only if the item is
 listed on an application's product list. Each application has its own product list; you cannot sell
 items that are listed in another application's product list.
          
 
@@ -77,7 +77,7 @@ storing and delivering the digital content that you sell in your applications.
 
 
          You can create a product list for any published application or any draft application that's been
-uploaded and saved to the Android Market site. However, you must have a Google Checkout merchant
+uploaded and saved to the Google Play site. However, you must have a Google Checkout merchant
 account and the application's manifest must include the com.android.vending.BILLING
 permission. If an application's manifest does not include this permission, you will be able to edit
 existing items in the product list but you will not be able to add new items to the list. For more
@@ -104,8 +104,8 @@ number of in-app items.
          
 
          To add an item to a product list using the In-app Products UI, follow these steps:
          
 
 
            
-  
          1. Log in to your publisher account.
            2. 
-  
          2. In the All Android Market listings panel, under the application name, click
+  
          3. Log in to your publisher account.
            4. 
+  
          4. In the All Google Play listings panel, under the application name, click
   In-app Products.
            5. 
   
          5. On the In-app Products List page, click Add in-app product.
            6. 
   
          6. On the Create New In-app Product page (see figure 3), provide details about the item you are
@@ -137,7 +137,7 @@ number of in-app items.
            
   
          7. Publishing State
     
            An item's publishing state can be Published or Unpublished
     . To be visible to a user during checkout, an item's publishing state must be set to
-    Published and the item's application must be published on Android Market.
            
+    Published and the item's application must be published on Google Play.
            
     
            Note: This is not true for test accounts. An item is visible to
     a test account if the application is not published and the item is published. See Testing In-app
@@ -167,9 +167,9 @@ number of in-app items.
            
     
            You must provide a default price in your home currency. You can also provide prices in other
     currencies, but you can do this only if a currency's corresponding country is listed as a
     target country for your application. You can specify target countries on the Edit Application
-    page in the Android Market developer console.
            
+    page in the Google Play developer console.
            
     
            To specify prices in other currencies, you can manually enter the price for each
-    currency or you can click Auto Fill and let Android Market do a one-time
+    currency or you can click Auto Fill and let Google Play do a one-time
     conversion from your home currency to the currencies you are targeting (see figure 4).
            
   
            8. 
 
@@ -357,8 +357,8 @@ with the locale field.
            
 
            To import the items that are specified in your CSV file, do the following:
            
 
 
              
-  
            1. Log in to your publisher account.
              2. 
-  
            2. In the All Android Market listings panel, under the application name, click
+  
            3. Log in to your publisher account.
              4. 
+  
            4. In the All Google Play listings panel, under the application name, click
   In-app Products.
              5. 
   
            5. On the In-app Products List page, click Choose File and select your CSV
 file.
@@ -381,17 +381,17 @@ a product list and you want to start managing the product list through a CSV fil
 
 
              Choosing a Purchase Type
              
 
-
              An item's purchase type controls how Android Market manages the purchase of the item. There are
+
              An item's purchase type controls how Google Play manages the purchase of the item. There are
 two purchase types: "managed per user account" and "unmanaged."
              
 
 
              Items that are managed per user account can be purchased only once per user account. When an item
-is managed per user account, Android Market permanently stores the transaction information for each
-item on a per-user basis. This enables you to query Android Market with the
+is managed per user account, Google Play permanently stores the transaction information for each
+item on a per-user basis. This enables you to query Google Play with the
 RESTORE_TRANSACTIONS request and restore the state of the items a specific user has
 purchased.
              
 
-
              If a user attempts to purchase a managed item that has already been purchased, Android Market
-displays an "Item already purchased" error. This occurs during checkout, when Android Market
+
              If a user attempts to purchase a managed item that has already been purchased, Google Play
+displays an "Item already purchased" error. This occurs during checkout, when Google Play
 displays the price and description information on the checkout page. When the user dismisses the
 error message, the checkout page disappears and the user returns to your user interface. As a best
 practice, your application should prevent the user from seeing this error. The sample application
@@ -404,10 +404,10 @@ or application features. These items are not transient and usually need to be re
 user reinstalls your application, wipes the data on their device, or installs your application on a
 new device.
              
 
-
              Items that are unmanaged do not have their transaction information stored on Android Market,
-which means you cannot query Android Market to retrieve transaction information for items whose
+
              Items that are unmanaged do not have their transaction information stored on Google Play,
+which means you cannot query Google Play to retrieve transaction information for items whose
 purchase type is listed as unmanaged. You are responsible for managing the transaction information
-of unmanaged items. Also, unmanaged items can be purchased multiple times as far as Android Market
+of unmanaged items. Also, unmanaged items can be purchased multiple times as far as Google Play
 is concerned, so it's also up to you to control how many times an unmanaged item can be
 purchased.
              
 
@@ -417,10 +417,10 @@ times.
              
 
 
              Handling Refunds
              
 
-
              In-app billing does not allow users to send a refund request to Android Market. Refunds for
+
              In-app billing does not allow users to send a refund request to Google Play. Refunds for
 in-app purchases must be directed to you (the application developer). You can then process the
-refund through your Google Checkout merchant account. When you do this, Android Market receives a
-refund notification from Google Checkout, and Android Market sends a refund message to your
+refund through your Google Checkout merchant account. When you do this, Google Play receives a
+refund notification from Google Checkout, and Google Play sends a refund message to your
 application. For more information, see Handling
 IN_APP_NOTIFY messages and 
 
 
              Setting Up Test Accounts
              
 
-
              The Android Market publisher site lets you set up one or more test accounts. A test account is a
+
              The Google Play publisher site lets you set up one or more test accounts. A test account is a
 regular Google account that you register on the publisher site as a test account. Test accounts are
-authorized to make in-app purchases from applications that you have uploaded to the Android Market
+authorized to make in-app purchases from applications that you have uploaded to the Google Play
 site but have not yet published.
              
 
 
              You can use any Google account as a test account. Test accounts are useful if you want to let
@@ -458,7 +458,7 @@ accounts yourself and distribute the credentials to your developers or testers.<
 
              To add test accounts to your publisher account, follow these steps:
              
 
 
                
-  
              1. Log in to your publisher account.
                2. 
+  
              2. Log in to your publisher account.
                3. 
   
              3. On the upper left part of the page, under your name, click Edit profile.
                4. 
   
              4. On the Edit Profile page, scroll down to the Licensing & In-app Billing panel (see figure
   5).
                5. 
@@ -480,7 +480,7 @@ support resources listed in the following table (see table 2). By directing your
 correct forum, you can get the support you need more quickly.
                
 
 
                Table 2. Developer support resources
-for Android Market in-app billing.
                
+for Google Play in-app billing.
                
 
 
 
@@ -502,8 +502,8 @@ href="http://stackoverflow.com/questions/tagged/android">http://stackoverflow.co
 android
-
-
+
diff --git a/docs/html/guide/market/billing/billing_best_practices.jd b/docs/html/guide/market/billing/billing_best_practices.jd
index d9776af5e9c76..e100ce5813031 100755
--- a/docs/html/guide/market/billing/billing_best_practices.jd
+++ b/docs/html/guide/market/billing/billing_best_practices.jd
@@ -32,7 +32,7 @@ parent.link=index.html
 
 
                As you design your in-app billing implementation, be sure to follow the security and design
 guidelines that are discussed in this document. These guidelines are recommended best practices for
-anyone who is using Android Market's in-app billing service.
                
+anyone who is using Google Play's in-app billing service.
                Security Best Practices
                
 
@@ -92,7 +92,7 @@ replay attacks.
                
 nonces on the server.
                Take action against trademark and copyright infringement
                
-
                If you see your content being redistributed on Android Market, act quickly and decisively. File a
+
                If you see your content being redistributed on Google Play, act quickly and decisively. File a
 trademark notice
 of infringement or a copyright notice of
 infringement.
                
@@ -102,7 +102,7 @@ infringement.
                
 purchase state of the unlocked content whenever a user accesses the content. This allows you to
 revoke use when necessary and minimize piracy.
                
 
-
                Protect your Android Market public key
                
+
                Protect your Google Play public key
                To keep your public key safe from malicious users and hackers, do not embed it in any code as a
 literal string. Instead, construct the string at runtime from pieces or use bit manipulation (for
 example, XOR with some other string) to hide the actual key. The key itself is not secret
diff --git a/docs/html/guide/market/billing/billing_integrate.jd b/docs/html/guide/market/billing/billing_integrate.jd
index 6017583d8b159..57f685b22577b 100755
--- a/docs/html/guide/market/billing/billing_integrate.jd
+++ b/docs/html/guide/market/billing/billing_integrate.jd
@@ -35,8 +35,8 @@ parent.link=index.html
 
 
 
-
                Android Market In-app Billing provides a straightforward, simple interface for sending in-app
-billing requests and managing in-app billing transactions using Android Market. This document helps
+
                In-app Billing on Google Play provides a straightforward, simple interface for sending in-app
+billing requests and managing in-app billing transactions using Google Play. This document helps
 you implement in-app billing by stepping through the primary implementation tasks, using the in-app
 billing sample application as an example.
                
 
@@ -53,23 +53,23 @@ billing.
              5. Update your AndroidManifest.xml file.
              6. Create a Service and bind it to the
   MarketBillingService so your application can send billing requests and receive
-  billing responses from the Android Market application.
                7. 
+  billing responses from Google Play.
              7. Create a BroadcastReceiver to handle broadcast
-  intents from the Android Market application.
                8. 
+  intents from Google Play.
              8. Create a security processing component to verify the
-  integrity of the transaction messages that are sent by Android Market .
                9. 
+  integrity of the transaction messages that are sent by Google Play.
              9. Modify your application code to support in-app billing.
                10. Downloading the Sample Application
                The in-app billing sample application shows you how to perform several tasks that are common to
-all Android Market in-app billing implementations, including:
                
+all in-app billing implementations, including:
                  
-  
                • Sending in-app billing requests to the Android Market application.
                  • 
-  
                • Handling synchronous responses from the Android Market application.
                  • 
-  
                • Handling broadcast intents (asynchronous responses) from the Android Market application.
                  • 
+  
                • Sending in-app billing requests to Google Play.
                  • 
+  
                • Handling synchronous responses from Google Play.
                  • 
+  
                • Handling broadcast intents (asynchronous responses) from Google Play.
                  • 
   
                • Using in-app billing security mechanisms to verify the integrity of billing responses.
                  • 
   
                • Creating a user interface that lets users select items for purchase.
                  • 
 
                
@@ -109,12 +109,12 @@ history.
-  
 
@@ -136,8 +136,8 @@ history.
-
+
@@ -171,7 +171,7 @@ running the sample application involves three tasks:
                  
   
                • Configuring and building the sample application.
                  • 
-  
                • Uploading the sample application to Android Market.
                  • 
+  
                • Uploading the sample application to Google Play.
                  • 
   
                • Setting up test accounts and running the sample application.
                  • 
 
                
 
@@ -186,12 +186,12 @@ your project.
                
 following:
                  
-  
                1. Add your Android Market public key to the sample application code.
+  
                2. Add your Google Play public key to the sample application code.
     
                  This enables the application to verify the signature of the transaction information that is
-    returned from Android Market. To add your public key to the sample application code, do the
+    returned from Google Play. To add your public key to the sample application code, do the
     following:
                  
     
                    
-      
                  1. Log in to your Android Market publisher
+      
                  2. Log in to your Google Play publisher
       account.
                    3. 
       
                  3. On the upper left part of the page, under your name, click Edit
       Profile.
                    4. 
@@ -208,7 +208,7 @@ following:
                    
     
                  
   
                  3. 
   
                3. Change the package name of the sample application.
-    
                  The current package name is com.example.dungeons. Android Market does not let
+    
                  The current package name is com.example.dungeons. Google Play does not let
     you upload applications with package names that contain com.example, so you must
     change the package name to something else.
                  
   
                  4. 
@@ -221,14 +221,14 @@ following:
                  
 
                  Uploading the sample application
                  
 
 
                  After you build a release version of the sample application and sign it, you need to upload it as
-a draft to the Android Market publisher site. You also need to create a product list for the in-app
+a draft to the Google Play publisher site. You also need to create a product list for the in-app
 items that are available for purchase in the sample application. The following instructions show you
 how to do this.
                  
 
                    
-  
                  1. Upload the release version of the sample application to Android Market.
+  
                  2. Upload the release version of the sample application to Google Play.
     
                    Do not publish the sample application; leave it as an unpublished draft application. The
     sample application is for demonstration purposes only and should not be made publicly available
-    on Android Market. To learn how to upload an application to Android Market, see Uploading
     applications.
                    
   
                    3. 
@@ -253,7 +253,7 @@ how to do this.
                    
 onto a device to run it. To run the sample application, do the following:
                    
 
 
                      
-  
                    1. Make sure you have at least one test account registered under your Android Market
+  
                    2. Make sure you have at least one test account registered under your Google Play
   publisher account.
     
                      You cannot purchase items from yourself (Google Checkout prohibits this), so you need to
     create at least one test account that you can use to purchase items in the sample application.
@@ -261,18 +261,18 @@ onto a device to run it. To run the sample application, do the following:
                      
     href="{@docRoot}guide/market/billing/billing_testing.html#billing-testing-setup">Setting up Test
     Accounts.
                      
   
                      3. 
-  
                    3. Verify that your device is running a supported version of the Android Market
+  
                    4. Verify that your device is running a supported version of the Google Play
   application or the MyApps application.
     
                      If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of
     the MyApps application. If your device is running any other version of Android, in-app billing
-    requires version 2.3.4 (or higher) of the Android Market application. To learn how to check the
-    version of the Android Market application, see Updating Android
-    Market.
                      
+    requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
+    version of the Google Play application, see Updating Google
+    Play.
                      
   
                      5. 
   
                    5. Install the application onto your device.
-    
                      Even though you uploaded the application to Android Market, the application is not published,
-    so you cannot download it from Android Market to a device. Instead, you must install the
+    
                      Even though you uploaded the application to Google Play, the application is not published,
+    so you cannot download it from Google Play to a device. Instead, you must install the
     application onto your device. To learn how to install an application onto a device, see Running on a
     device.
                      
@@ -280,7 +280,7 @@ onto a device to run it. To run the sample application, do the following:
                      
  
                    6. Make one of your test accounts the primary account on your device.
     
                      The primary account on your device must be one of the test accounts
-    that you registered on the Android Market site. If the primary account on your device is not a
+    that you registered on the Google Play publisher site. If the primary account on your device is not a
     test account, you must do a factory reset of the device and then sign in with one of your test
     accounts. To perform a factory reset, do the following:
                      
     
                        
@@ -306,7 +306,7 @@ to true in the Consts.java file.
                        
 
                        Adding the AIDL file to your project
                        
 
 
                        The sample application contains an Android Interface Definition Language (AIDL) file,  which
-defines the interface to Android Market's in-app billing service
+defines the interface to Google Play's in-app billing service
 (MarketBillingService). When you add this file to your project, the Android build
 environment creates an interface file (IMarketBillingService.java). You can then use
 this interface to make billing requests by invoking IPC method calls.
                        
@@ -333,29 +333,29 @@ the gen folder of your project.
                        
 
 
                        Updating Your Application's Manifest
                        
 
-
                        In-app billing relies on the Android Market application, which handles all communication between
-your application and the Android Market server. To use the Android Market application, your
+
                        In-app billing relies on the Google Play application, which handles all communication between
+your application and the Google Play server. To use the Google Play application, your
 application must request the proper permission. You can do this by adding the
 com.android.vending.BILLING permission to your AndroidManifest.xml file. If your
 application does not declare the in-app billing permission, but attempts to send billing requests,
-Android Market will refuse the requests and respond with a RESULT_DEVELOPER_ERROR
+Google Play will refuse the requests and respond with a RESULT_DEVELOPER_ERROR
 response code.
                        
 
 
                        In addition to the billing permission, you need to declare the {@link
 android.content.BroadcastReceiver} that you will use to receive asynchronous response messages
-(broadcast intents) from Android Market, and you need to declare the {@link android.app.Service}
-that you will use to bind with the IMarketBillingService and send messages to Android
-Market. You must also declare IMarketBillingService and send messages to Google
+Play. You must also declare intent filters for the {@link
 android.content.BroadcastReceiver} so that the Android system knows how to handle the broadcast
-intents that are sent from the Android Market application.
                        
+intents that are sent from the Google Play application.
                        
 
 
                        For example, here is how the in-app billing sample application declares the billing permission,
 the {@link android.content.BroadcastReceiver}, the {@link android.app.Service}, and the intent
 filters. In the sample application, BillingReceiver is the {@link
-android.content.BroadcastReceiver} that handles broadcast intents from the Android Market
+android.content.BroadcastReceiver} that handles broadcast intents from the Google Play
 application and BillingService is the {@link android.app.Service} that sends requests
-to the Android Market application.
                        
+to the Google Play application.
                        
 
 
                         <?xml version="1.0" encoding="utf-8"?>
@@ -391,11 +391,11 @@ to the Android Market application.
                        
 
                        Creating a Local Service
                        
 
 
                        Your application must have a local {@link android.app.Service} to facilitate messaging between
-your application and Android Market. At a minimum, this service must do the following:
                        
+your application and Google Play. At a minimum, this service must do the following:
                        
 
 
                          
   
                        • Bind to the MarketBillingService.
-  
                        • Send billing requests (as IPC method calls) to the Android Market application. The five types
+  
                        • Send billing requests (as IPC method calls) to the Google Play application. The five types
   of billing requests include:
     
                            
       
                          • CHECK_BILLING_SUPPORTED requests
                            • 
@@ -474,7 +474,7 @@ The five request types are specified using the BILLING_REQUEST Bund
 key can have the following five values:
                            
 
 
                              
-  
                            • CHECK_BILLING_SUPPORTED—verifies that the Android Market application
+  
                            • CHECK_BILLING_SUPPORTED—verifies that the Google Play application
   supports in-app billing.
                              • 
   
                            • REQUEST_PURCHASE—sends a purchase request for an in-app item.
                              • 
   
                            • GET_PURCHASE_INFORMATION—retrieves transaction information for a purchase
@@ -510,7 +510,7 @@ application's main thread.
                              
 
 
                              Verifying that in-app billing is supported (CHECK_BILLING_SUPPPORTED)
                              
 
-
                              The following code sample shows how to verify whether the Android Market application supports
+
                              The following code sample shows how to verify whether the Google Play application supports
 in-app billing. In the sample, mService is an instance of the
 MarketBillingService interface.
                              
 
@@ -533,7 +533,7 @@ android.os.Bundle} response, which contains only a single key: RESPONSE_CO
   
                            • RESULT_BILLING_UNAVAILABLE—in-app billing is not available because the API
   version you specified is not recognized or the user is not eligible to make in-app purchases (for
   example, the user resides in a country that prohibits in-app purchases).
                              • 
-  
                            • RESULT_ERROR—there was an error connecting with the Android Market
+  
                            • RESULT_ERROR—there was an error connecting with the Google Play
   application.
                              • 
   
                            • RESULT_DEVELOPER_ERROR—the application is trying to make an in-app billing
   request but the application has not declared the com.android.vending.BILLING
@@ -546,10 +546,10 @@ android.os.Bundle} response, which contains only a single key: RESPONSE_CO
 
 
                              We recommend that you invoke the CHECK_BILLING_SUPPORTED request within a
 RemoteException block. When your code throws a RemoteException it
-indicates that the remote method call failed, which means that the Android Market application is out
+indicates that the remote method call failed, which means that the Google Play application is out
 of date and needs to be updated. In this case, you can provide users with an error message that
 contains a link to the Updating Android Market
+href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google Play
 Help topic.
                              
 
 
                              The sample application demonstrates how you can handle this error condition (see
@@ -561,16 +561,16 @@ Help topic.
                              
 
 
                                
   
                              • Send the REQUEST_PURCHASE request.
                                • 
-  
                              • Launch the {@link android.app.PendingIntent} that is returned from the Android Market
+  
                              • Launch the {@link android.app.PendingIntent} that is returned from the Google Play
   application.
                                • 
-  
                              • Handle the broadcast intents that are sent by the Android Market application.
                                • 
+  
                              • Handle the broadcast intents that are sent by the Google Play application.
                                • 
 
                              
 
 
                              Making the request
                              
 
 
                              You must specify four keys in the request {@link android.os.Bundle}. The following code sample
 shows how to set these keys and make a purchase request for a single in-app item. In the sample,
-mProductId is the Android Market product ID of an in-app item (which is listed in the
+mProductId is the Google Play product ID of an in-app item (which is listed in the
 application's product
 list), and mService is an instance of the MarketBillingService
 interface.
                              
@@ -644,25 +644,25 @@ void startBuyPageActivity(PendingIntent pendingIntent, Intent intent) {
 context and not an application context. Also, you cannot use the singleTop launch mode to launch the
 pending intent. If you do either of these, the Android system will not attach the pending intent to
-your application process. Instead, it will bring Android Market to the foreground, disrupting your
+your application process. Instead, it will bring Google Play to the foreground, disrupting your
 application.
                              
 
 
                              Handling broadcast intents
                              
 
 
                              A REQUEST_PURCHASE request also triggers two asynchronous responses (broadcast
-intents). First, the Android Market application sends a RESPONSE_CODE broadcast intent,
+intents). First, the Google Play application sends a RESPONSE_CODE broadcast intent,
 which provides error information about the request. If the request does not generate an
 error, the RESPONSE_CODE broadcast intent returns RESULT_OK, which
 indicates that the request was successfully sent. (To be clear, a RESULT_OK response
 does not indicate that the requested purchase was successful; it indicates that the request was sent
-successfully to Android Market.)
                              
+successfully to Google Play.)
                              
 
 
                              Next, when the requested transaction changes state (for example, the purchase is successfully
-charged to a credit card or the user cancels the purchase), the Android Market application sends an
+charged to a credit card or the user cancels the purchase), the Google Play application sends an
 IN_APP_NOTIFY broadcast intent. This message contains a notification ID, which you can
 use to retrieve the transaction details for the REQUEST_PURCHASE request.
                              
 
-
                              Note: The Android Market application also sends
+
                              Note: The Google Play application also sends
 an IN_APP_NOTIFY for refunds. For more information, see Handling
 IN_APP_NOTIFY messages.
                              
@@ -670,7 +670,7 @@ IN_APP_NOTIFY messages.
                              
 
                              Because the purchase process is not instantaneous and can take several seconds (or more), you
 must assume that a purchase request is pending from the time you receive a RESULT_OK
 message until you receive an IN_APP_NOTIFY message for the transaction. While the
-transaction is pending, the Android Market checkout UI displays an "Authorizing purchase..."
+transaction is pending, the Google Play checkout UI displays an "Authorizing purchase..."
 notification; however, this notification is dismissed after 60 seconds and you should not rely on
 this notification as your primary means of conveying transaction status to users. Instead, we
 recommend that you do the following:
                              
@@ -693,12 +693,12 @@ status of pending and completed in-app purchases.
                              
 be sure that your pending status UI does not block your application. For example, you should avoid
 using a hovering progress wheel to convey the status of a pending transaction because a pending
 transaction could last a long time, particularly if a device loses network connectivity and cannot
-receive transaction updates from Android Market.
                              
+receive transaction updates from Google Play.
                              
 
 
                              Important: If a user purchases a managed item, you must prevent
 the user from purchasing the item again while the original transaction is pending. If a user
-attempts to purchase a managed item twice, and the first transaction is still pending, Android
-Market will display an error to the user; however, Android Market will not send an error to your
+attempts to purchase a managed item twice, and the first transaction is still pending, Google
+Play will display an error to the user; however, Google Play will not send an error to your
 application notifying you that the second purchase request was canceled. This might cause your
 application to get stuck in a pending state while it waits for an IN_APP_NOTIFY message
 for the second purchase request.
                              
@@ -730,7 +730,7 @@ three keys that are required for all requests: BILLING_REQUEST,
 API_VERSION, and PACKAGE_NAME. The additional keys are then added to the
 bundle prior to invoking the sendBillingRequest() method. The
 REQUEST_NONCE key contains a cryptographically secure nonce (number used once) that you
-must generate. The Android Market application returns this nonce with the
+must generate. The Google Play application returns this nonce with the
 PURCHASE_STATE_CHANGED broadcast intent so you can verify the integrity of the
 transaction information. The NOTIFY_IDS key contains an array of notification IDs,
 which you received in the IN_APP_NOTIFY broadcast intent.
                              
@@ -741,9 +741,9 @@ you with the status of the request and the REQUEST_ID key provides
 request identifier for the request.
                              
 
 
                              A GET_PURCHASE_INFORMATION request also triggers two asynchronous responses
-(broadcast intents). First, the Android Market application sends a RESPONSE_CODE
+(broadcast intents). First, the Google Play application sends a RESPONSE_CODE
 broadcast intent, which provides status and error information about the request. Next, if the
-request was successful, the Android Market application sends a PURCHASE_STATE_CHANGED
+request was successful, the Google Play application sends a PURCHASE_STATE_CHANGED
 broadcast intent. This message contains detailed transaction information. The transaction
 information is contained in a signed JSON string (unencrypted). The message includes the signature
 so you can verify the integrity of the signed string.
                              
@@ -783,8 +783,8 @@ request identifier for the request.
                              
 RESPONSE_CODE broadcast intent. This broadcast intent provides status and error
 information about the request.
                              
 
-
                              You must send a confirmation when you receive transaction information from Android Market. If you
-don't send a confirmation message, Android Market will continue sending
+
                              You must send a confirmation when you receive transaction information from Google Play. If you
+don't send a confirmation message, Google Play will continue sending
 IN_APP_NOTIFY messages for the transactions you have not confirmed. Also,
 your application must be able to handle IN_APP_NOTIFY messages that contain multiple
 orders.
                              
@@ -792,7 +792,7 @@ orders.
                              
 
                              In addition, as a best practice, you should not send a CONFIRM_NOTIFICATIONS request
 for a purchased item until you have delivered the item to the user. This way, if your application
 crashes or something else prevents your application from delivering the product, your application
-will still receive an IN_APP_NOTIFY broadcast intent from Android Market indicating
+will still receive an IN_APP_NOTIFY broadcast intent from Google Play indicating
 that you need to deliver the product.
                              
 
 
                              Restoring transaction information (RESTORE_TRANSACTIONS)
                              
@@ -817,7 +817,7 @@ three keys that are required for all requests: BILLING_REQUEST,
 API_VERSION, and PACKAGE_NAME. The additional REQUEST_NONCE
 key is then added to the bundle prior to invoking the sendBillingRequest() method. The
 REQUEST_NONCE key contains a cryptographically secure nonce (number used once) that you
-must generate. The Android Market application returns this nonce with the transactions information
+must generate. The Google Play application returns this nonce with the transactions information
 contained in the PURCHASE_STATE_CHANGED broadcast intent so you can verify the
 integrity of the transaction information.
                              
 
@@ -827,9 +827,9 @@ you with the status of the request and the REQUEST_ID key provides
 request identifier for the request.
                              
 
 
                              A RESTORE_TRANSACTIONS request also triggers two asynchronous responses (broadcast
-intents). First, the Android Market application sends a RESPONSE_CODE broadcast intent,
+intents). First, the Google Play application sends a RESPONSE_CODE broadcast intent,
 which provides status and error information about the request. Next, if the request was successful,
-the Android Market application sends a PURCHASE_STATE_CHANGED broadcast intent. This
+the Google Play application sends a PURCHASE_STATE_CHANGED broadcast intent. This
 message contains the detailed transaction information. The transaction information is contained in a
 signed JSON string (unencrypted). The message includes the signature so you can verify the integrity
 of the signed string.
                              
@@ -842,7 +842,7 @@ application has been removed from a device and reinstalled.
                              
 
 
                              You may also want your {@link android.app.Service} to receive intent messages from your {@link
 android.content.BroadcastReceiver}. You can use these intent messages to convey the information that
-was sent asynchronously from the Android Market application to your {@link
+was sent asynchronously from the Google Play application to your {@link
 android.content.BroadcastReceiver}. To see an example of how you can send and receive these intent
 messages, see the BillingReceiver.java and BillingService.java files in
 the sample application. You can use these samples as a basis for your own implementation. However,
@@ -851,16 +851,16 @@ href="{@docRoot}guide/market/billing/billing_best_practices.html">Security and D
 
 
                              Creating a BroadcastReceiver
                              
 
-
                              The Android Market application uses broadcast intents to send asynchronous billing responses to
+
                              The Google Play application uses broadcast intents to send asynchronous billing responses to
 your application. To receive these intent messages, you need to create a {@link
 android.content.BroadcastReceiver} that can handle the following intents:
                              
 
 
                
+  request and is returned by Google Play at the time a request is made.
 
-  
+  
@@ -933,16 +933,16 @@ public class BillingReceiver extends BroadcastReceiver {
 
   private static final String TAG = "BillingReceiver";
 
-  // Intent actions that we receive in the BillingReceiver from Android Market.
-  // These are defined by Android Market and cannot be changed.
+  // Intent actions that we receive in the BillingReceiver from Google Play.
+  // These are defined by Google Play and cannot be changed.
   // The sample application defines these in the Consts.java file.
   public static final String ACTION_NOTIFY = "com.android.vending.billing.IN_APP_NOTIFY";
   public static final String ACTION_RESPONSE_CODE = "com.android.vending.billing.RESPONSE_CODE";
   public static final String ACTION_PURCHASE_STATE_CHANGED =
     "com.android.vending.billing.PURCHASE_STATE_CHANGED";
 
-  // The intent extras that are passed in an intent from Android Market.
-  // These are defined by Android Market and cannot be changed.
+  // The intent extras that are passed in an intent from Google Play.
+  // These are defined by Google Play and cannot be changed.
   // The sample application defines these in the Consts.java file.
   public static final String NOTIFICATION_ID = "notification_id";
   public static final String INAPP_SIGNED_DATA = "inapp_signed_data";
@@ -974,7 +974,7 @@ public class BillingReceiver extends BroadcastReceiver {
 }
 
 
-
                In addition to receiving broadcast intents from the Android Market application, your {@link
+
                In addition to receiving broadcast intents from the Google Play application, your {@link
 android.content.BroadcastReceiver} must handle the information it received in the broadcast intents.
 Usually, your {@link android.content.BroadcastReceiver} does this by sending the information to a
 local service (discussed in the next section). The BillingReceiver.java file in the
@@ -985,8 +985,8 @@ href="{@docRoot}guide/market/billing/billing_best_practices.html">Security and D
 
 
                Verifying Signatures and Nonces
                
 
-
                Android Market's in-app billing service uses two mechanisms to help verify the integrity of the
-transaction information you receive from Android Market: nonces and signatures. A nonce (number used
+
                Google Play's in-app billing service uses two mechanisms to help verify the integrity of the
+transaction information you receive from Google Play: nonces and signatures. A nonce (number used
 once) is a cryptographically secure number that your application generates and sends with every
 GET_PURCHASE_INFORMATION and RESTORE_TRANSACTIONS request. The nonce is
 returned with the PURCHASE_STATE_CHANGED broadcast intent, enabling you to verify that
@@ -1023,12 +1023,12 @@ implementation, be sure to follow the guidelines in Security and Design and
 obfuscate your code.
                
 
-
                You will need to use your Android Market public key to perform the signature verification. The
-following procedure shows you how to retrieve Base64-encoded public key from the Android Market
+
                You will need to use your Google Play public key to perform the signature verification. The
+following procedure shows you how to retrieve Base64-encoded public key from the Google Play
 publisher site.
                
 
 
                  
-  
                1. Log in to your publisher account.
                  2. 
+  
                2. Log in to your publisher account.
                  3. 
   
                3. On the upper left part of the page, under your name, click Edit profile.
                  4. 
   
                4. On the Edit Profile page, scroll down to the Licensing & In-app Billing panel (see figure
   2).
                  5. 
@@ -1080,8 +1080,8 @@ unmanaged items is important because unmanaged items cannot be restored by using
 
 
                  Creating a user interface for selecting items
                  
 
-
                  You must provide users with a means for selecting items that they want to purchase. Android
-Market provides the checkout user interface (which is where the user provides a form of payment and
+
                  You must provide users with a means for selecting items that they want to purchase. Google
+Play provides the checkout user interface (which is where the user provides a form of payment and
 approves the purchase), but your application must provide a control (widget) that invokes the
 sendBillingRequest() method when a user selects an item for purchase.
                  
 
diff --git a/docs/html/guide/market/billing/billing_overview.jd b/docs/html/guide/market/billing/billing_overview.jd
index 8f9fd4c616ccb..b59381140eca1 100755
--- a/docs/html/guide/market/billing/billing_overview.jd
+++ b/docs/html/guide/market/billing/billing_overview.jd
@@ -38,24 +38,24 @@ parent.link=index.html
 
 
 
-
                  Android Market In-app Billing is an Android Market service that provides checkout processing for
+
                  In-app Billing is a Google Play service that provides checkout processing for
 in-app purchases. To use the service, your application sends a billing request for a specific in-app
 product. The service then handles all of the checkout details for the transaction, including
 requesting and validating the form of payment and processing the financial transaction. When the
 checkout process is complete, the service sends your application the purchase details, such as the
 order number, the order date and time, and the price paid. At no point does your application have to
-handle any financial transactions; that role is provided by Android Market's in-app billing
+handle any financial transactions; that role is provided by Google Play's in-app billing
 service.
                  
 
 
                  In-app Billing Architecture
                  
 
 
                  In-app billing uses an asynchronous message loop to convey billing requests and billing responses
-between your application and the Android Market server. In practice, your application never directly
-communicates with the Android Market server (see figure 1). Instead, your application sends billing
-requests to the Android Market application over interprocess communication (IPC) and receives
-purchase responses from the Android Market application in the form of asynchronous broadcast
-intents. Your application does not manage any network connections between itself and the Android
-Market server or use any special APIs from the Android platform.
                  
+between your application and the Google Play server. In practice, your application never directly
+communicates with the Google Play server (see figure 1). Instead, your application sends billing
+requests to the Google Play application over interprocess communication (IPC) and receives
+purchase responses from the Google Play application in the form of asynchronous broadcast
+intents. Your application does not manage any network connections between itself and the Google
+Play server or use any special APIs from the Android platform.
                  
 
 
                  Some in-app billing implementations may also use a private remote server to deliver content or
 validate transactions, but a remote server is not required to implement in-app billing. A remote
@@ -70,16 +70,16 @@ to security attacks.
                  
 
 
                  
   Figure 1. Your application sends and receives billing messages through the
-  Android Market application, which handles all communication with the Android Market server.
                  
+  Google Play application, which handles all communication with the Google Play server.
                  
 
 
 
                  A typical in-app billing implementation relies on three components:
                  
 
                
 
 
                Market billing issue trackerMarket billing
+Billing issue trackerBilling
 project issue tracker
 Bug and issue reports related specifically to in-app billing sample code.
 
                
 
 
 
 
 
   
   
   
   
   
 
 
 
 
 
 
 
 
                
   BillingReceiver.java
   A {@link android.content.BroadcastReceiver} that receives asynchronous response messages
-  (broadcast intents) from Android Market. Forwards all messages to the
+  (broadcast intents) from Google Play. Forwards all messages to the
   BillingService.
 
                
 
                
   BillingService.javaA {@link android.app.Service} that sends messages to Android Market on behalf of the
+  A {@link android.app.Service} that sends messages to Google Play on behalf of the
   application by connecting (binding) to the MarketBillingService.
 
                
 
 
                
 Consts.javaDefines various Android Market constants and sample application constants. All constants that
-are defined by Android Market must be defined the same way in your application.Defines various Google Play constants and sample application constants. All constants that
+are defined by Google Play must be defined the same way in your application.
 
                
 
 
                
 
 
 
 com.android.vending.billing.RESPONSE_CODE
   request_id
   A long representing a request ID. A request ID identifies a specific billing
-  request and is returned by Android Market at the time a request is made.
                
 
                
   com.android.vending.billing.RESPONSE_CODE
   response_codeAn int representing the actual Android Market server response code.An int representing the actual Google Play server response code.
 
                
 
                
   com.android.vending.billing.IN_APP_NOTIFY
   notification_id
   A String representing the notification ID for a given purchase state change.
-  Android Market notifies you when there is a purchase state change and the notification includes a
+  Google Play notifies you when there is a purchase state change and the notification includes a
   unique notification ID. To get the details of the purchase state change, you send the notification
   ID with the GET_PURCHASE_INFORMATION request.
 
                
 
@@ -80,13 +80,13 @@ codes returned by Android Market.
                
                   
-  
@@ -108,7 +108,7 @@ purchase an item from yourself, which is not allowed by Google Checkout.
 
 
                In-app Billing Service Interface
                
 
-
                The following section describes the interface for Android Market's in-app billing service. The
+
                The following section describes the interface for Google Play's in-app billing service. The
 interface is defined in the IMarketBillingService.aidl file, which is included with the
 in-app billing sample
@@ -144,7 +144,7 @@ pairs, which are summarized in table 2.
                
                   
-  
@@ -160,8 +160,8 @@ pairs, which are summarized in table 2.
                
                   
+  sell using Google Play's in-app billing service must have a unique product ID, which you
+  specify on the Google Play publisher site.
 
@@ -172,7 +172,7 @@ pairs, which are summarized in table 2.
                
                   
+  to verify the integrity of transaction responses form Google Play.
 
@@ -202,20 +202,20 @@ pairs, which are summarized in table 2.
                
 
                 
@@ -398,7 +398,7 @@ a PURCHASE_STATE_CHANGED intent.
                
                 
+  application's product list on the Google Play publisher site.
 
diff --git a/docs/html/guide/market/billing/billing_testing.jd b/docs/html/guide/market/billing/billing_testing.jd
index 5453047d96a83..77aa3edc51f76 100755
--- a/docs/html/guide/market/billing/billing_testing.jd
+++ b/docs/html/guide/market/billing/billing_testing.jd
@@ -32,16 +32,16 @@ parent.link=index.html
 
 
 
-
                The Android Market publisher site provides several tools that help you test your in-app billing
+
                The Google Play publisher site provides several tools that help you test your in-app billing
 implementation before it is published. You can use these tools to create test accounts and purchase
 special reserved items that send static billing responses to your application.
                
 
 
                To test in-app billing in an application you must install the application on an Android-powered
 device. You cannot use the Android emulator to test in-app billing.  The device you use for testing
 must run a standard version of the Android 1.6 or later platform (API level 4 or higher), and have
-the most current version of the Android Market application installed. If a device is not running the
-most current Android Market application, your application won't be able to send in-app billing
-requests to Android Market. For general information about how to set up a device for use in
+the most current version of the Google Play application installed. If a device is not running the
+most current Google Play application, your application won't be able to send in-app billing
+requests to Google Play. For general information about how to set up a device for use in
 developing Android applications, see Using Hardware
 Devices.
                
 
@@ -50,12 +50,12 @@ Devices.
                
 
                Testing in-app purchases with static responses
                
 
 
                We recommend that you first test your in-app billing implementation using static responses from
-Android Market. This enables you to verify that your application is handling the primary Android
-Market responses correctly and that your application is able to verify signatures correctly.
                
+Google Play. This enables you to verify that your application is handling the primary Google
+Play responses correctly and that your application is able to verify signatures correctly.
                
 
 
                To test your implementation with static responses, you make an in-app billing request using a
 special item that has a reserved product ID. Each reserved product ID returns a specific static
-response from Android Market. No money is transferred when you make in-app billing requests with the
+response from Google Play. No money is transferred when you make in-app billing requests with the
 reserved product IDs. Also, you cannot specify the form of payment when you make a billing request
 with a reserved product ID. Figure 1 shows the checkout flow for the reserved item that has the
 product ID android.test.purchased.
                
@@ -65,7 +65,7 @@ product ID android.test.purchased.
                
   Figure 1. Checkout flow for the special reserved item android.test.purchased.
 
                
 
-
                You do not need to list the reserved products in your application's product list. Android Market
+
                You do not need to list the reserved products in your application's product list. Google Play
 already knows about the reserved product IDs. Also, you do not need to upload your application to
 the publisher site to perform static response tests with the reserved product IDs. You can simply
 install your application on a device, log into the device, and make billing requests using the
@@ -75,24 +75,24 @@ reserved product IDs.
                
 
 
                  
   
                • android.test.purchased
-    
                  When you make an in-app billing request with this product ID, Android Market responds as
+    
                  When you make an in-app billing request with this product ID, Google Play responds as
     though you successfully purchased an item. The response includes a JSON string, which contains
     fake purchase information (for example, a fake order ID). In some cases, the JSON string is
     signed and the response includes the signature so you can test your signature verification
     implementation using these responses.
                  
   
                  • 
   
                • android.test.canceled
-    
                  When you make an in-app billing request with this product ID Android Market responds as
+    
                  When you make an in-app billing request with this product ID Google Play responds as
     though the purchase was canceled. This can occur when an error is encountered in the order
     process, such as an invalid credit card, or when you cancel a user's order before it is
     charged.
                  
   
                  • 
   
                • android.test.refunded
-    
                  When you make an in-app billing request with this product ID, Android Market responds as
-    though the purchase was refunded. Refunds cannot be initiated through Android Market's in-app
+    
                  When you make an in-app billing request with this product ID, Google Play responds as
+    though the purchase was refunded. Refunds cannot be initiated through Google Play's in-app
     billing service. Refunds must be initiated by you (the merchant). After you process a refund
     request through your Google Checkout account, a refund message is sent to your application by
-    Android Market. This occurs only when Android Market gets notification from Google Checkout that
+    Google Play. This occurs only when Google Play gets notification from Google Checkout that
     a refund has been made. For more information about refunds, see Handling
     IN_APP_NOTIFY messages and 
     Pricing.
                  
   
                  • 
   
                • android.test.item_unavailable
-    
                  When you make an in-app billing request with this product ID, Android Market responds as
+    
                  When you make an in-app billing request with this product ID, Google Play responds as
     though the item being purchased was not listed in your application's product list.
                  
   
                  • 
 
                
@@ -185,20 +185,20 @@ application's product list you use one of the reserved product IDs.
                
     
                You do not need to use a test account if you are testing only with the reserved product
     IDs.
                
   
-  
              10. Verify that your device is running a supported version of the Android Market
+  
              11. Verify that your device is running a supported version of the Google Play
   application or the MyApps application.
     
                If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of
     the MyApps application. If your device is running any other version of Android, in-app billing
-    requires version 2.3.4 (or higher) of the Android Market application. To learn how to check the
-    version of the Android Market application, see Updating Android
-    Market.
                
+    requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
+    version of the Google Play application, see Updating Google
+    Play.
                
   
                12. 
   
              12. Run your application and purchase the reserved product IDs.
                13. 
 
 
 
                Note: Making in-app billing requests with the reserved product IDs
-overrides the usual Android Market production system. When you send an in-app billing request for a
+overrides the usual Google Play production system. When you send an in-app billing request for a
 reserved product ID, the quality of service will not be comparable to the production
 environment.
                
 
@@ -207,7 +207,7 @@ environment.
                
 
                After you finish your static response testing, and you verify that signature verification is
 working in your application, you can test your in-app billing implementation by making actual in-app
 purchases. Testing real in-app purchases enables you to test the end-to-end in-app billing
-experience, including the actual responses from Android Market and the actual checkout flow that
+experience, including the actual responses from Google Play and the actual checkout flow that
 users will experience in your application.
                
 
 
                Note: You do not need to publish your application to do end-to-end
@@ -215,7 +215,7 @@ testing. You only need to upload your application as a draft application to perf
 testing.
                
 
 
                To test your in-app billing implementation with actual in-app purchases, you will need to
-register at least one test account on the Android Market publisher site. You cannot use your
+register at least one test account on the Google Play publisher site. You cannot use your
 developer account to test the complete in-app purchase process because Google Checkout does not let
 you buy items from yourself. If you have not set up test accounts before, see Setting up test
@@ -237,7 +237,7 @@ actual payouts to your merchant account.
                
     IDs; you only need to upload your application as a draft application. However, you must sign
     your application with your release key before you upload it as a draft application. Also, the
     version number of the uploaded application must match the version number of the application you
-    load to your device for testing. To learn how to upload an application to Android Market, see
+    load to your device for testing. To learn how to upload an application to Google Play, see
     Uploading
     applications.
                
   
@@ -257,7 +257,7 @@ actual payouts to your merchant account.
                
     
                To perform end-to-end testing of in-app billing, the primary account on your device must be
     one of the test accounts
-    that you registered on the Android Market site. If the primary account on your device is not a
+    that you registered on the Google Play site. If the primary account on your device is not a
     test account, you must do a factory reset of the device and then sign in with one of your test
     accounts. To perform a factory reset, do the following:
                
     
                  
@@ -269,14 +269,14 @@ actual payouts to your merchant account.
                  
       device setup process.
     
                
   
-  
              13. Verify that your device is running a supported version of the Android Market
+  
              14. Verify that your device is running a supported version of the Google Play
   application or the MyApps application.
     
                If your device is running Android 3.0, in-app billing requires version 5.0.12 (or higher) of
     the MyApps application. If your device is running any other version of Android, in-app billing
-    requires version 2.3.4 (or higher) of the Android Market application. To learn how to check the
-    version of the Android Market application, see Updating Android
-    Market.
                
+    requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
+    version of the Google Play application, see Updating Google
+    Play.
                
   
                15. 
   
              15. Make in-app purchases in your application.
                16. 
 
@@ -285,7 +285,7 @@ actual payouts to your merchant account.
                
 do a factory reset, making sure you log on with your primary account first.
                
 
 
                When you are finished testing your in-app billing implementation, you are ready to
-publish your application on Android Market. You can follow the normal steps for preparing, signing, and publishing your application.
diff --git a/docs/html/guide/market/billing/index.jd b/docs/html/guide/market/billing/index.jd
index fdfa6fa7ea943..036761f4e0998 100755
--- a/docs/html/guide/market/billing/index.jd
+++ b/docs/html/guide/market/billing/index.jd
@@ -30,18 +30,18 @@ page.title=In-app Billing
 
 
 
-
                Android Market In-app Billing is an Android Market service that lets you sell digital content in
+
                Google Play In-app Billing is a Google Play service that lets you sell digital content in
 your applications. You can use the service to sell a wide range of content, including downloadable
 content such as media files or photos, and virtual content such as game levels or potions.
                
 
-
                When you use Android Market's in-app billing service to sell an item, Android Market handles all
+
                When you use Google Play's in-app billing service to sell an item, Google Play handles all
 checkout details so your application never has to directly process any financial transactions.
-Android Market uses the same checkout service that is used for application purchases, so your users
+Google Play uses the same checkout service that is used for application purchases, so your users
 experience a consistent and familiar purchase flow (see figure 1). Also, the transaction fee for
 in-app purchases is the same as the transaction fee for application purchases (30%).
                
 
-
                Any application that you publish through Android Market can implement in-app billing. No special
-account or registration is required other than an Android Market publisher account and a Google
+
                Any application that you publish through Google Play can implement in-app billing. No special
+account or registration is required other than a Google Play app publisher account and a Google
 Checkout Merchant account. Also, because the service uses no dedicated framework APIs, you can add
 in-app billing to any application that uses a minimum API level of 4 or higher.
                
 
@@ -59,11 +59,11 @@ obfuscate the sample code before you use it in a production application. For mor
 
 
                
   Figure 1. Applications initiate in-app billing requests through their own UI
-  (first screen). Android Market responds to the request by providing the checkout user interface
+  (first screen). Google Play responds to the request by providing the checkout user interface
   (middle screen). When checkout is complete, the application resumes.
 
                
 
-
                To learn more about Android Market's in-app billing service and start integrating it into your
+
                To learn more about Google Play's in-app billing service and start integrating it into your
 applications, read the following documents:
                
 
 
                
@@ -88,7 +88,7 @@ applications, read the following documents:
                
     
                Learn how to set up your product list, register test accounts, and handle refunds.
                
   
                In-app Billing
   Reference
                
-    
                Get detailed information about Android Market response codes and the in-app billing
+    
                Get detailed information about Google Play response codes and the in-app billing
     interface.
                
 
                
 
diff --git a/docs/html/guide/market/expansion-files.jd b/docs/html/guide/market/expansion-files.jd
index fad30e9a27d29..26e63ecd6b6a7 100644
--- a/docs/html/guide/market/expansion-files.jd
+++ b/docs/html/guide/market/expansion-files.jd
@@ -8,7 +8,7 @@ page.title=APK Expansion Files
 
                  
   
                • Recommended for most apps that exceed the 50MB APK limit
                  • 
   
                • You can provide up to 4GB of additional data for each APK
                  • 
-  
                • Android Market hosts and serves the expansion files at no charge
                  • 
+  
                • Google Play hosts and serves the expansion files at no charge
                  • 
   
                • The files can be any file type you want and are saved to the device's shared storage
                  • 
 
                
 
@@ -61,28 +61,28 @@ APK Support
 
 
 
-
                Android Market currently requires that your APK file be no more than 50MB. For most
+
                Google Play currently requires that your APK file be no more than 50MB. For most
 applications, this is plenty of space for all the application's code and assets.
 However, some apps need more space for high-fidelity graphics, media files, or other large assets.
 Previously, if your app exceeded 50MB, you had to host and download the additional resources
 yourself when the user opens the app. Hosting and serving the extra files can be costly, and the
 user experience is often less than ideal. To make this process easier for you and more pleasant
-for users, Android Market allows you to attach two large expansion files that supplement your
+for users, Google Play allows you to attach two large expansion files that supplement your
 APK.
                
 
-
                Android Market hosts the expansion files for your application and serves them to the device at
+
                Google Play hosts the expansion files for your application and serves them to the device at
 no cost to you. The expansion files are saved to the device's shared storage location (the
 SD card or USB-mountable partition; also known as the "external" storage) where your app can access
-them. On most devices, Android Market downloads the expansion file(s) at the same time it
+them. On most devices, Google Play downloads the expansion file(s) at the same time it
 downloads the APK, so your application has everything it needs when the user opens it for the
-first time. In some cases, however, your application must download the files from Android Market
+first time. In some cases, however, your application must download the files from Google Play
 when your application starts.
                
 
 
 
 
                Overview
                
 
-
                Each time you upload an APK using the Android Market Developer Console, you have the option to
+
                Each time you upload an APK using the Google Play Android Developer Console, you have the option to
 add one or two expansion files to the APK. Each file can be up to 2GB and it can be any format you
 choose, but we recommend you use a compressed file to conserve bandwidth during the download.
 Conceptually, each expansion file plays a different role:
                
@@ -102,7 +102,7 @@ release or as necessary.
                
 
                However, even if your application update requires only a new patch expansion file, you still must
 upload a new APK with an updated {@code
-versionCode} in the manifest. (The Android Market
+versionCode} in the manifest. (The
 Developer Console does not allow you to upload an expansion file to an existing APK.)
                
 
 
                Note: The patch expansion file is semantically the same as the
@@ -115,7 +115,7 @@ yourself or be able to distinguish between the two files.
                
 
                File name format
                
 
 
                Each expansion file you upload can be any format you choose (ZIP, PDF, MP4, etc.). Regardless of
-the file type, Android Market considers them opaque binary blobs and renames the files
+the file type, Google Play considers them opaque binary blobs and renames the files
 using the following scheme:
                
 
 
                @@ -133,7 +133,7 @@ only one main file and one patch file for each APK.
 first associated (it matches the application's {@code android:versionCode}
 value).
-    
                "First" is emphasized because although the Android Market Developer Console allows you to
+    
                "First" is emphasized because although the Developer Console allows you to
 re-use an uploaded expansion file with a new APK, the expansion file's name does not change—it
 retains the version applied to it when you first uploaded the file.
                
   
                {@code <package-name>}
                 
@@ -147,9 +147,9 @@ upload a main expansion file, the file is renamed to:
                
 
 
                Storage location
                
 
-
                When Android Market downloads your expansion files to a device, it saves them to the system's
+
                When Google Play downloads your expansion files to a device, it saves them to the system's
 shared storage location. To ensure proper behavior, you must not delete, move, or rename the
-expansion files. In the event that your application must perform the download from Android Market
+expansion files. In the event that your application must perform the download from Google Play
 itself, you must save the files to the exact same location.
                
 
 
                The specific location for your expansion files is:
                
@@ -194,27 +194,27 @@ compressed: 
                
 
 
                Download process
                
 
-
                Most of the time, Android Market downloads and saves your expansion files at the same time it
-downloads the APK to the device. However, in some cases Android Market
+
                Most of the time, Google Play downloads and saves your expansion files at the same time it
+downloads the APK to the device. However, in some cases Google Play
 cannot download the expansion files or the user might have deleted previously downloaded expansion
 files. To handle these situations, your app must be able to download the files
-itself when the main activity starts, using a URL provided by Android Market.
                
+itself when the main activity starts, using a URL provided by Google Play.
                
 
 
                The download process from a high level looks like this:
                
 
 
                  
-  
                1. User selects to install your app from Android Market.
                  2. 
-  
                2. If Android Market is able to download the expansion files (which is the case for most
+  
                3. User selects to install your app from Google Play.
                  4. 
+  
                4. If Google Play is able to download the expansion files (which is the case for most
 devices), it downloads them along with the APK.
-     
                  If Android Market is unable to download the expansion files, it downloads the
+     
                  If Google Play is unable to download the expansion files, it downloads the
 APK only.
                  
   
                  5. 
   
                5. When the user launches your application, your app must check whether the expansion files are
 already saved on the device.
     
                    
       
                  1. If yes, your app is ready to go.
                    2. 
-      
                  2. If no, your app must download the expansion files over HTTP from Android Market. Your app
-must send a request to the Android Market client using the Android Market's If no, your app must download the expansion files over HTTP from Google Play. Your app
+must send a request to the Google Play client using the Google Play's Application Licensing service, which
 responds with the name, file size, and URL for each expansion file. With this information, you then
 download the files and save them to the proper storage location.
                    3. 
@@ -223,7 +223,7 @@ download the files and save them to the proper storag
 
                  
 
 
                  Caution: It is critical that you include the necessary code to
-download the expansion files from Android Market in the event that the files are not already on the
+download the expansion files from Google Play in the event that the files are not already on the
 device when your application starts. As discussed in the following section about Downloading the Expansion Files, we've made a library available to you that
 greatly simplifies this process and performs the download from a service with a minimal amount of
@@ -258,7 +258,7 @@ your expansion files, then read them using the APK Expansion Z
 Library.
                  
   
                  6. 
   
                6. Add logic to your application's main activity that checks whether the expansion files
-are on the device upon start-up. If the files are not on the device, use Android Market's Application Licensing service to request URLs
 for the expansion files, then download and save them.
     
                  To greatly reduce the amount of code you must write and ensure a good user experience
@@ -280,15 +280,15 @@ Your Expansion Files.
                  
 
                  Rules and Limitations
                  
 
 
                  Adding APK expansion files is a feature available when you upload your application using the
-Android Market Developer Console. When uploading your application for the first time or updating an
+Developer Console. When uploading your application for the first time or updating an
 application that uses expansion files, you must be aware of the following rules and limitations:
                  
 
 
                    
   
                  1. Each expansion file can be no more than 2GB.
                    2. 
-  
                  2. In order to download your expansion files from Android Market, the user must have
-acquired your application from Android Market. Android Market will not
+  
                  3. In order to download your expansion files from Google Play, the user must have
+acquired your application from Google Play. Google Play will not
 provide the URLs for your expansion files if the application was installed by other means.
                    4. 
-  
                  4. When performing the download from within your application, the URL that Android Market
+  
                  5. When performing the download from within your application, the URL that Google Play
 provides for each file is unique for every download and each one expires shortly after it is given
 to your application.
                    6. 
   
                  6. If you update your application with a new APK or upload ).
                    7. 
 directory                    . If you must unpack some data, save it into the location specified by {@link
 android.content.Context#getExternalFilesDir getExternalFilesDir()}.
   
                  7. Do not delete or rename the {@code .obb} expansion file (unless you're
-performing an update). Doing so will cause Android Market (or your app itself) to repeatedly
+performing an update). Doing so will cause Google Play (or your app itself) to repeatedly
 download the expansion file.
                    8. 
   
                  8. When updating an expansion file manually, you must delete the previous expansion file.
                    9. 
 
                  
@@ -328,11 +328,11 @@ download the expansion file.
                  7. 
 
 
                  Downloading the Expansion Files
                  
 
-
                  In most cases, Android Market downloads and saves your expansion files to the device at the same
+
                  In most cases, Google Play downloads and saves your expansion files to the device at the same
 time it installs or updates the APK. This way, the expansion files are available when your
 application launches for the first time. However, in some cases your app must download the
 expansion files itself by requesting them from a URL provided to you in a response
-from Android Market's Application Licensing service.
                  
 
 
                  The basic logic you need to download your expansion files is the following:
                  
@@ -345,15 +345,15 @@ href="#StorageLocation">shared storage location (in the
       
                7. If the expansion files are there, you're all set and your application can continue.
                  8. 
       
                8. If the expansion files are not there:
         
                    
-          
                  1. Perform a request using Android Market's Perform a request using Google Play's Application Licensing to get your
 app's expansion file names, sizes, and URLs.
                    2.  
-          
                  2. Use the URLs provided by Android Market to download the expansion files and save
+          
                  3. Use the URLs provided by Google Play to download the expansion files and save
 the expansion files. You must save the files to the shared storage location
 (Android/obb/<package-name>/) and use the exact file name provided
-by Android Market's response.
-            
                    Note: The URL that Android Market provides for your
+by Google Play's response.
+            
                    Note: The URL that Google Play provides for your
 expansion files is unique for every download and each one expires shortly after it is given to
 your application.
                    
           
                    4. 
@@ -368,16 +368,16 @@ your application.
                    
 href="{@docRoot}guide/market/licensing/index.html">Application Licensing service. It's primarily
 designed for you to enforce
 licensing policies for your application and ensure that the user has the right to
-use your app (he or she rightfully paid for it on Android Market). In order to facilitate the
+use your app (he or she rightfully paid for it on Google Play). In order to facilitate the
 expansion file functionality, the licensing service has been enhanced to provide a response
 to your application that includes the URL of your application's expansion files that are hosted
-on Android Market. So, even if your application is free for users, you need to include the Android
-Market License Verification Library (LVL) to use APK expansion files. Of course, if your application
+on Google Play. So, even if your application is free for users, you need to include the
+License Verification Library (LVL) to use APK expansion files. Of course, if your application
 is free, you don't need to enforce license verification—you simply need the
 library to perform the request that returns the URL of your expansion files.
                    
 
-
                    Note: Whether your application is free or not, Android Market
-returns the expansion file URLs only if the user acquired your application from Android Market.
                    
+
                    Note: Whether your application is free or not, Google Play
+returns the expansion file URLs only if the user acquired your application from Google Play.
                    
 
 
                    In addition to the LVL, you need a set of code that downloads the expansion files
 over an HTTP connection and saves them to the proper location on the device's shared storage.
@@ -464,7 +464,7 @@ Library. For each library:
 source and choose the library from the {@code <sdk>/extras/google/} directory
 ({@code market_licensing/} for the License Verification Library or {@code
 market_apk_expansion/downloader_library/} for the Downloader Library).
-      
                  4. Specify a Project Name such as "Android Market License Library" and "Market
+      
                  5. Specify a Project Name such as "Google Play License Library" and "Google Play
 Downloader
 Library"
                    6. 
       
                  6. Click Finish.
                    7. 
@@ -495,7 +495,7 @@ android update project --path ~/Android/MyApp \
 
 
                    With both the License Verification Library and Downloader Library added to your
 application, you'll be able to quickly integrate the ability to download expansion files from
-Android Market. The format that you choose for the expansion files and how you read them
+Google Play. The format that you choose for the expansion files and how you read them
 from the shared storage is a separate implementation that you should consider based on your
 application needs.
                    
 
@@ -518,10 +518,10 @@ are:
                    
 
 
                     <manifest ...>
-    <!-- Required to access Android Market Licensing -->
+    <!-- Required to access Google Play Licensing -->
     <uses-permission android:name="com.android.vending.CHECK_LICENSE" />
 
-    <!-- Required to download files from Android Market -->
+    <!-- Required to download files from Google Play -->
     <uses-permission android:name="android.permission.INTERNET" />
 
     <!-- Required to keep CPU alive while downloading files (NOT to keep screen awake) -->
@@ -570,7 +570,7 @@ DownloaderService} class and override three methods to provide specific applicat
 
                    
   
                    {@code getPublicKey()}
                    
     
                    This must return a string that is the Base64-encoded RSA public key for your publisher
-account, available from the profile page on the Android Market Developer Console (see Setting Up for Licensing).
                    
   
                    {@code getSALT()}
                    
     
                    This must return an array of random bytes that the licensing {@code Policy} uses to
@@ -589,7 +589,7 @@ restarted (which might happen if the downloader service unexpectedly stops).
                    
 public class SampleDownloaderService extends DownloaderService {
     // You must use the public key belonging to your publisher account
-    public static final String BASE64_PUBLIC_KEY = "YourAndroidMarketLVLKey";
+    public static final String BASE64_PUBLIC_KEY = "YourLVLKey";
     // You should also modify this salt
     public static final byte[] SALT = new byte[] { 1, 42, -12, -1, 54, 98,
             -100, -12, 43, 2, -8, -4, 9, 5, -106, -107, -33, 45, -1, 84
@@ -613,8 +613,8 @@ public class SampleDownloaderService extends DownloaderService {
 
                    
 
 
                    Notice: You must update the {@code BASE64_PUBLIC_KEY} value
-to be the public key belonging to your publisher account. You can find the key in the Android
-Market Developer Console under your profile information. This is necessary even when testing
+to be the public key belonging to your publisher account. You can find the key in the Developer
+Console under your profile information. This is necessary even when testing
 your downloads.
                    
 
 
                    Remember to declare the service in your manifest file:
                    
@@ -899,11 +899,11 @@ mRemoteService.setDownloadFlags(IDownloaderService.FLAGS_DOWNLOAD_OVER_CELLULAR)
 
 
                    Using APKExpansionPolicy
                    
 
-
                    If you decide to build your own downloader service instead of using the Android Market
+
                    If you decide to build your own downloader service instead of using the Google Play
 Downloader Library, you should still use the {@code
 APKExpansionPolicy} that's provided in the License Verification Library. The {@code
 APKExpansionPolicy} class is nearly identical to {@code ServerManagedPolicy} (available in the
-Android Market License Verification Library) but includes additional handling for the APK expansion
+Google Play License Verification Library) but includes additional handling for the APK expansion
 file response extras.
                    
 
 
                    Note: If you do use the 
 
 
                    Testing file reads
                    
 
-
                    Before you upload your application to Android Market, you
+
                    Before you upload your application to Google Play, you
 should test your application's ability to read the files from the shared storage. All you need to do
 is add the files to the appropriate location on the device shared storage and launch your
 application:
                    
 
 
                      
-  
                    1. On your device, create the appropriate directory on the shared storage where Android
-Market will save your files.
+  
                    2. On your device, create the appropriate directory on the shared storage where Google
+Play will save your files.
   
                      For example, if your package name is {@code com.example.android}, you need to create
 the directory {@code Android/obb/com.example.android/} on the shared storage space. (Plug in
 your test device to your computer to mount the shared storage and manually create this
 directory.)
                      
   
                      3. 
   
                    3. Manually add the expansion files to that directory. Be sure that you rename your files to
-match the file name format that Android Market will use.
+match the file name format that Google Play will use.
   
                      For example, regardless of the file type, the main expansion file for the {@code
 com.example.android} application should be {@code main.0300110.com.example.android.obb}.
 The version code can be whatever value you want. Just remember:
                      
@@ -1166,7 +1166,7 @@ The version code can be whatever value you want. Just remember:
                      
     
                    4. The main expansion file always starts with {@code main} and the patch file starts with
 {@code patch}.
                      5. 
     
                    5. The package name always matches that of the APK to which the file is attached on
-Android Market.
+Google Play.
   
   
                      6. 
   
                    6. Now that the expansion file(s) are on the device, you can install and run your application to
@@ -1176,7 +1176,7 @@ test your expansion file(s).
                      7. 
 
                      Here are some reminders about handling the expansion files:
                      
 
                        
   
                      • Do not delete or rename the {@code .obb} expansion files (even if you unpack
-the data to a different location). Doing so will cause Android Market (or your app itself) to
+the data to a different location). Doing so will cause Google Play (or your app itself) to
 repeatedly download the expansion file.
                        • 
   
                      • Do not save other data into your obb/
 directory. If you must unpack some data, save it into the location specified by {@link
@@ -1192,16 +1192,16 @@ opens, it's important that you test this process to be sure your application can
 for the URLs, download the files, and save them to the device.
                        
 
 
                        To test your application's implementation of the manual download procedure, you must upload
-your application to Android Market as a "draft" to make your expansion files available for
+your application to Google Play as a "draft" to make your expansion files available for
 download:
                        
 
 
                          
-  
                        1. Upload your APK and corresponding expansion files using the Android Market Developer
+  
                        2. Upload your APK and corresponding expansion files using the Google Play Developer
 Console.
                          3. 
   
                        3. Fill in the necessary application details (title, screenshots, etc.). You can come back and
 finalize these details before publishing your application.
   
                          Click the Save button. Do not click Publish. This saves
-the application as a draft, such that your application is not published for Android Market users,
+the application as a draft, such that your application is not published for Google Play users,
 but the expansion files are available for you to test the download process.
                          4. 
   
                        4. Install the application on your test device using the Eclipse tools or {@code adb}.
                          5. 
@@ -1216,14 +1216,14 @@ files as soon as the main activity starts.
                          
 
 
                          Updating Your Application
                          
 
-
                          One of the great benefits to using expansion files on Android Market is the ability to
-update your application without re-downloading all of the original assets. Because Android Market
+
                          One of the great benefits to using expansion files on Google Play is the ability to
+update your application without re-downloading all of the original assets. Because Google Play
 allows you to provide two expansion files with each APK, you can use the second file as a "patch"
 that provides updates and new assets. Doing so avoids the
 need to re-download the main expansion file which could be large and expensive for users.
                          
 
 
                          The patch expansion file is technically the same as the main expansion file and neither
-the Android system nor Android Market perform actual patching between your main and patch expansion
+the Android system nor Google Play perform actual patching between your main and patch expansion
 files. Your application code must perform any necessary patches itself.
                          
 
 
                          If you use ZIP files as your expansion files, the APK Expansion Zip
@@ -1232,13 +1232,13 @@ your
 patch file with the main expansion file.
                          
 
 
                          Note: Even if you only need to make changes to the patch
-expansion file, you must still update the APK in order for Android Market to perform an update.
+expansion file, you must still update the APK in order for Google Play to perform an update.
 If you don't require code changes in the application, you should simply update the {@code versionCode} in the
 manifest.
                          
 
 
                          As long as you don't change the main expansion file that's associated with the APK
-in the Android Market Developer Console, users who previously installed your application will not
+in the Developer Console, users who previously installed your application will not
 download the main expansion file. Existing users receive only the updated APK and the new patch
 expansion file (retaining the previous main expansion file).
                          
 
@@ -1246,7 +1246,7 @@ expansion file (retaining the previous main expansion file).
                          
 
 
                            
   
                          • There can be only two expansion files for your application at a time. One main expansion
-file and one patch expansion file. During an update to a file, Android Market deletes the
+file and one patch expansion file. During an update to a file, Google Play deletes the
 previous version (and so must your application when performing manual updates).
                            • 
   
                          • When adding a patch expansion file, the Android system does not actually patch your
 application or main expansion file. You must design your application to support the patch data.
diff --git a/docs/html/guide/market/licensing/adding-licensing.jd b/docs/html/guide/market/licensing/adding-licensing.jd
index d1fe8395db293..d4dd008bcf7c2 100644
--- a/docs/html/guide/market/licensing/adding-licensing.jd
+++ b/docs/html/guide/market/licensing/adding-licensing.jd
@@ -82,7 +82,7 @@ and Interfaces.
                            
 
 
                            Adding the Licensing Permission
                            
 
-
                            To use the Android Market application for sending a license check to the
+
                            To use the Google Play application for sending a license check to the
 server, your application must request the proper permission,
 com.android.vending.CHECK_LICENSE. If your application does
 not declare the licensing permission but attempts to initiate a license check,
@@ -101,7 +101,7 @@ android:name="com.android.vending.CHECK_LICENSE">
                            
 
                            <?xml version="1.0" encoding="utf-8"?>
 
 <manifest xmlns:android="http://schemas.android.com/apk/res/android" ...">
-    <!-- Devices >= 3 have version of Android Market that supports licensing. -->
+    <!-- Devices >= 3 have version of Google Play that supports licensing. -->
     <uses-sdk android:minSdkVersion="3" />
     <!-- Required permission to check licensing. -->
     <uses-permission android:name="com.android.vending.CHECK_LICENSE" />
@@ -123,7 +123,7 @@ application's manifest. 
                            
 
                            ServerManagedPolicy
                            
 
 
                            The LVL includes a complete {@code Policy} implementation called ServerManagedPolicy
-that makes use of license-management settings provided by the Android Market
+that makes use of license-management settings provided by the Google Play
 server. 
                            
 
 
                            Use of ServerManagedPolicy as the basis for your
@@ -133,7 +133,7 @@ href="#ServerManagedPolicy">ServerManagedPolicy section, below.
                            
 
 
 
-
                            Android Market licensing service does not itself determine whether a
+
                            Google Play licensing service does not itself determine whether a
 given user with a given license should be granted access to your application.
 Rather, that responsibility is left to a {@code Policy} implementation that you provide
 in your application.
                            
@@ -227,7 +227,7 @@ extra is highly recommended. See Server Response Extras
 for more information.
                            • 
 
                          • Uses an exponential backoff period, if retrying any requests the result in
-errors. Note that the Android Market client automatically retries failed
+errors. Note that the Google Play client automatically retries failed
 requests, so in most cases there is no need for your {@code Policy} to retry them.
                            • 
 
                          • Provides for a "grace period" that allows the user to access your
 application for a limited time or number of uses, while a license check is being
@@ -286,7 +286,7 @@ responses.
                            
 
                            Importantly, a key feature of ServerMangedPolicy is its use of
 server-provided settings as the basis for managing licensing across an
 application's refund period and through varying network and error conditions.
-When an application contacts the Android Market server for a license check, the
+When an application contacts the Google Play server for a license check, the
 server appends several settings as key-value pairs in the extras field of certain
 license response types. For example, the server provides recommended values for the
 application's license validity period, retry grace period, and maximum allowable
@@ -298,7 +298,7 @@ href="{@docRoot}guide/market/licensing/licensing-reference.html#extras">Server R
 Extras.
                            
 
 
                            For convenience, best performance, and the benefit of using license settings
-from the Android Market server, using ServerManagedPolicy as your
+from the Google Play server, using ServerManagedPolicy as your
 licensing {@code Policy} is strongly recommended. 
                            
 
 
                            If you are concerned about the security of license response data that is
@@ -446,7 +446,7 @@ the device IMEI or related data, the application will also need to request the
 
 
                            Before requesting new permissions for the sole purpose of acquiring
 device-specific information for use in your {@code Obfuscator}, consider
-how doing so might affect your application or its filtering on Android Market
+how doing so might affect your application or its filtering on Google Play
 (since some permissions can cause the SDK build tools to add
 the associated <uses-feature>).
                            
 
@@ -647,11 +647,11 @@ have determined the exact behaviors you want, you can add more complex handling.
 
                          • Display a "Try again" dialog to the user, including a button to initiate a
 new license check if the reason supplied is {@code Policy.RETRY}. 
                            • 
 
                          • Display a "Purchase this application" dialog, including a button that
-deep-links the user to the application's details page on Market, from which the
+deep-links the user to the application's details page on Google Play, from which the
 use can purchase the application. For more information on how to set up such
 links, see Using Intents to
-Launch the Market Application on a Device. 
                            • 
+href="{@docRoot}guide/publishing/publishing.html#marketintent">Linking to your apps
+on Google Play. 
 
                          • Display a Toast notification that indicates that the features of the
 application are limited because it is not licensed. 
                            • 
 
                          
@@ -688,7 +688,7 @@ private class MyLicenseCheckerCallback implements LicenseCheckerCallback {
             // Your response should always inform the user that the application
             // is not licensed, but your behavior at that point can vary. You might
             // provide the user a limited access version of your app or you can
-            // take them to Android Market to purchase the app.
+            // take them to Google Play to purchase the app.
             showDialog(DIALOG_GOTOMARKET);
         }
     }
@@ -707,16 +707,16 @@ method should log the error code and call dontAllow().
                          
 
                          Create a Handler for posting from LicenseCheckerCallback
 to the UI thread
                          
 
-
                          During a license check, the LVL passes the request to the Android Market
+
                          During a license check, the LVL passes the request to the Google Play
 application, which handles communication with the licensing server. The LVL
 passes the request over asynchronous IPC (using {@link android.os.Binder}) so
 the actual processing and network communication do not take place on a thread
-managed by your application. Similarly, when the Android Market application
+managed by your application. Similarly, when the Google Play application
 receives the result, it invokes a  callback method over IPC, which in turn
 executes in an IPC thread pool in your application's process.
                          
 
 
                          The {@code LicenseChecker} class manages your application's IPC communication with
-the Android Market application, including the call that sends the request and
+the Google Play application, including the call that sends the request and
 the callback that receives the response. {@code LicenseChecker} also tracks open license
 requests and manages their timeouts. 
                          
 
@@ -858,14 +858,14 @@ sample application calls checkAccess() from a
 
 
                          Embed your public key for licensing
                          
 
-
                          For each publisher account, the Android Market service automatically
+
                          For each publisher account, the Google Play service automatically
 generates a  2048-bit RSA public/private key pair that is used exclusively for
 licensing. The key pair is uniquely associated with the publisher account and is
 shared across all applications that are published through the account. Although
 associated with a publisher account, the key pair is not the same as
 the key that you use to sign your applications (or derived from it).
                          
 
-
                          The Android Market publisher site exposes the public key for licensing to any
+
                          The Google Play publisher site exposes the public key for licensing to any
 developer signed in to the publisher account, but it keeps the private key
 hidden from all users in a secure location. When an application requests a
 license check for an application published in your account, the licensing server
@@ -878,8 +878,8 @@ public key for licensing and copy it into your application. Here's how to find
 your account's public key for licensing:
                          
 
 
                            
-
                          1. Go to the Android Market publisher site and sign in.
+
                          2. Go to the Google Play publisher site and sign in.
 Make sure that you sign in to the account from which the application you are
 licensing is published (or will be published). 
                            3. 
 
                          3. In the account home page, locate the "Edit profile" link and click it. 
                            4. 
@@ -907,7 +907,7 @@ to close IPC connections
 {@link android.content.Context} changes, add a call to the {@code LicenseChecker}'s
 onDestroy() method from your Activity's
 {@link android.app.Activity#onDestroy()} implementation. The call causes the
-{@code LicenseChecker} to properly close any open IPC connection to the Android Market
+{@code LicenseChecker} to properly close any open IPC connection to the Google Play
 application's ILicensingService and removes any local references to the service
 and handler.
                            
 
@@ -992,13 +992,13 @@ and then recompile it.
                            
 
                            Several obfuscator programs are available for Android applications, including
 ProGuard, which also offers
 code-optimization features. The use of ProGuard or a similar program to obfuscate
-your code is strongly recommended for all applications that use Android
-Market Licensing. 
                            
+your code is strongly recommended for all applications that use Google
+Play Licensing. 
                            
 
 
                            Publishing a Licensed Application
                            
 
 
                            When you are finished testing your license implementation, you are ready to
-publish the application on Android Market. Follow the normal steps to prepare, sign, and then publish the application.
@@ -1021,7 +1021,7 @@ table below. By directing your queries to the correct forum, you can get the
 support you need more quickly. 
                            
 
 
                            Table 2. Developer support resources
-for Android Market Licensing Service.
                            
+for Google Play Licensing Service.
                            
 
 
                RESULT_BILLING_UNAVAILABLE
   3
   Indicates that in-app billing is not available because the API_VERSION that you
-  specified is not recognized by the Android Market application or the user is ineligible for in-app
+  specified is not recognized by the Google Play application or the user is ineligible for in-app
   billing (for example, the user resides in a country that prohibits in-app purchases).
 
                
 
                
   RESULT_ITEM_UNAVAILABLE
   4Indicates that Android Market cannot find the requested item in the application's product
+  Indicates that Google Play cannot find the requested item in the application's product
   list. This can happen if the product ID is misspelled in your REQUEST_PURCHASE
   request or if an item is unpublished in the application's product list.
 
                int
   1
   YesThe version of Android Market's in-app billing service you are using. The current version is
+  The version of Google Play's in-app billing service you are using. The current version is
   1.
 
                
 
                Any valid product identifier.
   Required for REQUEST_PURCHASE requests.
   The product ID of the item you are making a billing request for. Every in-app item that you
-  sell using Android Market's in-app billing service must have a unique product ID, which you
-  specify on the Android Market publisher site.
                
 
                
   NONCEA number used once. Your application must generate and send a nonce with each
   GET_PURCHASE_INFORMATION and RESTORE_TRANSACTIONS request. The nonce is
   returned with the PURCHASE_STATE_CHANGED broadcast intent, so you can use this value
-  to verify the integrity of transaction responses form Android Market.
                
 
                
   NOTIFY_IDS
                
   nonce
   A number used once. Your application generates the nonce and sends it with the
-  GET_PURCHASE_INFORMATION request. Android Market sends the nonce back as part of the
+  GET_PURCHASE_INFORMATION request. Google Play sends the nonce back as part of the
   JSON string so you can verify the integrity of the message.
 
                
 
                
   notificationId
   A unique identifier that is sent with an IN_APP_NOTIFY broadcast intent. Each
   notificationId corresponds to a specify message that is waiting to be retrieved on
-  the Android Market server. Your application sends back the notificationId with the
-  GET_PURCHASE_INFORMATION message so Android Market can determine which messages you
+  the Google Play server. Your application sends back the notificationId with the
+  GET_PURCHASE_INFORMATION message so Google Play can determine which messages you
   are retrieving.
 
                
 
                
   productId
   The item's product identifier. Every item has a product ID, which you must specify in the
-  application's product list on the Android Market publisher site.
                
 
                
   purchaseTime
                
 
@@ -1045,8 +1045,8 @@ href="http://stackoverflow.com/questions/tagged/android">http://stackoverflow.co
 
 
-
+
diff --git a/docs/html/guide/market/licensing/index.jd b/docs/html/guide/market/licensing/index.jd
index f08176d57101c..b9a71540e7d7f 100644
--- a/docs/html/guide/market/licensing/index.jd
+++ b/docs/html/guide/market/licensing/index.jd
@@ -2,9 +2,9 @@ page.title=Application Licensing
 @jd:body
 
 
-
                Android Market offers a licensing service that lets you enforce licensing policies for
-applications that you publish on Android Market. With Android Market Licensing, your application can
-query Android Market at run time to obtain the licensing status for the current user, then allow or
+
                Google Play offers a licensing service that lets you enforce licensing policies for
+applications that you publish on Google Play. With Google Play Licensing, your application can
+query Google Play at run time to obtain the licensing status for the current user, then allow or
 disallow further use as appropriate. 
                
 
 
                Using the service, you can apply a flexible licensing policy on an application-by-application
@@ -15,26 +15,26 @@ that allow the user to run it unlicensed for a specific validity period. An appl
 restrict use of the application to a specific device, in addition to any other constraints. 
                
 
 
                The licensing service is a secure means of controlling access to your applications. When an
-application checks the licensing status, the Android Market server signs the licensing status
+application checks the licensing status, the Google Play server signs the licensing status
 response using a key pair that is uniquely associated with the publisher account. Your application
 stores the public key in its compiled .apk file and uses it to verify the licensing
 status response.
                
 
-
                Any application that you publish through Android Market can use the Android Market Licensing
+
                Any application that you publish through Google Play can use the Google Play Licensing
 service. No special account or registration is needed. Additionally, because the service uses no
 dedicated framework APIs, you can add licensing to any application that uses a minimum API level of
 3 or higher.
                
 
-
                Note: The Android Market Licensing service is primarily intended
+
                Note: The Google Play Licensing service is primarily intended
 for paid applications that wish to verify that the current user did in fact pay for the application
-on Android Market. However, any application (including free apps) may use the licensing service
+on Google Play. However, any application (including free apps) may use the licensing service
 to initiate the download of an APK expansion file. In which case, the request that your application
 sends to the licensing service is not to check whether the user paid for the app, but to request the
 URL of the expansion files. For information about downloading expansion files for your application,
 read the guide to APK Expansion Files.
                
 
 
-
                To learn more about Android Market's application licensing service and start integrating it into
+
                To learn more about Google Play's application licensing service and start integrating it into
 your applications, read the following documents:
                
 
 
                
@@ -44,7 +44,7 @@ Overview
 like.
   
                Setting Up for
 Licensing
                
-    
                Explains how to set up your Android Market account, development environment, and
+    
                Explains how to set up your Google Play account, development environment, and
 testing environment in order to add licensing to your app.
                
   
                Adding
 Licensing to Your App
                
diff --git a/docs/html/guide/market/licensing/licensing-reference.jd b/docs/html/guide/market/licensing/licensing-reference.jd
index ac5d59618b221..0a7e03331b8e8 100644
--- a/docs/html/guide/market/licensing/licensing-reference.jd
+++ b/docs/html/guide/market/licensing/licensing-reference.jd
@@ -117,7 +117,7 @@ managed by an Obfuscator.
 
                
+Google Play client.
 
@@ -137,7 +137,7 @@ codes. By default, the LicenseValidator class in the LVL provides all of the
 necessary handling of these response codes for you. 
                
 
 
                Table 2. Summary of response codes
-returned by the Android Market server in a license response.
                
+returned by the Google Play server in a license response.
                
 
 
                
 Accounts, publishing, and deployment issuesAndroid
-Market Help ForumGoogle Play
+Help Forum
 Publisher accounts, licensing key pair, test accounts, server
 responses, test responses, application deployment and results
 
                
 ILicensingService
 One-way IPC interface over which a license check request is passed to the
-Android Market client.
                
 
                
 ILicenseResultListener
                
 
@@ -178,7 +178,7 @@ until upgrade.
                
 
                 
-
@@ -217,12 +217,12 @@ application. 
 
+Google Play. 
 
@@ -233,7 +233,7 @@ implementation.
                
 href="{@docRoot}guide/market/licensing/setting-up.html#test-env">
 Setting Up The Testing Environment, the response code can be manually
 overridden for the application developer and any registered test users via the
-Android Market publisher site.
+Google Play publisher site.
 

                
 Additionally, as noted above, applications that are in draft mode (in other
 words, applications that have been uploaded but have never been
@@ -263,7 +263,7 @@ implementation and an illustration of how to obtain, store, and use the
 settings. 
                
 
 
                Table 3. Summary of
-license-management settings supplied by the Android Market server in a license
+license-management settings supplied by the Google Play server in a license
 response.
                
 
 
                
 {@code ERROR_CONTACTING_SERVER}Local error — the Android Market application was not able to reach the
+Local error — the Google Play application was not able to reach the
 licensing server, possibly because of network availability problems. 
 No
 
                
 {@code ERROR_NOT_MARKET_MANAGED}
 Server error — the application (package name) was not recognized by
-Android Market. No
 
 Do not retry the license check.
 
                Can indicate that the application was not published
-through Android Market or that there is an development error in the licensing
+through Google Play or that there is an development error in the licensing
 implementation.
                
                 		
 
                
@@ -329,7 +329,7 @@ storage location before downloading.
 
 
                License validity period
                
 
-
                The Android Market licensing server sets a license validity period for all
+
                The Google Play licensing server sets a license validity period for all
 downloaded applications. The period expresses the interval of time over which an
 application's license status should be considered as unchanging and cacheable by
 a licensing {@code Policy} in the application. The licensing server includes the
@@ -351,7 +351,7 @@ status instead of sending a new license check to the server.
                
 
 
                The licensing server manages the validity period as a means of helping the
 application properly enforce licensing across the refund period offered by
-Android Market for paid applications. It sets the validity period based on
+Google Play for paid applications. It sets the validity period based on
 whether the application was purchased and, if so, how long ago. Specifically,
 the server sets a validity period as follows:
                
 
@@ -381,15 +381,15 @@ the application. 
                
 
 
                In some cases, system or network conditions can prevent an application's
 license check from reaching the licensing server, or prevent the server's
-response from reaching the Android Market client application. For example, the
+response from reaching the Google Play client application. For example, the
 user might launch an application when there is no cell network or data
 connection available—such as when on an airplane—or when the
 network connection is unstable or the cell signal is weak. 
                
 
-
                When network problems prevent or interrupt a license check, the Android
-Market client notifies the application by returning a {@code RETRY} response code to
+
                When network problems prevent or interrupt a license check, the Google
+Play client notifies the application by returning a {@code RETRY} response code to
 the {@code Policy}'s processServerResponse() method. In the case of system
-problems, such as when the application is unable to bind with Android Market's
+problems, such as when the application is unable to bind with Google Play's
 {@code ILicensingService} implementation, the {@code LicenseChecker} library itself calls the
 Policy processServerResonse() method with a {@code RETRY} response code.
 
                
@@ -397,7 +397,7 @@ Policy processServerResonse() method with a {@code RETRY} response
 
                In general, the {@code RETRY} response code is a signal to the application that an
 error has occurred that has prevented a license check from completing.
 
-
                The Android Market server helps an application to manage licensing under
+
                The Google Play server helps an application to manage licensing under
 error conditions by setting a retry "grace period" and a recommended maximum
 retries count. The server includes these values in all license check responses,
 appending them as extras under the keys {@code GT} and {@code GR}. 
                
diff --git a/docs/html/guide/market/licensing/overview.jd b/docs/html/guide/market/licensing/overview.jd
index 3576e26653faf..05a3a409fa78a 100644
--- a/docs/html/guide/market/licensing/overview.jd
+++ b/docs/html/guide/market/licensing/overview.jd
@@ -9,9 +9,9 @@ parent.link=index.html
   
   
                Quickview
                
   
                  
-    
                • Licensing allows you to verify your app was purchased from Android Market
                  • 
+    
                • Licensing allows you to verify your app was purchased from Google Play
                  • 
     
                • Your app maintains control of how it enforces its licensing status
                  • 
-    
                • The service is free for all developers who publish on Android Market
                  • 
+    
                • The service is free for all developers who publish on Google Play
                  • 
   
                
   
   
                In this document
                
@@ -26,19 +26,19 @@ parent.link=index.html
 
 
 
-
                Android Market Licensing is a network-based service that lets an application query a trusted
-Android Market licensing server to determine whether the application is licensed to the current
-device user. The licensing service is based on the capability of the Android Market licensing server
-to determine whether a given user is licensed to use a given application. Android Market considers a
+
                Google Play Licensing is a network-based service that lets an application query a trusted
+Google Play licensing server to determine whether the application is licensed to the current
+device user. The licensing service is based on the capability of the Google Play licensing server
+to determine whether a given user is licensed to use a given application. Google Play considers a
 user to be licensed if the user is a recorded purchaser of the application.
                
 
 
                The request starts when your application makes a request to a service hosted by
-the Android Market client application. The Android Market application then sends a request to
-the licensing server and receives the result. The Android Market application sends
+the Google Play client application. The Google Play application then sends a request to
+the licensing server and receives the result. The Google Play application sends
 the result to your application, which can allow or disallow further use of the
 application as needed.
                
 
-
                Note: If a paid application has been uploaded to Android Market but
+
                Note: If a paid application has been uploaded to Google Play but
 saved only as a draft application (the app is unpublished), the licensing server considers all users
 to be licensed users of the application (because it's not even possible to purchase the app).
 This exception is necessary in order for you to perform testing of your licensing
@@ -48,39 +48,39 @@ implementation.
                
 
                
 
 
                Figure 1. Your application initiates a
-license check through the License Verification Library and the Android Market
-client, which handles communication with the Market server.
                
+license check through the License Verification Library and the Google Play
+client, which handles communication with the Google Play server.
                
 
                
 
 
 
                To properly identify the user and determine the license status, the licensing server requires
-information about the application and user—your application and the Android Market client work
-together to assemble the information and the Android Market client passes it to the server. 
                
+information about the application and user—your application and the Google Play client work
+together to assemble the information and the Google Play client passes it to the server. 
                
 
 
                To help you add licensing to your application, the Android SDK provides a downloadable set of
-library sources that you can include in your application project: the "Google Market Billing
+library sources that you can include in your application project: the "Google Market Licensing
 package." The License Verification Library (LVL) is a library you can add to your application that
-handles all of the licensing-related communication with the Android Market licensing service. With
+handles all of the licensing-related communication with the Google Play licensing service. With
 the LVL added to your application, your application can determine its licensing status for the
 current user by simply calling a method and implementing a callback that receives the status
 response.
                
 
 
                Your application does not query the licensing server
-directly, but instead calls the Android Market client over remote IPC to
+directly, but instead calls the Google Play client over remote IPC to
 initiate a license request. In the license request:
                
 
 
                  
 
                • Your application provides: its package name, a nonce that is later used to
 validate any response from the server, and a callback over which the
 response can be returned asynchronously.
                  • 
-
                • The Android Market client collects the necessary information about the user and the device,
+
                • The Google Play client collects the necessary information about the user and the device,
 such as the device's primary Google account username, IMSI, and other
 information. It then sends the license check request to the server on behalf of
 your application.
                  • 
-
                • The Android Market server evaluates the request using all available information, attempting
+
                • The Google Play server evaluates the request using all available information, attempting
 to establish the user's identity to a sufficient level of confidence. The server
 then checks the user identity against purchase records for your application and
-returns a license response, which the Android Market client returns to your
+returns a license response, which the Google Play client returns to your
 application over the IPC callback.
                  • 
 
                
 
@@ -97,7 +97,7 @@ network connections or use any licensing related APIs in the Android platform.License Responses are Secure
 
 
                To ensure the integrity of each license query, the server signs the license
-response data using an RSA key pair that is shared exclusively between the Android Market
+response data using an RSA key pair that is shared exclusively between the Google Play
 server and you.
                
 
 
                The licensing service generates a single licensing key pair for each
@@ -120,7 +120,7 @@ tampered with or that are spoofed.
                
 which includes the License Verification Library (LVL). The LVL greatly simplifies the process of
 adding licensing to your application and helps ensure a more secure, robust implementation for your
 application. The LVL provides internal classes that handle most of the standard operations of a
-license query, such as contacting the Android Market client to initiate a license request and
+license query, such as contacting the Google Play client to initiate a license request and
 verifying and validating the responses. It also exposes interfaces that let you easily plug in your
 custom code for defining licensing policy and managing access as needed by your application. The key
 LVL interfaces are: 
                
@@ -179,17 +179,17 @@ physical device.
                
 
 
                Requirements and Limitations
                
 
-
                Android Market Licensing is designed to let you apply license controls to
-applications that you publish through Android Market. The service is not
+
                Google Play Licensing is designed to let you apply license controls to
+applications that you publish through Google Play. The service is not
 designed to let you control access to applications that are not published
-through Android Market or that are run on devices that do not offer the Android
-Market client. 
                
+through Google Play or that are run on devices that do not offer the Google
+Play client. 
                
 
 
                Here are some points to keep in mind as you implement licensing in your
 application: 
                
 
 
                  
-
                • An application can use the service only if the Android Market client is
+
                • An application can use the service only if the Google Play client is
 installed on its host device and the device is running Android 1.5 (API level 3)
 or higher.
                  • 
 
                • To complete a license check, the licensing server must be accessible over
@@ -202,7 +202,7 @@ handling of the license are factors are up to you. By following the best
 practices in the following documents, you can help ensure that your implementation will be
 secure.
                  • 
 
                • Adding licensing to an application does not affect the way the application
-functions when run on a device that does not offer Android Market.
                  • 
+functions when run on a device that does not offer Google Play.
 
                • You can implement licensing controls for a free app, but only if you're using the service to 
 provide APK expansion files.
                  • 
@@ -212,20 +212,20 @@ href="{@docRoot}guide/market/expansion-files.html">APK expansion files.
 
 
                  Replacement for Copy Protection
                  
 
-
                  Android Market Licensing is a flexible, secure mechanism for controlling
+
                  Google Play Licensing is a flexible, secure mechanism for controlling
 access to your applications. It effectively replaces the Copy Protection
-mechanism offered on Android Market and gives you wider distribution
+mechanism offered on Google Play and gives you wider distribution
 potential for your applications. 
                  
 
 
                    
-
                  • A limitation of the legacy Copy Protection mechanism on Android Market is
+
                  • A limitation of the legacy Copy Protection mechanism on Google Play is
 that applications using it can be installed only on compatible devices that
 provide a secure internal storage environment. For example, a copy-protected
-application cannot be downloaded from Market to a device that provides root
+application cannot be downloaded from Google Play to a device that provides root
 access, and the application cannot be installed to a device's SD card. 
                    • 
-
                  • With Android Market licensing, you can move to a license-based model in
+
                  • With Google Play licensing, you can move to a license-based model in
 which access is not bound to the characteristics of the host device, but to your
-publisher account on Android Market and the licensing policy that you define.
+publisher account on Google Play and the licensing policy that you define.
 Your application can be installed and controlled on any compatible device on
 any storage, including SD card.
                    • 
 
                  
diff --git a/docs/html/guide/market/licensing/setting-up.jd b/docs/html/guide/market/licensing/setting-up.jd
index c79f90b6a64dc..15214d19aa297 100644
--- a/docs/html/guide/market/licensing/setting-up.jd
+++ b/docs/html/guide/market/licensing/setting-up.jd
@@ -31,27 +31,27 @@ environment
 
 
 
-
                  Before you start adding license verification to your application, you need to set up your Android
-Market publishing account, your development environment, and test accounts required to verify
+
                  Before you start adding license verification to your application, you need to set up your Google
+Play publishing account, your development environment, and test accounts required to verify
 your implementation.
                  
 
 
 
                  Setting Up a Publisher Account
                  
 
-
                  If you don't already have a publisher account for Android Market, you need to register for one
-using your Google account and agree to the terms of service on the Android Market publisher site:
                  
+
                  If you don't already have a publisher account for Google Play, you need to register for one
+using your Google account and agree to the terms of service on the Google Play publisher site:
                  
 
 
                  http://market.android.com/publish
+href="http://play.google.com/apps/publish">http://play.google.com/apps/publish
 
                  
 
 
                  For more information, see Publishing on Android Market.
                  
+href="{@docRoot}guide/publishing/publishing.html">Publishing on Google Play.
                  
 
-
                  If you already have a publisher account on Android Market, use your existing
+
                  If you already have a publisher account on Google Play, use your existing
 account to set up licensing.
                  
 
-
                  Using your publisher account on Android Market, you can:
                  
+
                  Using your publisher account on Google Play, you can:
                  
 
 
                    
 
                  • Obtain a public key for licensing
                    • 
@@ -63,7 +63,7 @@ publishing the application
 
                    Administrative settings for licensing
                    
 
 
                    You can manage several
-administrative controls for Android Market licensing on the publisher site. The controls are available
+administrative controls for Google Play licensing on the publisher site. The controls are available
 in the Edit Profile page, in the "Licensing" panel, shown in figure 1. The controls
 let you: 
                    
 
@@ -114,17 +114,17 @@ checking and enforcement. 
                    
 
 
                    As described earlier, applications check licensing status not by contacting
 the licensing server directly, but by binding to a service provided by the
-Android Market application and initiating a license check request. The Android
-Market service then handles the direct communication with the licensing server
+Google Play application and initiating a license check request. The Google
+Play service then handles the direct communication with the licensing server
 and finally routes the response back to your application. To debug and test
 licensing in your application, you need to set up a runtime environment that
-includes the necessary Android Market service, so that your application is able
+includes the necessary Google Play service, so that your application is able
 to send license check requests to the licensing server. 
                    
 
 
                    There are two types of runtime environment that you can use: 
                    
 
 
                      
-
                    • An Android-powered device that includes the Android Market application, or
                      • 
+
                    • An Android-powered device that includes the Google Play application, or
                      • 
 
                    • An Android emulator running the Google APIs Add-on, API level 8 (release 2)
 or higher
                      • 
 
                    
@@ -137,12 +137,12 @@ debugging and testing licensing, the device must:
                    
 
                      
 
                    • Run a compatible version of Android 1.5 or later (API level
 3 or higher) platform, and 
                      • 
-
                    • Run a system image on which the Android Market client application
+
                    • Run a system image on which the Google Play client application
 is preinstalled. 
                      • 
 
                    
 
-
                    If Android Market is not preinstalled in the system image, your application won't
-be able to communicate with the Android Market licensing server. 
                    
+
                    If Google Play is not preinstalled in the system image, your application won't
+be able to communicate with the Google Play licensing server. 
                    
 
 
                    For general information about how to set up a device for use in developing
 Android applications, see Using Hardware Devices.
                    
 licensing.
                    
 
 
                    Because the Android platforms provided in the Android SDK do
-not include Android Market, you need to download the Google APIs Add-On
+not include Google Play, you need to download the Google APIs Add-On
 platform, API level 8 (or higher), from the SDK repository. After downloading
 the add-on, you need to create an AVD configuration that uses that system image.
 
                    
 
-
                    The Google APIs Add-On does not include the full Android Market client.
+
                    The Google APIs Add-On does not include the full Google Play client.
 However, it does provide: 
                    
 
 
                      
-
                    • An Android Market background service that implements the
+
                    • An Google Play background service that implements the
 ILicensingService remote interface, so that your application can
 send license checks over the network to the licensing server. 
                      • 
 
                    • A set of underlying account services that let you add an a Google account on
@@ -174,8 +174,8 @@ href="#acct-signin">Signing in to an authorized account, below.
                      • 
 
                    
 
 
                    Several versions of the add-on are available through the SDK Manager, but only
-Google APIs Add-On, API 8 (release 2) or higher includes the necessary Android
-Market services.
                    
+Google APIs Add-On, API 8 (release 2) or higher includes the necessary Google
+Play services.
                    
 
 
 
@@ -256,11 +256,11 @@ classes to check and enforce licensing.
 
 
                    To download the LVL component into your development environment, use the
 Android SDK Manager. Launch the Android SDK Manager and then
-select the "Market Licensing" component, as shown in figure 3.
+select the "Google Market Licensing" component, as shown in figure 3.
 Accept the terms and click Install Selected to begin the download. 
                    
 
 
-
                    Figure 3. The Market Licensing package contains the LVL and
+
                    Figure 3. The Licensing package contains the LVL and
 the LVL sample application.
                    
 
 
                    When the download is complete, the Android SDK Manager installs both
@@ -297,7 +297,7 @@ system, add and track the sources that are in the working location rather
 than those in default location in the SDK. 
                    
 
 
                    Moving the library sources is important is because, when you later update the
-Market licensing package, the SDK installs the new files to the same location as
+Licensing package, the SDK installs the new files to the same location as
 the older files. Moving your working library files to a safe location ensures
 that your work won't be inadvertently overwritten should you download a new
 version of the LVL.
                    
@@ -438,7 +438,7 @@ Setting up a Library Project.
                    
 
 
                    Setting Up the Testing Environment
                    
 
-
                    The Android Market publisher site provides configuration tools that let you
+
                    The Google Play publisher site provides configuration tools that let you
 and others test licensing on your application before it is published. As you are
 implementing licensing, you can make use of the publisher site tools to test
 your application's Policy and handling of different licensing responses and
@@ -454,7 +454,7 @@ signed in to the publisher account or a test account.
 
                  • An optional set of test accounts that will receive the static test
 response when they check the license of an application that you have uploaded
 (regardless whether the application is published or not).
                    • 
-
                  • A runtime environment for the application that includes the Android Market
+
                  • A runtime environment for the application that includes the Google Play
 application or Google APIs Add-On, on which the user is signed in to the
 publisher account or one of the test accounts.
                    • 
 
                  
@@ -472,7 +472,7 @@ publisher account or one of the test accounts.
 
 
                  Setting test responses for license checks
                  
 
-
                  Android Market provides a configuration setting in your publisher account
+
                  Google Play provides a configuration setting in your publisher account
 that lets you override the normal processing of a license check and return a
 specified static response code. The setting is for testing only and applies
 only to license checks for applications that you have uploaded, made by
@@ -522,7 +522,7 @@ test responses available and their meanings. 
                  
 
                  In some cases, you might want to let multiple teams of developers test
 licensing on applications that will ultimately be published through your
 publisher account, but without giving them access to your publisher account's
-sign-in credentials. To meet that need, the Android Market publisher site lets
+sign-in credentials. To meet that need, the Google Play publisher site lets
 you set up one or more optional test accounts — accounts that are
 authorized to query the licensing server and receive static test responses from
 your publisher account.
                  
@@ -632,11 +632,11 @@ directly. 
                  
 environment
 
 
                  The licensing service is designed to determine whether a given user is
-licensed to use a given application — during a license check, the Android
-Market application gathers the user ID from the primary account on the system
+licensed to use a given application — during a license check, the Google
+Play application gathers the user ID from the primary account on the system
 and sends it to the server, together with the package name of the application
 and other information. However, if there is no user information available, the
-license check cannot succeed, so the Android Market application terminates the
+license check cannot succeed, so the Google Play application terminates the
 request and returns an error to the application. 
                  
 
 
                  During testing, to ensure that your application can successfully query the
diff --git a/docs/html/guide/market/publishing/multiple-apks.jd b/docs/html/guide/market/publishing/multiple-apks.jd
index ff70e8508881b..e7cfa33dac955 100644
--- a/docs/html/guide/market/publishing/multiple-apks.jd
+++ b/docs/html/guide/market/publishing/multiple-apks.jd
@@ -45,7 +45,7 @@ support all desired devices with a single APK
 
   
                  See also
                  
 
                    
-  
                  1. Market Filters
                    2. 
+  
                  2. Filters on Google Play
                    3. 
   
                  3. Supporting Multiple Screens
                    4. 
   
                  4. Compatibility
 Package
                    5. 
@@ -55,10 +55,10 @@ Package
 
 
 
-
                    Multiple APK support is a feature in Android Market that allows you to publish different APKs
+
                    Multiple APK support is a feature on Google Play that allows you to publish different APKs
 for your application that are each targeted to different device configurations. Each APK is a
 complete and independent version of your application, but they share the same application listing on
-Android Market and must share the same package name and be signed with the same release key. This
+Google Play and must share the same package name and be signed with the same release key. This
 feature is useful for cases in which your application cannot reach all desired devices with a single
 APK.
                    
 
@@ -73,8 +73,8 @@ prevent a single APK from working on all devices.
                    
 
 
                    Although we encourage you to develop and publish a single APK that supports as
 many device configurations as possible, doing so is sometimes not possible. To help
-you publish your application for as many devices as possible, Android Market allows you to
-publish multiple APKs under the same application listing. Android Market then supplies each APK to
+you publish your application for as many devices as possible, Google Play allows you to
+publish multiple APKs under the same application listing. Google Play then supplies each APK to
 the appropriate devices based on configuration support you've declared in the manifest file of each
 APK.
                    
 
@@ -86,7 +86,7 @@ APK.
                    
   
                  5. Support different platform versions with each APK.
                    6. 
 
                
 
-
                Currently, these are the only device characteristics that Android Market supports for publishing
+
                Currently, these are the only device characteristics that Google Play supports for publishing
 multiple APKs as the same application.
                
 
 
                Note: You should generally use multiple APKs to support
@@ -100,8 +100,8 @@ consider your options before publishing multiple APKs.
                
 
 
                Publishing Concepts
                
 
-
                Before you start publishing multiple APKs on Android Market, you must understand a few
-concepts regarding how the Android Market publisher site works.
                
+
                Before you start publishing multiple APKs on Google Play, you must understand a few
+concepts regarding how the Google Play publisher site works.
                
 
 
                Active APKs
                
 
@@ -111,20 +111,20 @@ concepts regarding how the Android Market publisher site works.
                
   
                When editing your application, there are two buttons on the top-right side of the page. The
 first button is either Publish or Unpublish and the second
 button is always Save (but its behavior changes).
                
-  
                When your application is new or you have unpublished it from Market, the first
+  
                When your application is new or you have unpublished it from Google Play, the first
 button says Publish. Clicking it will publish any APKs listed as
-Active, making them available on Android Market. Also while your application is new
+Active, making them available on Google Play. Also while your application is new
 or unpublished, clicking Save will save any changes you've made, such
 as information added to the Product details and APKs you've uploaded, but nothing is made visible on
-Android Market—this allows you to save your changes and sign out of the publisher site before
+Google Play—this allows you to save your changes and sign out of the publisher site before
 deciding to publish.
                
  
                Once you've published your application, the first button changes to
 Unpublish. Clicking it in this state unpublishes your application so that none
-of the APKs are available on Android Market. Also while published, the behavior of the
+of the APKs are available on Google Play. Also while published, the behavior of the
 Save button is different. In this state, clicking Save not
-only saves all your changes, but also publishes them to Android Market. For example, if you've
+only saves all your changes, but also publishes them to Google Play. For example, if you've
 already published your application and then make changes to your product details or activate new
-APKs, clicking Save makes all those changes live on Android Market.
                
+APKs, clicking Save makes all those changes live on Google Play.
                
 
 
 
@@ -135,14 +135,14 @@ moves into the list of Active APKs. This list allows you to preview whi
 you're about to publish.
                
 
 
                If there are no errors, any "active" APK will be published to
-Android Market when you click the Publish button (if the application is
+Google Play when you click the Publish button (if the application is
 unpublished) or when you click the Save button (if the application is
 already published).
                
 
 
 
                Simple mode and advanced mode
                
 
-
                The Android Market publisher site provides two modes for managing the APKs associated with
+
                The Google Play publisher site provides two modes for managing the APKs associated with
 your application: simple mode and advanced mode. You can switch between these by
 clicking the
 link at the top-right corner of the APK files tab.
                
@@ -164,21 +164,21 @@ below.
                
 
 
                How Multiple APKs Work
                
 
-
                The concept for using multiple APKs on Android Market is that you have just one entry in
-Android Market for your application, but different devices might download a different APK. This
+
                The concept for using multiple APKs on Google Play is that you have just one entry in
+Google Play for your application, but different devices might download a different APK. This
 means that:
                
 
 
                  
   
                • You maintain only one set of product details (app description, icons, screenshots, etc.).
 This also means you cannot charge a different price for different APKs.
                  • 
-  
                • All users see only one version of your application on Android Market, so they are not
+  
                • All users see only one version of your application on Google Play, so they are not
 confused by different versions you may have published that are "for tablets" or
 "for phones."
                  • 
   
                • All user reviews are applied to the same application listing, even though users on different
 devices may have different APKs.
                  • 
   
                • If you publish different APKs for different versions of Android (for different API levels),
 then when a user's device receives a system update that qualifies them for a different APK you've
-published, Android Market updates the user's application to the APK designed for the higher version
+published, Google Play updates the user's application to the APK designed for the higher version
 of Android. Any system data associated with the application is retained (the same as with normal
 application updates when using a single APK).
                  • 
 
                
@@ -192,8 +192,8 @@ following sections describe more about how it works.
                
 
                Supported filters
                
 
 
                Which devices receive each APK is determined by Android Market filters that are specified by
-elements in the manifest file of each APK. However, Android Market allows you to publish multiple
+href="{@docRoot}guide/appendix/market-filters.html">Google Play filters that are specified by
+elements in the manifest file of each APK. However, Google Play allows you to publish multiple
 APKs only when each APK uses filters to support a variation of the following
 device characteristics:
                
 
@@ -229,7 +229,7 @@ with a single APK.
                
 href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code
 <supports-screens>} element are "true" if you do not declare them otherwise. However,
 because the {@code android:xlargeScreens} attribute was added in Android 2.3 (API level
-9), Android Market will assume that it is "false" if your application does not set either {@code
 android:minSdkVersion} or {@code
@@ -266,7 +266,7 @@ with a higher {@code android:versionCode}
 value. This is also true if two APKs overlap their device support based on a different supported
-filter. This ensures that when a device receives a system update, Android Market can offer the user
+filter. This ensures that when a device receives a system update, Google Play can offer the user
 an update for your application (because updates are based on an increase in the app version code).
 This requirement is described further in the section below about Rules for
 multiple APKs.
@@ -286,8 +286,8 @@ higher, as per the previous note).
 
 
 
                Other manifest elements that enable Android Market filters—but are not
-listed above—are still applied for each APK as usual. However, Android Market does not allow
+href="{@docRoot}guide/appendix/market-filters.html">Google Play filters—but are not
+listed above—are still applied for each APK as usual. However, Google Play does not allow
 you to publish multiple APKs based on variations of them. Thus, you cannot publish
 multiple APKs if the above listed filters are the same for each APK (but the APKs differ based on
 other characteristics in the manifest file). For
@@ -312,7 +312,7 @@ android:versionCode} attribute.
 
   
              16. Each APK must not exactly match the configuration support of another APK.
     
                That is, each APK must declare slightly different support for at least one of
-the supported Market filters (listed above).
                
+the supported Google Play filters (listed above).
                
     
                Usually, you will differentiate your APKs based on a specific characteristic (such as the
 supported texture compression formats), and thus, each APK will declare support for different
 devices. However, it's OK to publish multiple APKs that overlap their support slightly. When two
@@ -330,11 +330,11 @@ application.
                17. 
   
              17. An APK that requires a higher API level must have a higher
 version code.
     
                This is true only when either: the APKs differ based only on the
-supported API levels (no other supported market filters
+supported API levels (no other supported filters
 distinguish the APKs from each other) or when the APKs do use another supported filter, but
 there is an overlap between the APKs within that filter.
                
     
                This is important because a user's device receives an application update from
-Android Market only if the version code for the APK on Android Market is higher than the version
+Google Play only if the version code for the APK on Google Play is higher than the version
 code of the APK currently on the device. This ensures that if a device receives a system update that
 then qualifies it to install the APK for higher API levels, the device receives an application
 update because the version code increases.
                
@@ -365,7 +365,7 @@ increase from the lower API level to the higher API level.
                18. 
 
 
 
-
                Failure to abide by the above rules results in an error on the Android Market publisher site
+
                Failure to abide by the above rules results in an error on the Google Play publisher site
 when you activate your APKs—you will be unable to publish your application until you
 resolve the error.
                
 
@@ -377,7 +377,7 @@ in warnings rather than errors. Warnings can be caused by the following:
                
 APKs support the devices that then fall outside the supported range. For example, if an APK
 currently supports small and normal size screens and you change it to support only small screens,
 then you have shrunk the pool of supported devices and some devices will no longer see your
-application in Android Market. You can resolve this by adding another APK that supports normal size
+application on Google Play. You can resolve this by adding another APK that supports normal size
 screens so that all previously-supported devices are still supported.
 
   
              18. When there are "overlaps" between two or more APKs. For example, if an APK supports screen
@@ -467,8 +467,8 @@ user visible version assigned to {@code android:versionName}),
 so that it's easy for you to associate the version code and version name.
                
 
-
                Note: When you increase the version code for an APK, Android
-Market will prompt users of the previous version to update the application. Thus, to avoid
+
                Note: When you increase the version code for an APK, Google
+Play will prompt users of the previous version to update the application. Thus, to avoid
 unnecessary updates, you should not increase the version code for APKs that do not actually
 include changes.
                
 
@@ -507,7 +507,7 @@ configuration support for one or several of the APKs.
                
 
                Using a Single APK Instead
                
 
 
                Creating multiple APKs for your application is not the normal procedure for
-publishing an application on Android Market. In most cases, you should be able to publish your
+publishing an application on Google Play. In most cases, you should be able to publish your
 application to most users with a single APK and we encourage that you do so. When you encounter
 a situation in which using a single APK becomes difficult, you should carefully consider all your
 options before deciding to publish multiple APKs.
                
@@ -542,7 +542,7 @@ setup, the user receives your application and it runs using the resources optimi
 For example, on a new tablet, the user receives your application and it runs with your
 tablet-optimized resources. This restore
 process does not work across different APKs, because each APK can potentially have different
-permissions that the user has not agreed to, so Android Market may not restore the application at
+permissions that the user has not agreed to, so Google Play may not restore the application at
 all. (If you use multiple APKs, the user receives either the exact same APK if it's compatible or
 nothing at all and must manually download your application to get the APK designed for the new
 device.)
                19. 
@@ -586,7 +586,7 @@ public void onSurfaceChanged(GL10 gl, int w, int h) {
 
 
                Supporting multiple screens
                
 
-
                Unless your APK file exceeds the Android Market size limit of 50MB, supporting multiple screens
+
                Unless your APK file exceeds the Google Play size limit of 50MB, supporting multiple screens
 should always be done with a single APK. Since Android 1.6, the Android system manages most of the
 work required for your application to run successfully on a variety of screen sizes and
 densities.
                
diff --git a/docs/html/guide/practices/compatibility.jd b/docs/html/guide/practices/compatibility.jd
index bb7a72ed2fd99..5e514c4444c19 100644
--- a/docs/html/guide/practices/compatibility.jd
+++ b/docs/html/guide/practices/compatibility.jd
@@ -7,7 +7,7 @@ page.title=Android Compatibility
 
                See also
                
  
                  
 
                1. Market Filters
                  2. 
+href="{@docRoot}guide/appendix/market-filters.html">Filtering on Google Play
 
                2. Providing Alternative Resources
                  3. 
 
                3. 
 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.
                  
@@ -64,7 +64,7 @@ every class and every API for that API level.
                  
 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.
                  
+it’s part of the Android platform itself, as well as part of Google Play.
                  
 
 
                  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.
                  
 
                4. You state the features your app requires by declaring <uses-feature>
 elements its manifest file.
                  5. 
-
                5. Devices are required to declare the features they include to Android
-Market.
                  6. 
-
                6. Android Market uses your app’s stated requirements to filter it from devices
+
                7. Devices are required to declare the features they include to Google
+Play.
                  8. 
+
                8. Google Play uses your app’s stated requirements to filter it from devices
 that don’t meet those requirements.
                  9. 
 
                
 
@@ -103,24 +103,24 @@ instead use the fine-grained controls Android provides.
                
  
                 
    
   
                 
-     
-    
                Filtering on Android Market
                
+     
+    
                Filtering on Google Play
                
 
-    
                Android Market filters the applications that are visible to users, so
+    
                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.
                
 
-    
                One of the ways Market filters applications is by
-feature compatibility. To do this, Market checks the
+    
                One of the ways Google Play filters applications is by
+feature compatibility. To do this, Google Play checks the
 <uses-feature> 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. 
 
 
                For information about other filters that you can
 use to control the availability of your apps, see the 
-Market
-Filters document.
                
+Filters on Google Play
+document.
                
   
                 
 
                
 
@@ -142,8 +142,8 @@ future versions, new feature IDs will be added as well.
                
 
 
                When you write your application, you specify which features your app requires
 by listing their feature IDs in <uses-feature> elements in
-the AndroidManifest.xml file.  This is the information that Android
-Market uses to match your app to devices that can run it. For instance, if you
+the AndroidManifest.xml 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.
                
 
@@ -170,12 +170,12 @@ audience size and minimizing development costs.
                
 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.
                
 
-
                The help information for Android Market provides full details, but in a
-nutshell, developers can use the Market publisher UI to:
                
+
                The help information for Google Play provides full details, but in a
+nutshell, developers can use the Google Play publisher UI to:
                
 
 
                  
 
                • List the countries an app is available in.
                  • 
@@ -185,7 +185,7 @@ nutshell, developers can use the Market publisher UI to:
                  
 
                  Filtering for technical compatibility (such as required hardware components)
 is always based on information contained within your .apk file. But
 filtering for non-technical reasons (such as geographic restrictions) is always
-handled in the Market user interface.
                  
+handled in the Google Play user interface.
                  
 
 
                  Future-proofing
                  
 
@@ -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.
 
 
                • Android 2.2, meanwhile, allowed the microphone to be optional on some
diff --git a/docs/html/guide/practices/design/accessibility.jd b/docs/html/guide/practices/design/accessibility.jd
index a66a974a32d0b..72da04ecc271b 100644
--- a/docs/html/guide/practices/design/accessibility.jd
+++ b/docs/html/guide/practices/design/accessibility.jd
@@ -332,11 +332,10 @@ public boolean dispatchPopulateAccessibilityEvent(final AccessibilityEvent event
 
 
                  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 TalkBack, by the
+href="https://play.google.com/store/details?id=com.google.android.marvin.talkback">TalkBack, by the
 Eyes-Free Project.  It comes preinstalled on many
-Android-powered devices, but is also available for free from Android
-Market.
                  
+Android-powered devices, but is also available for free from the Google Play store.
                  
 
 
                  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 Text-to-speech settings menu by selecting
diff --git a/docs/html/guide/practices/optimizing-for-3.0.jd b/docs/html/guide/practices/optimizing-for-3.0.jd
index 39662f17300a2..140c50ca52f5e 100644
--- a/docs/html/guide/practices/optimizing-for-3.0.jd
+++ b/docs/html/guide/practices/optimizing-for-3.0.jd
@@ -481,7 +481,7 @@ and densities.
                  
 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.
                  
+by external services such as Google Play.
                  
 
 
                  However, before you decide to restrict your application to certain screen configurations, you
 should understand the techniques for 
 </manifest>
 
 
-
                  External services such as Android Market read this manifest element and use it to ensure that
+
                  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.
                  
 
 
                  Note: If you use the {@code
 <supports-screens>} element for the reverse scenario (when your application is not compatible
 with larger screens) and set the larger screen size attributes to {@code "false"}, then
-external services such as Android Market do not apply filtering. Your application
+external services such as Google Play do not 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 {@code
 <compatible-screens>} 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.
                  
 
@@ -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 must include both attributes 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).
                  
+(external services such as Google Play will ignore it).
                  
 
 
                  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.
                  • 
   
                • Not all devices have telephony or other features
   
                  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.
                  • 
 
                
@@ -682,7 +682,7 @@ your applications. For example:
                
 
                <uses-feature android:name="android.hardware.telephony" />
                
 
 
                By default, this declares that your application requires 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.
                
 
 
                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 60c9c95a1a037..a7c4a8ee791c9 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.
                
 
 
                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 {@code
 <compatible-screens>} 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.
                
 
@@ -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 must include both attributes 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).
                
+(external services such as Google Play will ignore it).
                
 
 
                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.
                
 href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code
 <supports-screens>} element for the reverse scenario (when your application is not compatible
 with larger screens) and set the larger screen size attributes to {@code "false"}, then
-external services such as Android Market do not apply filtering. Your application
+external services such as Google Play do not 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 Screen Compatibility Mode for more
@@ -197,13 +197,13 @@ configurations.
                
 
 
                Publishing Multiple APKs for Different Screens
                
 
-
                Although we recommend that you publish one APK for your application, Android Market allows
+
                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.
                
 
 
                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. Supporting
 sizes, especially, is within reason using a single APK, as long as you follow the guide to
 Supporting Multiple Screens.
                
 
-
                If you need more information about how to publish multiple APKs on Android Market, read If you need more information about how to publish multiple APKs on Google Play, read Multiple APK Support.
                
diff --git a/docs/html/guide/practices/screens_support.jd b/docs/html/guide/practices/screens_support.jd
index fb121bd8f7a0d..29dff261335e7 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.
                
 
   
                Caution: 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,
-Android Market currently does not support this attribute for filtering (on Android
+to enable filtering for your application on services such as Google Play. However,
+Google Play currently does not support this attribute for filtering (on Android
 3.2), so you should continue using the other size attributes if your application does not support
 small screens.
                
 
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 9be72eea99352..f8ca3f8d1f782 100644
--- a/docs/html/guide/practices/ui_guidelines/activity_task_design.jd
+++ b/docs/html/guide/practices/ui_guidelines/activity_task_design.jd
@@ -886,7 +886,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 6b686b1ca3432..4b6768f5d8e58 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 Tips for Designers
 for suggestions on how to work with multiple sets of icons.
                
 
-
                A high-resolution version of your application launcher icon is also required by Android Market
+
                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 Application Icons in Android Market below.
                
+href="#icons_in_market">Application Icons on Google Play below.
                
 
 
 
                Note:
@@ -81,7 +81,7 @@ need to review the old guidelines, see the
 
 
                  
   
                1. Promote the brand and tell the story of the app.
                  2. 
-  
                2. Help users discover the app in Android Market.
                  3. 
+  
                3. Help users discover the app on Google Play.
                  4. 
   
                4. Function well in the Launcher.
                  5. 
 
                
 
@@ -100,19 +100,19 @@ app is about. Thus, you should:
                
 
 
 
-
                Help users discover the app in Android Market
                
+
                Help users discover the app on Google Play
                
 
-
                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
+
                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.
                
 
 
                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.
                
 
-
                Note: Android Market requires a high-resolution version of your
-icon; for more details on this, see Application Icons in Android
-Market below.
                
+
                Note: Google Play requires a high-resolution version of your
+icon; for more details on this, see Application Icons in Google
+Play below.
                
 
 
 
                Function well in the Launcher
                
@@ -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.
                
 
 
-
                Application Icons in Android Market
                
+
                Application Icons on Google Play
                
 
 
                If you are publishing your application on
-Android Market, you will also need to provide a 512 x 512 pixel, high-resolution application icon
-in the developer console at upload time. This icon
-will be used in various locations in Android Market and does not replace your launcher icon.
                
+Google Play, you will also need to provide a 512 x 512 pixel, high-resolution application icon
+in the developer console at upload time. This icon
+will be used in various locations on Google Play and does not replace your launcher icon.
                
 
 
                For tips and recommendations on creating high-resolution launcher icons that can easily be scaled
 up to 512x512, see 
 Tips for Designers.
                
 
-
                For information and specifications about high-resolution application icons in Android Market, see
+
                For information and specifications about high-resolution application icons on Google Play, see
 the following article:
                
 
 
                
-Graphic Assets for your Application (Android Market Help) »
+Graphic Assets for your Application (Google Play Help) »
 
 

                
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 ea036cd1703d2..85a3cc8602429 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.
                
 
 
 
-
                Application Icons in Android Market
                
+
                Application Icons on Google Play
                
 
 
                If you are publishing
-your application on Android Market, you will also need to provide a 512x512
+your application on Google Play, you will also need to provide a 512x512
 pixel, high-resolution application icon in the developer console 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 at upload-time.
+This icon will be used in various locations on Google Play and does
 not replace your launcher icon.
                
 
 
                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.
                
 
 
                For information and specifications about high-resolution application
-icons in Android Market, see the following article:
                
+icons on Google Play, see the following article:
                
 
 
                
-  Graphic Assets for your Application (Android Market Help) »
+  Graphic Assets for your Application (Google Play Help) »
 
 
 
diff --git a/docs/html/guide/publishing/app-signing.jd b/docs/html/guide/publishing/app-signing.jd
index 9abcdf75c41cc..e86ec301c25c0 100644
--- a/docs/html/guide/publishing/app-signing.jd
+++ b/docs/html/guide/publishing/app-signing.jd
@@ -82,7 +82,7 @@ run it or debug it on an emulator or device.
                
 use to build your application. There are two build modes: debug mode and release
 mode. You use debug mode when you are developing and testing your application. You use
 release mode when you want to build a release version of your application that you can
-distribute directly to users or publish on an application marketplace such as Android Market.
                
+distribute directly to users or publish on an application marketplace such as Google Play.
                
 
 
                When you build in debug mode the Android SDK build tools use the Keytool utility
 (included in the JDK) to create a debug key. Because the SDK build tools created the debug key,
@@ -158,10 +158,10 @@ you should ensure that your key's validity period exceeds the expected
 lifespan of all versions of all of the applications, including
 dependent applications that may be added to the suite in the future. 
 
-
              19. If you plan to publish your application(s) on Android Market, the
+
              20. If you plan to publish your application(s) on Google Play, the
 key you use to sign the application(s) must have a validity period
-ending after 22 October 2033. The Market server enforces this requirement
-to ensure that users can seamlessly upgrade Market applications when
+ending after 22 October 2033. Google Play enforces this requirement
+to ensure that users can seamlessly upgrade applications when
 new versions are available. 
                21. 
 
 
@@ -292,7 +292,7 @@ key is one that:
                
 with the application
 
              21. Has a validity period that exceeds the expected lifespan of the application
 or application suite. A validity period of more than 25 years is recommended.
-
                If you plan to publish your application(s) on Android Market, note that a
+
                If you plan to publish your application(s) on Google Play, note that a
 validity period ending after 22 October 2033 is a requirement. You can not upload an
 application if it is signed with a key whose validity expires before that date.
 
                22. 
diff --git a/docs/html/guide/publishing/preparing.jd b/docs/html/guide/publishing/preparing.jd
index c355479922a27..fe563529a4d99 100644
--- a/docs/html/guide/publishing/preparing.jd
+++ b/docs/html/guide/publishing/preparing.jd
@@ -22,7 +22,7 @@ page.title=Preparing for Release
     
                  
       
                1. Publishing Overview
                  2. 
       
                2. Signing Your Applications
                  3. 
-      
                3. Publishing on Android Market
                  4. 
+      
                4. Publishing on Google Play
                  5. 
     
                
   
 
@@ -39,13 +39,13 @@ similar to the debug build process and can be done using JDK and Android SDK too
 tasks serve as a final check, ensuring that your application performs as expected under real-world
 conditions. When you are finished preparing your application for release you have a signed
 .apk file, which you can distribute directly to users or distribute through an
-application marketplace such as Android Market.
                
+application marketplace such as Google Play.
                
 
 
                This document summarizes the main tasks you need to perform to prepare your application for
 release. The tasks that are described in this document apply to all Android applications regardless
-how they are released or distributed to users. If you are releasing your application through Android
-Market, you should also read Publishing on
-Android Market to be sure your release-ready application satisfies all Android Market
+how they are released or distributed to users. If you are releasing your application through Google
+Play, you should also read Publishing on
+Google Play to be sure your release-ready application satisfies all Google Play
 requirements.
                
 
 
                Note: As a best practice, your application should meet all of your
@@ -89,9 +89,9 @@ line.
                
 
 
                To prepare your application for release you typically perform five main tasks (see figure 2).
 Each main task may include one or more smaller tasks depending on how you are releasing your
-application. For example, if you are releasing your application through Android Market you may want
+application. For example, if you are releasing your application through Google Play you may want
 to add special filtering rules to your manifest while you are configuring your application for
-release. Similarly, to meet Android Market publishing guidelines you may have to prepare screenshots
+release. Similarly, to meet Google Play publishing guidelines you may have to prepare screenshots
 and create promotional text while you are gathering materials for release.
                
 
 
                You usually perform the tasks listed in figure 2 after you have throroughly debugged and tested
@@ -137,9 +137,9 @@ key.
                
 href="{@docRoot}guide/practices/ui_guidelines/icon_design_launcher.html">icon guidelines. Your
 application's icon helps users identify your application on a device's Home
 screen and in the Launcher window. It also appears in Manage Applications, My Downloads, and
-elsewhere. In addition, publishing services such as Android Market display your icon to users.
                
+elsewhere. In addition, publishing services such as Google Play display your icon to users.
                
 
-
                Note: If you are releasing your application on Android Market, you
+
                Note: If you are releasing your application on Google Play, you
 need to create a high resolution
   version of your icon. See Graphic
@@ -154,7 +154,7 @@ with your application.
                
 
                Miscellaneous Materials
                
 
 
                You might also have to prepare promotional and marketing materials to publicize your application.
-For example, if you are releasing your application on Android Market you will need to prepare some
+For example, if you are releasing your application on Google Play you will need to prepare some
 promotional text and you will need to create screenshots of your application. For more
 information, see
 
@@ -242,11 +242,11 @@ tasks:
                
 
 
 
                There are several additional manifest elements that you can set if you are releasing your
-application on Android Market. For example, the android:minSdkVersion and
+application on Google Play. For example, the android:minSdkVersion and
 android:targetSdkVersion attributes, which are located in the  <uses-sdk> element. For more
-information about these and other Android Market settings, see Market Filters.
                
+information about these and other Google Play settings, see Filters on Google Play.
                
 
 
                Address compatibility issues
                
 
@@ -283,16 +283,15 @@ doing the following:
                
 
                If your application accesses remote servers or services, make sure you are using the production
 URL or path for the server or service and not a test URL or path.
                
 
-
                Implement Licensing (if you are releasing on Android Market)
                
+
                Implement Licensing (if you are releasing on Google Play)
                
 
-
                If you are releasing a paid application through Android Market, consider adding support for
-Android Market Licensing. Licensing lets you control access to your application based on whether the
-current user has purchased it. Using Android Market Licensing is optional even if you are
-releasing your app through Android Market.
                
+
                If you are releasing a paid application through Google Play, consider adding support for
+Google Play Licensing. Licensing lets you control access to your application based on whether the
+current user has purchased it. Using Google Play Licensing is optional even if you are
+releasing your app through Google Play.
                
 
-
                For more information about Android Market Licensing Service and how to use it in your
-application, see Application
-Licensing.
                
+
                For more information about Google Play Licensing Service and how to use it in your
+application, see Application Licensing.
                
 
 
                Building Your Application for Release
                
 
@@ -353,7 +352,7 @@ a summary of common Android situations that you should consider when you are tes
 done testing and you are satisfied that the release version of your application
 behaves correctly, you can release your application to users. For more information, see
 Releasing Your
-Application to Users. If you are publishing your application on Android Market, see
-Publishing on Android Market.
                
+Application to Users. If you are publishing your application on Google Play, see
+Publishing on Google Play.
                
 
 
diff --git a/docs/html/guide/publishing/publishing.jd b/docs/html/guide/publishing/publishing.jd
index 27a87f944bc16..952e602754127 100644
--- a/docs/html/guide/publishing/publishing.jd
+++ b/docs/html/guide/publishing/publishing.jd
@@ -1,4 +1,4 @@
-page.title=Publishing on Android Market
+page.title=Publishing on Google Play
 @jd:body
 
 
                
@@ -7,25 +7,25 @@ page.title=Publishing on Android Market
 
                Quickview
                
 
 
                  
-
                • Learn how to publish and update apps on Android Market.
                  • 
-
                • Find out how to create links to apps that are published on Android Market.
                  • 
-
                • Learn about Android Market features.
                  • 
+
                • Learn how to publish and update apps on Google Play.
                  • 
+
                • Find out how to create links to apps that are published on Google Play.
                  • 
+
                • Learn about Google Play features.
                  • 
 
                
 
 
 
                In this document
                
 
 
                  
-
                1. About Android Market
-
                2. Publishing Apps on Android Market
                  3. 
-
                3. Publishing Updates on Android Market
                  4. 
-
                4. Using Android Market Licensing Service
                  5. 
-
                5. Using Android Market In-app Billing
                  6. 
-
                6. Linking to Your Apps on Android Market
+
                7. About Google Play
+
                8. Publishing Apps on Google Play
                  9. 
+
                9. Publishing Updates on Google Play
                  10. 
+
                10. Using Google Play Licensing Service
                  11. 
+
                11. Using Google Play In-app Billing
                  12. 
+
                12. Linking to Your Apps on Google Play
   
                    
     
                  1. Opening an app's details page
                    2. 
     
                  2. Performing a search
                    3. 
-    
                  3. Build an Android Market button
                    4. 
+    
                  4. Build a Google Play button
                    5. 
     
                  5. Summary of URI formats
                    6. 
   
                  
 
                  13. 
@@ -41,9 +41,9 @@ page.title=Publishing on Android Market
 
                  
   
   
                  
-    
-    
                  Already know about Android Market and want to get started?
                  
-    
                  Go to Android Market, create a developer
+    
+    
                  Already know about Google Play and want to get started?
                  
+    
                  Go to Google Play, create a developer
 account, and upload your application. For more information about required assets, listing details,
 and publishing options, see Upload
@@ -55,78 +55,78 @@ Applications.
                  
 
                  
 
 
                  One of the most effective ways to get your application into users' hands is to
-publish it on an application marketplace like Android Market. Publishing on Android Market is a
+publish it on an application marketplace like Google Play. Publishing on Google Play is a
 straightforward process that you can do in just a few simple steps—register, configure,
 upload, and publish. Registration takes only a few minutes and needs to be done only once.
-The configuration and publishing steps can all be done through the Android Market Developer Console
-after you register as an Android Market developer.
                  
+The configuration and publishing steps can all be done through the Google Play Android Developer Console
+after you register as a Google Play developer.
                  
 
-
                  To start publishing on Android Market, first read this topic and then go to the Android Market publisher site and register as
-an Android Market developer.
                  
+
                  To start publishing on Google Play, first read this topic and then go to the Google Play Android Developer Console and register as
+a Google Play developer.
                  
 
 
-
                  About Android Market
                  
+
                  About Google Play
                  
 
-
                  Android Market is a robust publishing platform that helps you publicize, sell, and distribute
+
                  Google Play is a robust publishing platform that helps you publicize, sell, and distribute
 your Android applications to users around the world. When you release your applications through
-Android Market you have access to a suite of developer tools that let you analyze your sales,
+Google Play you have access to a suite of developer tools that let you analyze your sales,
 identify market trends, and control who your applications are being distributed to. You also have
 access to several revenue-enhancing features, such as in-app billing and
 application licensing.
                  
 
-
                  Before you can publish applications on Android Market, you need to register as an Android Market developer. During the
+
                  Before you can publish applications on Google Play, you need to register as a Google Play developer. During the
 registration process you will need to create a developer profile, pay a registration fee, and agree
-to the Android Market
-Developer Distribution Agreement. After you register you can access the Android Market Developer
+to the Google Play
+Developer Distribution Agreement. After you register you can access the Developer
 Console, where you can upload applications, configure publishing options, and monitor publishing
 data. If you want to sell your applications or use the in-app billing feature, you will also need
 to set up a Google Checkout merchant account. For more information about the registration process,
 see 
 Developer Registration.
                  
 
-
                  Publishing Apps on Android Market
                  
+
                  Publishing Apps on Google Play
                  
 
-
                  Publishing your application on Android Market is a simple process that involves three basic
+
                  Publishing your application on Google Play is a simple process that involves three basic
 tasks (see figure 1):
                  
 
 
                    
   
                  • Creating various graphical assets that
-accompany your app on Android Market.
                    • 
-  
                  • Using the Android Market Developer Console to configure publishing options,
-specify listing details, and upload your app and graphical assets to Android Market.
                    • 
+accompany your app on Google Play.
+  
                  • Using the Google Play Developer Console to configure publishing options,
+specify listing details, and upload your app and graphical assets to Google Play.
                    • 
   
                  • Reviewing your publishing settings and changing the release
 status of your app from Unpublished to Published.
                    • 
 
                  
 
 Shows the three steps that are required to publish on Android Market
 
                  
-  Figure 1. To publish apps on Android Market you must first Figure 1. To publish apps on Google Play you must first prepare your app for release and then perform
 three simple tasks.
 
                  
 
 
                  Important: You must prepare your application for release before you
-can publish it on Android Market. When you prepare your application for release you configure it for
+can publish it on Google Play. When you prepare your application for release you configure it for
 release and build it in release mode. Building in release mode signs your application's {@code .apk}
-file with your private release key. You cannot publish an application on Android Market unless it is
+file with your private release key. You cannot publish an application on Google Play unless it is
 signed with your own private release key.
                  
 
 
                  Preparing promotional materials
                  
 
-
                  To fully leverage the marketing and publicity capabilities of Android Market, you need to create
-several graphical assets that accompany your app on Android Market, such as screenshots, videos,
+
                  To fully leverage the marketing and publicity capabilities of Google Play, you need to create
+several graphical assets that accompany your app on Google Play, such as screenshots, videos,
 promotional graphics, and promotional text. At a minimum you must provide two screenshots of your
 application and a high resolution application icon. The screenshots are displayed on the details
-page for your application in Android Market, and the high resolution application icon is displayed
-in various locations throughout Android Market. The high resolution icon does not replace the
+page for your application on Google Play, and the high resolution application icon is displayed
+in various locations throughout Google Play. The high resolution icon does not replace the
 launcher icon for your application, rather, it serves as a supplemental icon and should look
 the same as your launcher icon. Promotional video,
 graphics, and text are optional, although we strongly recommended that you prepare these for your
@@ -136,8 +136,8 @@ Assets for your Application.
                  
 
 
                  Configuring options and uploading assets
                  
 
-
                  Android Market lets you target your application to a worldwide pool of users and devices. To
-reach these users you can use the Android Market Developer Console to configure various publishing
+
                  Google Play lets you target your application to a worldwide pool of users and devices. To
+reach these users you can use the Developer Console to configure various publishing
 options and listing details for your app. For example, you can choose the countries you want to reach, the listing languages you want to use, and the
@@ -155,11 +155,11 @@ href="http://grendel.sea.corp.google.com:48014/guide/market/billing/billing_admi
 app.
                  
 
 
                  When you are finished setting publishing options and listing details, you can upload your assets
-and your application to Android Market. You can also upload your application as a draft
+and your application to Google Play. You can also upload your application as a draft
 (unpublished) application, which lets you do final testing before you publish it for final
 release.
                  
 
-
                  To learn more about Android Market publishing settings, see the following resources:
                  
+
                  To learn more about Google Play publishing settings, see the following resources:
                  
 
 
                
@@ -670,19 +670,19 @@ the web and in the Android application), as discussed in the previous sections.<
 
 
-
-
+
-
+
 
diff --git a/docs/html/guide/publishing/publishing_overview.jd b/docs/html/guide/publishing/publishing_overview.jd
index c94d20181cb50..6fb77e18b4a6f 100755
--- a/docs/html/guide/publishing/publishing_overview.jd
+++ b/docs/html/guide/publishing/publishing_overview.jd
@@ -14,7 +14,7 @@ page.title=Publishing Overview
     
              22. Preparing Your Application for Release
                23. 
     
              23. Releasing Your Application to Users
     
                  
-      
                1. Releasing on Android Market
                  2. 
+      
                2. Releasing on Google Play
                  3. 
       
                3. Releasing on your own website
                  4. 
       
                4. Releasing through email
                  5. 
     
                
@@ -23,7 +23,7 @@ page.title=Publishing Overview
   
                  
     
                1. Preparing for
     Release
                  2. 
-    
                2. Publishing on Android Market
                  3. 
+    
                3. Publishing on Google Play
                  4. 
   
                
 
 
@@ -42,7 +42,7 @@ publish an Android application you perform two main tasks:
                
   
                24. 
 
 
-
                Usually, you release your application through an application marketplace, such as Android Market.
+
                Usually, you release your application through an application marketplace, such as Google Play.
 However, you can also release applications by sending them directly to users or by letting users
 download them from your own website.
                
 
@@ -73,7 +73,7 @@ tasks:
                
     android:versionCode and android:versionName attributes, which are
     located in the
     <manifest>
-    element. You may also have to configure several other settings to meet Android Market
+    element. You may also have to configure several other settings to meet Google Play
     requirements or accomodate whatever method you're using to release your application.
                
   
   
              24. Building and signing a release version of your application.
@@ -114,28 +114,27 @@ application.
                
 
                Releasing Your Application to Users
                
 
 
                You can release your Android applications several ways. Usually, you release applications
-through an application marketplace, such as Android Market, but you can also release applications
-on your own website or by sending an application directly to a user. Android Market is the
+through an application marketplace, such as Google Play, but you can also release applications
+on your own website or by sending an application directly to a user. Google Play is the
 recommended marketplace for Android applications and is particularly useful if you want to
 distribute your applications to a large global audience. The other two release methods—server
 distribution and email distribution—are useful if you are releasing an application to a small
 group of users (for example, a work group in an enterprise environment), or if you do not want to
 make your application available to the general public.
                
 
-
                Releasing Your Applications on Android Market
                
+
                Releasing Your Applications on Google Play
                
 
-
                Android Market is a robust publishing platform that helps you publicize, sell, and distribute
+
                Google Play is a robust publishing platform that helps you publicize, sell, and distribute
 your Android applications to users around the world. When you release your applications through
-Android Market you have access to a suite of developer tools that let you analyze your sales,
+Google Play you have access to a suite of developer tools that let you analyze your sales,
 identify market trends, and control who your applications are being distributed to. You also have
 access to several revenue-enhancing features that are not available anywhere else, such as in-app billing and application licensing. This rich array of
-tools
-and features, coupled with numerous end-user community features, makes Android Market the premier
+href="{@docRoot}guide/market/licensing.html">application licensing. This rich array of tools
+and features, coupled with numerous end-user community features, makes Google Play the premier
 marketplace for selling and buying Android applications.
                
 
-
                Releasing your application on Android Market is a simple process that involves three basic
+
                Releasing your application on Google Play is a simple process that involves three basic
   steps:
                
 
 
                
@@ -144,19 +143,19 @@ marketplace for selling and buying Android applications.
                
        to be installed" />
   
                
     Figure 2. The Unknown sources setting lets you install
-    applications that are not published on Android Market .
+    applications that are not published on Google Play .
   
                
 
                
 
 
                  
   
                • Preparing promotional materials.
-    
                  To fully leverage the marketing and publicity capabilities of Android Market, you need to
+    
                  To fully leverage the marketing and publicity capabilities of Google Play, you need to
     create promotional materials for your application, such as screenshots, videos, graphics, and
     promotional text.
                  
   
                  • 
   
                • Configuring options and uploading assets.
-    
                  Android Market lets you target your application to a worldwide pool of users and devices.
-    By configuring various Android Market settings, you can choose the countries you want to
+    
                  Google Play lets you target your application to a worldwide pool of users and devices.
+    By configuring various Google Play settings, you can choose the countries you want to
     reach, the listing languages you want to use, and the price you want to charge in each
     country. You can also configure listing details such as the application type, category, and
     content rating. When you are done configuring options you can upload your promotional materials
@@ -170,21 +169,21 @@ marketplace for selling and buying Android applications.
                  
   
                  • 
 
                
 
-
                For information about Android Market, see Publishing on Android Market. This
-topic provides an introduction to Android Market features and provides a step-by-step guide for
-distributing your applications on Android Market.
                
+
                For information about Google Play, see Publishing on Google Play. This
+topic provides an introduction to Google Play features and provides a step-by-step guide for
+distributing your applications on Google Play.
                
 
 
                Releasing your application on your own website
                
 
-
                If you do not want to release your application on an application marketplace like Android Market,
+
                If you do not want to release your application on an application marketplace like Google Play,
 you can release your application by making it available for download on your own website or server.
 To do this, you must first prepare your application for release (that is, you must build it for
 release and sign it). Then all you need to do is host the release-ready application on your website
 and provide a download link for the application. When users browse to your website with their
 Android-powered devices and download your application, the Android system will automatically start
 installing the application on the device. However, the installation process will start automatically
-only if the user has configured their device to allow the installation of non-Android Market
+only if the user has configured their device to allow the installation of non-Google Play
 applications.
                
 
 
                
@@ -198,7 +197,7 @@ applications.
                
 
                
 
 
                By default, Android-powered devices allow users to install applications only if the applications
-have been downloaded from Android Market. To allow the installation of applications from other
+have been downloaded from Google Play. To allow the installation of applications from other
 sources, users need to enable the Unknown sources setting on their devices, and
 they need to make this configuration change before they download your application to their
 device (see figure 2).
                
@@ -209,7 +208,7 @@ applications from unknown sources.
                
 
                Although it is relatively easy to release your application on your own website, it can be
 inefficient and cumbersome. For example, if you want to monetize your application you will
 have to process and track all financial transactions yourself and you will not be able to use
-Android Market's in-app billing feature to sell in-app products. In addition, you will not be
+Google Play's in-app billing feature to sell in-app products. In addition, you will not be
 able to use the licensing feature to help prevent unauthorized installation and use of your
 application.
                
 
@@ -223,7 +222,7 @@ button in the email message (see figure 3). Users can install your application b
 button.
                
 
 
                Note: The Install Now button appears only if a
-user has configured their device to allow the installation of non-Android Market applications and
+user has configured their device to allow the installation of non-Google Play applications and
 they open your email with the native Gmail application.
                
 
 
                Releasing applications through email is convenient if you are sending your application to
diff --git a/docs/html/guide/publishing/versioning.jd b/docs/html/guide/publishing/versioning.jd
index 79ebf96bba680..da57e3ebc710c 100644
--- a/docs/html/guide/publishing/versioning.jd
+++ b/docs/html/guide/publishing/versioning.jd
@@ -25,7 +25,7 @@ page.title=Versioning Your Applications
 
 
                  
 
                1. Preparing to Publish Your Application
                  2. 
-
                2. Publishing On Android Market
                  3. 
+
                3. Publishing On Google Play
                  4. 
 
                4. The AndroidManifest.xml File
                  5. 
 
                
 
diff --git a/docs/html/guide/topics/admin/device-admin.jd b/docs/html/guide/topics/admin/device-admin.jd
index 820c3c0e6c537..4a325dbcb364e 100644
--- a/docs/html/guide/topics/admin/device-admin.jd
+++ b/docs/html/guide/topics/admin/device-admin.jd
@@ -75,8 +75,8 @@ server. 
                25. 
 not currently have an automated provisioning solution. Some of the ways a sysadmin might
 distribute the application to users are as follows:
 
                  
-
                • Android Market.
                  • 
-
                • Enabling non-market installation.
                  • 
+
                • Google Play.
                  • 
+
                • Enabling installation from another store.
                  • 
 
                • Distributing the application through other means, such as email or websites.
                  • 
 
 
                
diff --git a/docs/html/guide/topics/data/backup.jd b/docs/html/guide/topics/data/backup.jd
index dec21467d71ba..4eba4f3b72dc3 100644
--- a/docs/html/guide/topics/data/backup.jd
+++ b/docs/html/guide/topics/data/backup.jd
@@ -900,8 +900,8 @@ href="{@docRoot}guide/developing/tools/bmgr.html">{@code bmgr}.
                
   
              25. Install your application on a suitable Android system image
     
                  
       
                • If using the emulator, create and use an AVD with Android 2.2 (API Level 8).
                  • 
-      
                • If using a device, the device must be running Android 2.2 or greater and have Android
-Market built in.
                  • 
+      
                • If using a device, the device must be running Android 2.2 or greater and have Google
+Play built in.
                  • 
     
                
   
                26. 
   
              26. Ensure that backup is enabled
diff --git a/docs/html/guide/topics/fundamentals.jd b/docs/html/guide/topics/fundamentals.jd
index d1a37868e1acd..a86d905ad2ce0 100644
--- a/docs/html/guide/topics/fundamentals.jd
+++ b/docs/html/guide/topics/fundamentals.jd
@@ -392,13 +392,13 @@ same features and capabilities. In order to prevent your application from being
 that lack features needed by your application, it's important that you clearly define a profile for
 the types of devices your application supports by declaring device and software requirements in your
 manifest file. Most of these declarations are informational only and the system does not read
-them, but external services such as Android Market do read them in order to provide filtering
+them, but external services such as Google Play do read them in order to provide filtering
 for users when they search for applications from their device.
                
 
 
                For example, if your application requires a camera and uses APIs introduced in Android 2.1 (API Level 7), you should declare these as
 requirements in your manifest file. That way, devices that do not have a camera and have an
-Android version lower than 2.1 cannot install your application from Android Market.
                
+Android version lower than 2.1 cannot install your application from Google Play.
                
 
 
                However, you can also declare that your application uses the camera, but does not
 require it. In that case, your application must perform a check at runtime to determine
@@ -458,12 +458,12 @@ element.
 
 
 
                It's important that you declare all such requirements for your application, because, when you
-distribute your application on Android Market, Market uses these declarations to filter which
+distribute your application on Google Play, the store uses these declarations to filter which
 applications are available on each device. As such, your application should be available only to
 devices that meet all your application requirements.
                
 
-
                For more information about how Android Market filters applications based on these (and other)
-requirements, see the Market Filters
+
                For more information about how Google Play filters applications based on these (and other)
+requirements, see the Filters on Google Play
 document.
                
 
 
diff --git a/docs/html/guide/topics/graphics/opengl.jd b/docs/html/guide/topics/graphics/opengl.jd
index 6a2a20f13fb61..a786d4282d6fb 100644
--- a/docs/html/guide/topics/graphics/opengl.jd
+++ b/docs/html/guide/topics/graphics/opengl.jd
@@ -189,7 +189,7 @@ shown below.
     <uses-feature android:glEsVersion="0x00020000" android:required="true" />
 
 
-  
                Adding this declaration causes the Android Market to restrict your application from being
+  
                Adding this declaration causes Google Play to restrict your application from being
   installed on devices that do not support OpenGL ES 2.0.
                
   
                27. 
   
              27. Texture compression requirements - If your application uses texture
@@ -200,9 +200,9 @@ formats, see Texture compression support.
 
 
                Declaring texture compression requirements in your manifest hides your application from users
 with devices that do not support at least one of your declared compression types. For more
-information on how Android Market filtering works for texture compressions, see the 
-Android Market and texture compression filtering section of the {@code
+Google Play and texture compression filtering section of the {@code
 <supports-gl-texture>} documentation.
                
   
                28. 
 
@@ -470,7 +470,7 @@ the next section.
 
                Note: Once you decide which texture compression formats your
 application will support, make sure you declare them in your manifest using <supports-gl-texture>
-. Using this declaration enables filtering by external services such as Android Market, so that
+. Using this declaration enables filtering by external services such as Google Play, so that
 your app is installed only on devices that support the formats your app requires. For details, see
 OpenGL manifest declarations.
                
diff --git a/docs/html/guide/topics/manifest/activity-element.jd b/docs/html/guide/topics/manifest/activity-element.jd
index 8b131c8beb50b..9dc124be4f3e1 100644
--- a/docs/html/guide/topics/manifest/activity-element.jd
+++ b/docs/html/guide/topics/manifest/activity-element.jd
@@ -672,7 +672,7 @@ unspecified}" setting.
 
 
                Note: When you declare one of the landscape or portrait values,
 it is considered a hard requirement for the orientation in which the activity runs. As such,
-the value you declare enables filtering by services such as Android Market so your application is
+the value you declare enables filtering by services such as Google Play so your application is
 available only to devices that support the orientation required by your activities. For
 example, if you declare either {@code "landscape"}, {@code "reverseLandscape"}, or
 {@code "sensorLandscape"}, then your application will be available only to devices that support
@@ -681,7 +681,7 @@ your application requires either portrait or landscape orientation with the {@code <uses-feature>}
 element. For example, <uses-feature
 android:name="android.hardware.screen.portrait"/>. This is purely a filtering behavior
-provided by Android Market (and other services that support it) and the platform itself does not
+provided by Google Play (and other services that support it) and the platform itself does not
 control whether your app can be installed when a device supports only certain orientations.
                
 
 
diff --git a/docs/html/guide/topics/manifest/compatible-screens-element.jd b/docs/html/guide/topics/manifest/compatible-screens-element.jd
index 5c89869d1a262..a27c31624de2d 100644
--- a/docs/html/guide/topics/manifest/compatible-screens-element.jd
+++ b/docs/html/guide/topics/manifest/compatible-screens-element.jd
@@ -27,10 +27,10 @@ specifies a specific screen size-density combination with which the application
 
   
                The Android system does not read the {@code <compatible-screens>} manifest
 element (neither at install-time nor at runtime). This element is informational only and may be used
-by external services (such as Android Market) to better understand the application's compatibility
+by external services (such as Google Play) to better understand the application's compatibility
 with specific screen configurations and enable filtering for users. Any screen configuration that is
 not declared in this element is a screen with which the application is not
-compatible. Thus, external services (such as Android Market) should not provide the application to
+compatible. Thus, external services (such as Google Play) should not provide the application to
 devices with such screens.
                
 
   
                Caution: Normally, you should not use this manifest
@@ -48,14 +48,14 @@ should use the {@code
 <supports-screens>} element allows you to declare that your application does not
-support small and normal screen sizes. External services (such as Android
-Market) will filter your application accordingly. You can also use the small and normal screen sizes. External services (such as Google
+Play) will filter your application accordingly. You can also use the {@code
 <supports-screens>} element to declare whether the system should resize your
 application for different screen sizes.
                
 
-  
                Also see the Market Filters
-document for more information about how Android Market filters applications using this and
+  
                Also see the Filters on Google Play
+document for more information about how Google Play filters applications using this and
 other manifest elements.
                
 
 
@@ -138,5 +138,5 @@ entry looks like if your application is compatible with only small and normal sc
 
                see also:
                
 
                Supporting Multiple Screens
                
-
                Market Filters
                
+
                Filters on Google Play
                
 
diff --git a/docs/html/guide/topics/manifest/manifest-element.jd b/docs/html/guide/topics/manifest/manifest-element.jd
index c970c72441402..9788945fbed5a 100644
--- a/docs/html/guide/topics/manifest/manifest-element.jd
+++ b/docs/html/guide/topics/manifest/manifest-element.jd
@@ -150,9 +150,9 @@ either internal or external storage through the system settings.
 
 
                
 Display the details screen for a specific applicationhttp://market.android.com/details?id=<package_name>
+http://play.google.com/store/details?id=<package_name>
 market://details?id=<package_name>
 
                
 
 
                
 Search for applications using a general string query.http://market.android.com/search?q=<query>http://play.google.com/store/search?q=<query>
 market://search?q=<query>
 
                
 
 
                
 Search for applications by publisher namehttp://market.android.com/search?q=pub:<publisher_name>http://play.google.com/store/search?q=pub:<publisher_name>
 market://search?q=pub:<publisher_name>
 
                
 
-
                Caution: If your application uses the Android Market's Copy 
-  Protection feature, it cannot be installed to a device's SD card. However, if you use Android 
-  Market's Application Licensing instead, 
+
                Caution: If your application uses Google Play's Copy 
+  Protection feature, it cannot be installed to a device's SD card. However, if you use Google 
+  Play's Application Licensing instead, 
   your application can be installed to internal or external storage, including SD cards.
                
 
 
                Note: By default, your application will be installed on the
diff --git a/docs/html/guide/topics/manifest/supports-gl-texture-element.jd b/docs/html/guide/topics/manifest/supports-gl-texture-element.jd
index 6c4a05a4351ea..ebdd0b10917aa 100644
--- a/docs/html/guide/topics/manifest/supports-gl-texture-element.jd
+++ b/docs/html/guide/topics/manifest/supports-gl-texture-element.jd
@@ -18,20 +18,20 @@ parent.link=manifest-intro.html
  
                
   
   
                
-    
-    
                Android Market and Google Play and <supports-gl-texture> elements
                
-    
                Android Market filters applications according
+    
                Google Play filters applications according
     to the texture compression formats that they support, to ensure that
     they can be installed only on devices that can handle their textures
     properly. Developers can use texture compression filtering
     as a way of targeting specific device types, based on GPU platform.
                
     
     
                For important information about how
-    Android Market uses <supports-gl-texture> elements as
-    the basis for filtering, please read Android
-    Market and texture compression filtering, below.
                
+    Google Play uses <supports-gl-texture> elements as
+    the basis for filtering, please read Google
+    Play and texture compression filtering, below.
                
 
                 
 
                
 
@@ -57,7 +57,7 @@ texture compression formats, you can declare multiple
 
                Declared <supports-gl-texture> elements are informational,
 meaning that the Android system itself does not examine the elements at install
 time to ensure matching support on the device. However, other services
-(such as Android Market) or applications can check your application's
+(such as Google Play) or applications can check your application's
 <supports-gl-texture> declarations as part of handling or
 interacting with your application. For this reason, it's very important that
 you declare all of the texture compression formats (from the list below) that
@@ -141,20 +141,20 @@ and others.
 
                see also:
                
 
                
   
 
                
 
-
                Android Market and texture compression filtering
                
+
                Google Play and texture compression filtering
                
 
-
                Android Market filters the applications that are visible to users, so that
+
                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. One of the ways Market filters applications is by texture
+their devices. One of the ways it filters applications is by texture
 compression compatibility, giving you control over the availability of your
 application to various devices, based on the capabilities of their GPUs.
                
 
 
                To determine an application's texture compression compatibility with a given
-user's device, Android Market compares:
                
+user's device, Google Play compares:
                
 
 
                  
 
                • Texture compression formats that are supported by the application —
@@ -164,26 +164,26 @@ an application declares its supported texture compression formats in
 a device reports the formats it supports as read-only system properties.
                  • 
 
                
 
-
                Each time you upload an application to the Android Market Publisher Site,
-Android Market scans the application's manifest file and looks for any
+
                Each time you upload an application to the Google Play publisher site,
+Google Play scans the application's manifest file and looks for any
 <supports-gl-texture> elements. It extracts the
 format descriptors from the elements and stores them internally as
 metadata associated with the application .apk and the application
 version. 
                
 
-
                When a user searches or browses for applications on Android Market,
+
                When a user searches or browses for applications on Google Play,
 the service compares the texture compression formats supported by the application
 with those supported by the user's device. The comparison is based on the format
 descriptor strings and a match must be exact.
                
 
 
                If any of an application's supported texture compression formats is
-also supported by the device, Android Market allows the user to see the
+also supported by the device, Google Play allows the user to see the
 application and potentially download it. Otherwise, if none of the application's
-formats is supported by the device, Android Market filters the application so
+formats is supported by the device, Google Play filters the application so
 that it is not available for download. 
                
 
 
                If an application does not declare any <supports-gl-texture> elements,
-Android Market does not apply any filtering based on GL texture compression format.
                
+Google Play does not apply any filtering based on GL texture compression format.
                
 
 
 
diff --git a/docs/html/guide/topics/manifest/supports-screens-element.jd b/docs/html/guide/topics/manifest/supports-screens-element.jd
index 81d6e27a235e0..ae141216b9286 100644
--- a/docs/html/guide/topics/manifest/supports-screens-element.jd
+++ b/docs/html/guide/topics/manifest/supports-screens-element.jd
@@ -80,7 +80,7 @@ should not use it.
                
      A small screen is defined as one with a smaller aspect ratio than
      the "normal" (traditional HVGA) screen.  An application that does
      not support small screens will not be available for
-     small screen devices from external services (such as Android Market), because there is little
+     small screen devices from external services (such as Google Play), because there is little
 the platform can do to make such an application work on a smaller screen. This is {@code "true"} by
 default.
   
@@ -156,8 +156,8 @@ smallest screen width qualifier ({@code sw<N>dp}).
                
 
   
                Caution: 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,
-Android Market currently does not support this attribute for filtering (on Android
+to enable filtering for your application on services such as Google Play. However,
+Google Play currently does not support this attribute for filtering (on Android
 3.2), so you should continue using the other size attributes if your application does not support
 small screens.
                
 
diff --git a/docs/html/guide/topics/manifest/uses-feature-element.jd b/docs/html/guide/topics/manifest/uses-feature-element.jd
index 9f806380e921c..9175566cb36ed 100644
--- a/docs/html/guide/topics/manifest/uses-feature-element.jd
+++ b/docs/html/guide/topics/manifest/uses-feature-element.jd
@@ -9,7 +9,7 @@ parent.link=manifest-intro.html
 
 
                In this document
                
 
                  
-  
                1. Android Market and Feature-Based Filtering
+  
                2. Google Play and Feature-Based Filtering
     
                    
       
                  1. Filtering based on explicitly declared features
                    2. 
       
                  2. Filtering based on implicit features
                    3. 
@@ -45,26 +45,26 @@ href="{@docRoot}guide/topics/manifest/manifest-element.html"><manifest> 
    
   
                     
-     
-    
                    Android Market and <uses-feature> elements
                    
-    
                    Android Market filters the applications that are visible to users, so
+     
+    
                    Google Play and <uses-feature> elements
                    
+    
                    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. One of the ways Market filters applications is by feature compatibility.
                    
+devices. One of the ways it filters applications is by feature compatibility.
                    
 
-
                    To do this, Market checks the
+
                    To do this, Google Play checks the
 <uses-feature> 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. 
                    
 
 
                    By specifying the features that your application requires,
-you enable Android Market to present your application only to users whose
+you enable Google Play to present your application only to users whose
 devices meet the application's feature requirements, rather than presenting it
 to all users. 
                    
 
 
                    For important information about how
-Android Market uses features as the basis for filtering, please read Android Market and Feature-Based Filtering,
+Google Play uses features as the basis for filtering, please read Google Play and Feature-Based Filtering,
 below.
                    
 
                    
 
          14. 
@@ -106,7 +106,7 @@ application requires.
          
 
          Declared <uses-feature> elements are informational only, meaning
 that the Android system itself does not check for matching feature support on
 the device before installing an application. However, other services
-(such as Android Market) or applications may check your application's 
+(such as Google Play) or applications may check your application's 
 <uses-feature> declarations as part of handling or interacting
 with your application. For this reason, it's very important that you declare all of
 the features (from the list below) that your application uses. 
          
@@ -207,22 +207,22 @@ can check at run-time whether a higher level of OpenGL ES is available.)
          
     
        14. {@link android.content.pm.FeatureInfo}
          15. 
     
        15. {@link android.content.pm.ConfigurationInfo}
          16. 
     
        16. <uses-permission>
          17. 
-    
        17. Android Market Filters
          18. 
+    
        18. Filters on Google Play
          19. 
   
 
 
 
 
 
-
          Android Market and Feature-Based Filtering
          
+
          Google Play and Feature-Based Filtering
          
 
-
          Android Market filters the applications that are visible to users, so that
+
          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. One of the ways Market filters applications is by feature
+their devices. One of the ways it filters applications is by feature
 compatibility.
          
 
 
          To determine an application's feature compatibility with a given user's
-device, the Android Market service compares:
          
+device, Google Play compares:
          
 
 
            
 
          • Features required by the application — an application declares features in
@@ -238,14 +238,14 @@ are listed in the Features Reference tables at
 the bottom of this document, and in the class documentation for {@link
 android.content.pm.PackageManager}.
            
 
-
            When the user launches the Market application, the application queries the
+
            When the user launches Google Play, the application queries the
 Package Manager for the list of features available on the device by calling
 {@link android.content.pm.PackageManager#getSystemAvailableFeatures()}. The
-Market application then passes the features list up to the Android Market
-service when establishing the session for the user.
            
+Store application then passes the features list up to Google Play
+when establishing the session for the user.
            
 
-
            Each time you upload an application to the Android Market Publisher Site,
-Android Market scans the application's manifest file. It looks for
+
            Each time you upload an application to the Google Play publisher site,
+Google Play scans the application's manifest file. It looks for
 <uses-feature> elements and evaluates them in combination
 with other elements, in some cases, such as <uses-sdk> and
 <uses-permission> elements. After establishing the
@@ -253,17 +253,17 @@ application's set of required features, it stores that list internally as
 metadata associated with the application .apk and the application
 version. 
            
 
-
            When a user searches or browses for applications using the Android Market
+
            When a user searches or browses for applications using the Google Play
 application, the service compares the features needed by each application with
 the features available on the user's device. If all of an application's required
-features are present on the device, Android Market allows the user to see the
+features are present on the device, Google Play allows the user to see the
 application and potentially download it. If any required feature is not
-supported by the device, Android Market filters the application so that it is
+supported by the device, Google Play filters the application so that it is
 not visible to the user and not available for download. 
            
 
 
            Because the features you declare in <uses-feature>
-elements directly affect how Android Market filters your application, it's
-important to understand how Android Market evaluates the application's manifest
+elements directly affect how Google Play filters your application, it's
+important to understand how Google Play evaluates the application's manifest
 and establishes the set of required features. The sections below provide more
 information. 
            
 
@@ -277,35 +277,35 @@ application absolutely requires the feature and cannot function properly without
 it ("true"), or whether the application prefers to use the feature
 if available, but is designed to run without it ("false").
            
 
-
            Android Market handles explicitly declared features in this way: 
            
+
            Google Play handles explicitly declared features in this way: 
            
 
 
              
-
            • If a feature is explicitly declared as being required, Android Market adds
+
            • If a feature is explicitly declared as being required, Google Play adds
 the feature to the list of required features for the application. It then
 filters the application from users on devices that do not provide that feature.
 For example:
 
              <uses-feature android:name="android.hardware.camera" android:required="true" />
              • 
-
            • If a feature is explicitly declared as not being required, Android
-Market does not add the feature to the list of required features. For
+
            • If a feature is explicitly declared as not being required, Google
+Play does not add the feature to the list of required features. For
 that reason, an explicitly declared non-required feature is never considered when
 filtering the application. Even if the device does not provide the declared
-feature, Android Market will still consider the application compatible with the
+feature, Google Play will still consider the application compatible with the
 device and will show it to the user, unless other filtering rules apply. For
 example:
 
              <uses-feature android:name="android.hardware.camera" android:required="false" />
              • 
 
            • If a feature is explicitly declared, but without an
-android:required attribute, Android Market assumes that the feature
+android:required attribute, Google Play assumes that the feature
 is required and sets up filtering on it. 
              • 
 
            
 
 
            In general, if your application is designed to run on Android 1.6 and earlier
 versions, the android:required attribute is not available in the
-API and Android Market assumes that any and all
+API and Google Play assumes that any and all
 <uses-feature> declarations are required. 
            
 
 
            Note: By declaring a feature explicitly and
 including an android:required="false" attribute, you can
-effectively disable all filtering on Android Market for the specified feature.
+effectively disable all filtering on Google Play for the specified feature.
 
            
 
 
@@ -317,7 +317,7 @@ function properly, but which is not declared in a
 speaking, every application should always declare all features that it
 uses or requires, so the absence of a declaration for a feature used by an
 application should be considered an error. However, as a safeguard for users and
-developers, Android Market looks for implicit features in each application and
+developers, Google Play looks for implicit features in each application and
 sets up filters for those features, just as it would do for an explicitly
 declared feature. 
            
 
@@ -337,25 +337,25 @@ element name or an unrecognized string value for the
 
            • 
 
          
 
-
          To account for the cases above, Android Market attempts to discover an
+
          To account for the cases above, Google Play attempts to discover an
 application's implied feature requirements by examining other elements
 declared in the manifest file, specifically,
 <uses-permission> elements.
          
 
-
          If an application requests hardware-related permissions, Android Market
+
          If an application requests hardware-related permissions, Google Play
 assumes that the application uses the underlying hardware features and
 therefore requires those features, even though there might be no
 corresponding to <uses-feature> declarations. For such
-permissions, Android Market adds the underlying hardware features to the
+permissions, Google Play adds the underlying hardware features to the
 metadata that it stores for the application and sets up filters for them.
          
 
 
          For example, if an application requests the CAMERA permission
 but does not declare a <uses-feature> element for
-android.hardware.camera, Android Market considers that the
+android.hardware.camera, Google Play considers that the
 application requires a camera and should not be shown to users whose devices do
 not offer a camera.
          
 
-
          If you don't want Android Market to filter based on a specific implied
+
          If you don't want Google Play to filter based on a specific implied
 feature, you can disable that behavior. To do so, declare the feature explicitly
 in a <uses-feature> element and include an 
 android:required="false" attribute. For example, to disable
@@ -366,30 +366,30 @@ the feature as shown below.
          
 
 
          It's important to understand that the permissions that you
 request in <uses-permission> elements can directly affect how
-Android Market filters your application. The reference section Permissions that Imply Feature Requirements,
 below, lists the full set of permissions that imply feature requirements and
 therefore trigger filtering.
          
 
 
          Special handling for Bluetooth feature
          
 
-
          Android Market applies slightly different rules than described above, when
+
          Google Play applies slightly different rules than described above, when
 determining filtering for Bluetooth.
          
 
 
          If an application declares a Bluetooth permission in a
 <uses-permission> element, but does not explicitly declare
-the Bluetooth feature in a <uses-feature> element, Android
-Market checks the version(s) of the Android platform on which the application is
+the Bluetooth feature in a <uses-feature> element, Google
+Play checks the version(s) of the Android platform on which the application is
 designed to run, as specified in the <uses-sdk> element. 
          
 
-
          As shown in the table below, Android Market enables filtering for the
+
          As shown in the table below, Google Play enables filtering for the
 Bluetooth feature only if the application declares its lowest or targeted
-platform as Android 2.0 (API level 5) or higher. However, note that Android
-market applies the normal rules for filtering when the application explicitly
+platform as Android 2.0 (API level 5) or higher. However, note that Google
+Play applies the normal rules for filtering when the application explicitly
 declares the Bluetooth feature in a <uses-feature> element.
 
          
 
-
          Table 1. How Android Market determines the
+
          Table 1. How Google Play determines the
 Bluetooth feature requirement for an application that requests a Bluetooth
 permission but does not declare the Bluetooth feature in a
 <uses-feature> element.
          
@@ -403,14 +403,14 @@ permission but does not declare the Bluetooth feature in a
 
 <=4 (or uses-sdk is not declared)
 <=4
-Android Market will not filter the application from any devices
+Google Play will not filter the application from any devices
 based on their reported support for the android.hardware.bluetooth
 feature.
 
 
 <=4
 >=5
-Android Market filters the application from any devices that
+Google Play filters the application from any devices that
 do not support the android.hardware.bluetooth feature (including
 older releases).
 
@@ -421,13 +421,13 @@ older releases).
 
 
 
          The examples below illustrate the different filtering effects, based on how
-Android Market handles the Bluetooth feature. 
          
+Google Play handles the Bluetooth feature. 
          
 
 
          
 
          In first example, an application that is designed to run on older API levels
 declares a Bluetooth permission, but does not declare the Bluetooth feature in a
 <uses-feature> element.
          
-
          Result: Android Market does not filter the application from any device.
          
+
          Result: Google Play does not filter the application from any device.
          
 
          
 
 
          <manifest ...>
@@ -439,7 +439,7 @@ declares a Bluetooth permission, but does not declare the Bluetooth feature in a
 
          
 
          In the second example, below, the same application also declares a target
 API level of "5". 
          
-
          Result: Android Market now assumes that the feature is required and
+
          Result: Google Play now assumes that the feature is required and
 will filter the application from all devices that do not report Bluetooth support,
 including devices running older versions of the platform. 
          
 
          
@@ -465,7 +465,7 @@ including devices running older versions of the platform. 
 
          
 
          Finally, in the case below, the same application adds an
 android:required="false" attribute.
          
-
          Result: Android Market disables filtering based on Bluetooth
+
          Result: Google Play disables filtering based on Bluetooth
 feature support, for all devices.
          
 
          
 
@@ -481,10 +481,10 @@ feature support, for all devices.
 
          Testing the features required by your application
          
 
 
          You can use the aapt tool, included in the Android SDK, to
-determine how Android Market will filter your application, based on its declared
+determine how Google Play will filter your application, based on its declared
 features and permissions. To do so, run  aapt with the dump
 badging command. This causes aapt to parse your
-application's manifest and apply the same rules as used by Android Market to
+application's manifest and apply the same rules as used by Google Play to
 determine the features that your application requires. 
          
 
 
          To use the tool, follow these steps: 
          
@@ -529,7 +529,7 @@ densities: '160'
 
          Features Reference
          
 
 
          The tables below provide reference information about hardware and software
-features and the permissions that can imply them on Android Market. 
          
+features and the permissions that can imply them on Google Play. 
          
 
 
          Hardware features
          
 
@@ -873,12 +873,12 @@ level 5). Because of this, some apps were able to use the API before they had
 the ability to declare that they require the API via the
 <uses-feature> system. 
          
 
-
          To prevent those apps from being made available unintentionally,  Android
-Market assumes that certain hardware-related permissions indicate that the
+
          To prevent those apps from being made available unintentionally,  Google
+Play assumes that certain hardware-related permissions indicate that the
 underlying hardware features are required by default. For instance, applications
 that use Bluetooth must request the BLUETOOTH permission in a
-<uses-permission> element — for legacy apps, Android
-Market assumes that the permission declaration means that the underlying
+<uses-permission> element — for legacy apps, Google
+Play assumes that the permission declaration means that the underlying
 android.hardware.bluetooth feature is required by the application
 and sets up filtering based on that feature. 
          
 
diff --git a/docs/html/guide/topics/manifest/uses-library-element.jd b/docs/html/guide/topics/manifest/uses-library-element.jd
index d94ad9fb3ab70..2f8eb508c2700 100644
--- a/docs/html/guide/topics/manifest/uses-library-element.jd
+++ b/docs/html/guide/topics/manifest/uses-library-element.jd
@@ -33,7 +33,7 @@ parent.link=manifest-intro.html
     
          
     
          
         This element also affects the installation of the application on a particular device and
-        the availability of the application in Android Market:
+        the availability of the application on Google Play:
     
          
     
          
         
          Installation
          
@@ -42,11 +42,11 @@ parent.link=manifest-intro.html
             {@code true}, the {@link android.content.pm.PackageManager} framework won't let the user
             install the application unless the library is present on the user's device.
         
-        
          Market
          
+        
          Google Play
          
         
          
-            Android Market filters applications based on the libraries installed on the
+            Google Play filters applications based on the libraries installed on the
             user's device. For more information about filtering, see the topic
-            Market Filters.
+            Filters on Google Play.
         
          
     
          
     
          
diff --git a/docs/html/guide/topics/manifest/uses-permission-element.jd b/docs/html/guide/topics/manifest/uses-permission-element.jd
index 967fc5a653162..6c71fb46c97ea 100644
--- a/docs/html/guide/topics/manifest/uses-permission-element.jd
+++ b/docs/html/guide/topics/manifest/uses-permission-element.jd
@@ -8,21 +8,21 @@ parent.link=manifest-intro.html
  
           
    
   
           
-     
-    
          <uses-permission> and filtering on Android Market. 
          
+     
+    
          <uses-permission> and filtering on Google Play. 
          
 
 
          In some cases, the permissions that you request
 through <uses-permission> can affect how
-your application is filtered by Android Market.
          
+your application is filtered by Google Play.
          
 
 
          If you request a hardware-related permission —
-CAMERA, for example — Android Market assumes that your
+CAMERA, for example — Google Play assumes that your
 application requires the underlying hardware feature and filters the application
 from devices that do not offer it.
          
 
 
          To control filtering, always explicitly declare
 hardware features in <uses-feature> elements, rather than
-relying on Android Market to "discover" the requirements in
+relying on Google Play to "discover" the requirements in
 <uses-permission> elements. Then, if you want to disable
 filtering for a particular feature, you can add a
 android:required="false" attribute to the
diff --git a/docs/html/guide/topics/manifest/uses-sdk-element.jd b/docs/html/guide/topics/manifest/uses-sdk-element.jd
index 99c91f6862b65..8fa39d156914c 100644
--- a/docs/html/guide/topics/manifest/uses-sdk-element.jd
+++ b/docs/html/guide/topics/manifest/uses-sdk-element.jd
@@ -33,16 +33,16 @@ major version or the sum of the major and minor versions).
          
  
           
    
   
           
-     
-    
          Android Market and <uses-sdk> attributes
           
-    
          Android Market filters the applications that are visible to users, so
+     
+    
          Google Play and <uses-sdk> attributes
           
+    
          Google Play filters the applications that are visible to users, so
 that users can only see and download applications that are compatible with their
-devices. One of the ways Market filters applications is by Android
-version-compatibility. To do this, Market checks the <uses-sdk>
+devices. One of the ways it filters applications is by Android
+version-compatibility. To do this, Google Play checks the <uses-sdk>
 attributes in each application's manifest to establish its version-compatibility
 range, then shows or hides the application based on a comparison with the API
 Level of the user's Android system version. For more information, see Market Filters.
          
+href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play.
          
   
          
 
          
 
@@ -114,7 +114,7 @@ the corresponding platform version.
          
   updates, consider the following example: 
          
 
   
          An application declaring maxSdkVersion="5" in its
-  manifest is published on Android Market. A user whose device is running Android
+  manifest is published on Google Play. A user whose device is running Android
   1.6 (API Level 4) downloads and installs the app. After a few weeks, the user
   receives an over-the-air system update to Android 2.0 (API Level 5). After the
   update is installed, the system checks the application's
@@ -143,7 +143,7 @@ the corresponding platform version.
          
 
   
          Future versions of Android (beyond Android 2.0.1) will no
 longer check or enforce the maxSdkVersion attribute during
-installation or re-validation. Android Market will continue to use the attribute
+installation or re-validation. Google Play will continue to use the attribute
 as a filter, however, when presenting users with applications available for
 download. 
          
   
diff --git a/docs/html/guide/topics/media/camera.jd b/docs/html/guide/topics/media/camera.jd
index 4e928b3132642..a76c3c76bb8ae 100644
--- a/docs/html/guide/topics/media/camera.jd
+++ b/docs/html/guide/topics/media/camera.jd
@@ -131,11 +131,11 @@ for example:
   
          For a list of camera features, see the manifest
 Features
 Reference.
          
-  
          Adding camera features to your manifest causes Android Market to prevent your application from
+  
          Adding camera features to your manifest causes Google Play to prevent your application from
 being installed to devices that do not include a camera or do not support the camera features you
-specify. For more information about using feature-based filtering with Android Market, see Android
-Market and Feature-Based Filtering.
          
+specify. For more information about using feature-based filtering with Google Play, see Google
+Play and Feature-Based Filtering.
          
   
          If your application can use a camera or camera feature for proper operation, but does
 not require it, you should specify this in the manifest by including the {@code
 android:required} attribute, and setting it to {@code false}:
          
@@ -1260,7 +1260,7 @@ supported.
          
 
 
          If your application requires certain camera features in order to function properly, you can
 require them through additions to your application manifest. When you declare the use of specific
-camera features, such as flash and auto-focus, the Android Market restricts your application from
+camera features, such as flash and auto-focus, Google Play restricts your application from
 being installed on devices which do not support these features. For a list of camera features that
 can be declared in your app manifest, see the manifest
  Features
diff --git a/docs/html/guide/topics/network/sip.jd b/docs/html/guide/topics/network/sip.jd
index 276adb6c96469..600da78ffcfbb 100644
--- a/docs/html/guide/topics/network/sip.jd
+++ b/docs/html/guide/topics/network/sip.jd
@@ -147,7 +147,7 @@ href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><uses-sdk>
 
 
          To control how your application is filtered from devices that do not support
-SIP (for example, in Android Market), add the following to your application's
+SIP (for example, on Google Play), add the following to your application's
 manifest:
          
 
 
            
diff --git a/docs/html/guide/topics/nfc/nfc.jd b/docs/html/guide/topics/nfc/nfc.jd
index 83873c37217cc..834656a9d5f57 100644
--- a/docs/html/guide/topics/nfc/nfc.jd
+++ b/docs/html/guide/topics/nfc/nfc.jd
@@ -318,8 +318,8 @@ other two intents, giving the user a better experience.
            
 
          
     
 
-    
        19. The uses-feature element so that your application shows up in the Android
-Market only for devices that have NFC hardware:
+    
        20. The uses-feature element so that your application shows up in Google
+Play only for devices that have NFC hardware:
       
           <uses-feature android:name="android.hardware.nfc" android:required="true" />
 
          
@@ -660,7 +660,7 @@ certainty that your application is started when an NFC tag is scanned. An AAR ha
 of an application embedded inside an NDEF record. You can add an AAR to any NDEF record of your NDEF message,
 because Android searches the entire NDEF message for AARs. If it finds an AAR, it starts the application based
 on the package name inside the AAR. If the application is not present on the device,
-Android Market is launched to download the application.
          
+Google Play is launched to download the application.
          
 
 
          AARs are useful if you want to prevent other applications from filtering for the same intent and
 potentially handling specific tags that you have deployed. AARs are only supported at the
@@ -678,7 +678,7 @@ the intent also matches the AAR, start the Activity.
          21. 
   
        21. If the Activity that filters for the intent does not match the
 AAR, if multiple Activities can handle the intent, or if no Activity handles the intent, start the
 application specified by the AAR.
          22. 
-  
        22. If no application can start with the AAR, go to the Android Market to download the
+  
        23. If no application can start with the AAR, go to Google Play to download the
 application based on the AAR.
          24.
        @@ -897,7 +897,7 @@ public class Beam extends Activity implements CreateNdefMessageCallback {

        Note that this code comments out an AAR, which you can remove. If you enable the AAR, the application specified in the AAR always receives the Android Beam message. If the application is not -present, the Android Market is started to download the application. Therefore, the following intent +present, Google Play launches to download the application. Therefore, the following intent filter is not technically necessary for Android 4.0 devices or later if the AAR is used:

        diff --git a/docs/html/guide/topics/resources/localization.jd b/docs/html/guide/topics/resources/localization.jd index 9affb153b2c2b..c2b668da99ddc 100755 --- a/docs/html/guide/topics/resources/localization.jd +++ b/docs/html/guide/topics/resources/localization.jd @@ -186,7 +186,7 @@ speak.

        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 in the Market)
        + 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 @@ -507,7 +507,7 @@ the new locale.

        Publishing Localized Applications

        -

        The Android Market is +

        The Google Play is the main application distribution system for Android devices. To publish a localized application, you need to sign your application, version it, and go through all the other steps described in href="{@docRoot}guide/publishing/app-signing.html#strategies">Signing Strategies.

      4. Give each .apk file a different application name. Currently it is -impossible to put two applications into the Android Market that have exactly the +impossible to publish two applications on Google Play that have exactly the same name.
      5. Include a complete set of default resources in each .apk file.
        6. @@ -638,7 +638,7 @@ border="0"> arrow - Upload your .apk file or files to Market, selecting the appropriate + Upload your .apk file or files to Google Play, selecting the appropriate languages as you upload. (For more details, see Publishing Your diff --git a/docs/html/guide/topics/sensors/sensors_overview.jd b/docs/html/guide/topics/sensors/sensors_overview.jd index 3c5e94c9b9927..543872ce57fbe 100644 --- a/docs/html/guide/topics/sensors/sensors_overview.jd +++ b/docs/html/guide/topics/sensors/sensors_overview.jd @@ -606,7 +606,7 @@ sensor is present on a device so your app can run successfully. You have two opt that a given sensor is present on a device:

        • Detect sensors at runtime and enable or disable application features as appropriate.
          • -
        • Use Android Market filters to target devices with specific sensor configurations.
          • +
        • Use Google Play filters to target devices with specific sensor configurations.

        Each option is discussed in the following sections.

        @@ -633,9 +633,9 @@ whether there's a pressure sensor on a device:

        } -

        Using Android Market filters to target specific sensor configurations

        +

        Using Google Play filters to target specific sensor configurations

        -

        If you are publishing your application on Android Market you can use the +

        If you are publishing your application on Google Play you can use the <uses-feature> element in your manifest file to filter your application from devices that do not have the appropriate sensor configuration for your application. The @@ -650,7 +650,7 @@ following is an example manifest entry that filters apps that do not have an acc

        If you add this element and descriptor to your application's manifest, users will see your -application on Android Market only if their device has an accelerometer.

        +application on Google Play only if their device has an accelerometer.

        You should set the descriptor to android:required="true" only if your application relies entirely on a specific sensor. If your application uses a sensor for some functionality, but diff --git a/docs/html/guide/topics/ui/actionbar.jd b/docs/html/guide/topics/ui/actionbar.jd index e59fa0f1aaca9..bf7369adb21f4 100644 --- a/docs/html/guide/topics/ui/actionbar.jd +++ b/docs/html/guide/topics/ui/actionbar.jd @@ -349,7 +349,7 @@ of the following:

      6. Frequently used: It's an action that your users need seven out of ten visits or they use it several times in a row.

        Example frequent actions: "New message" in the Messaging app and -"Search" in Android Market.

        +"Search" on Google Play.

      7. Important: It's an action that you need users to easily discover or, if it's diff --git a/docs/html/index.jd b/docs/html/index.jd index 431a7d26482ca..60cd8b751496e 100644 --- a/docs/html/index.jd +++ b/docs/html/index.jd @@ -59,11 +59,11 @@ alt="Android Design" width="160px" style="padding:10px 33px 5px"/>
         
        - +

        Publish

        -

        Android Market is an open service that lets you distribute your apps to handsets.

        -

        Learn more »

        +

        Google Play is an open service that lets you distribute your apps to devices.

        +

        Learn more »

        @@ -182,8 +182,8 @@ href="{@docRoot}resources/dashboard/platform-versions.html">Learn more »Run and debug your Android applications directly on one of these " + "devices. Modify and rebuild the Android operating system, and flash it onto " + "the phone. The Android Dev Phones are carrier-independent, and available for " - + "purchase by developers through their Android Market publisher accounts.

        " - + "Visit Android Market " + + "purchase by developers through their Google Play publisher accounts.

        " + + "Visit Google Play " + "to learn more »

        " }, */ diff --git a/docs/html/intl/ja/community/index.jd b/docs/html/intl/ja/community/index.jd index 490b23ff5d78e..9739f0d3f268a 100644 --- a/docs/html/intl/ja/community/index.jd +++ b/docs/html/intl/ja/community/index.jd @@ -85,7 +85,7 @@ page.title=コミュニティ
      8. Android マーケット ヘルプフォーラム - Android マーケットに関する質問や問題の報告をするための、ウェブベースのディスカッション フォーラムです。
        9. diff --git a/docs/html/intl/ja/index.jd b/docs/html/intl/ja/index.jd index 8096247e4e1b0..fbbd88f7ae8cb 100644 --- a/docs/html/intl/ja/index.jd +++ b/docs/html/intl/ja/index.jd @@ -52,11 +52,11 @@ home=true
         
        - +

        公開

        Android マーケットは、アプリケーションを携帯端末に配信するためのオープン サービスです。

        -

        詳細 »

        +

        詳細 »

        @@ -148,7 +148,7 @@ home=true 'name':"Dev Phone 1", 'img':"devphone-large.png", 'title':"Android Dev Phone 1", - 'desc': "

        この携帯電話を使用することで、開発した Android アプリケーションの実行とデバッグを行うことができます。Android オペレーティングシステムを変更してからリビルドし、携帯電話に書き込むことができます。Android Dev Phone 1 は携帯通信会社に依存しておらず、Android マーケットに登録済みのデベロッパーなら誰でも購入可能です。

        Android Dev Phone 1 の詳細»

        " + 'desc': "

        この携帯電話を使用することで、開発した Android アプリケーションの実行とデバッグを行うことができます。Android オペレーティングシステムを変更してからリビルドし、携帯電話に書き込むことができます。Android Dev Phone 1 は携帯通信会社に依存しておらず、Android マーケットに登録済みのデベロッパーなら誰でも購入可能です。

        Android Dev Phone 1 の詳細»

        " } } diff --git a/docs/html/intl/ja/resources/community-groups.jd b/docs/html/intl/ja/resources/community-groups.jd index ecedde1c52429..3fd66013d7034 100644 --- a/docs/html/intl/ja/resources/community-groups.jd +++ b/docs/html/intl/ja/resources/community-groups.jd @@ -85,7 +85,7 @@ page.title=コミュニティ
      9. Android マーケット ヘルプフォーラム - Android マーケットに関する質問や問題の報告をするための、ウェブベースのディスカッション フォーラムです。
        10. diff --git a/docs/html/resources/articles/can-i-use-this-intent.jd b/docs/html/resources/articles/can-i-use-this-intent.jd index c527331b92319..7787d31e39cae 100644 --- a/docs/html/resources/articles/can-i-use-this-intent.jd +++ b/docs/html/resources/articles/can-i-use-this-intent.jd @@ -68,4 +68,4 @@ but it only lets you react to the problem, you cannot predict it and update the UI accordingly to prevent the user from doing something that won't work. The technique described here can also be used at startup time to ask the user whether he'd like to install the missing package, you can then simply redirect -him to the Android Market by using the appropriate URI.

        \ No newline at end of file +him to Google Play by using the appropriate URI.

        \ No newline at end of file diff --git a/docs/html/resources/articles/contacts.jd b/docs/html/resources/articles/contacts.jd index 8365d2912dd83..374587b284a5c 100644 --- a/docs/html/resources/articles/contacts.jd +++ b/docs/html/resources/articles/contacts.jd @@ -298,10 +298,10 @@ platforms and one for Android 2.0 and beyond. If so, here's what you'll need to
      10. At launch time, check the version of the SDK. The version of the SDK is available as {@link android.os.Build.VERSION#SDK android.os.Build.VERSION.SDK}.
      11. If the SDK version is greater or equal to 5 (Android 2.0), show a dialog -suggesting to the user that it's time to go to Market and find a new version of -the app. You can even provide a link to the new app on Market (see Using Intents -to Launch Market).
        12. +to Launch Google Play).
      12. Change the new application:
          13. @@ -311,14 +311,14 @@ and other new features of Android 2.0.
        • Modify that application's AndroidManifest.xml file:
          • Give the application a new name and a new package name. Currently -Android Market does not allow you to have two applications with the same +Google Play does not allow you to have two applications with the same name/package.
          • Update (or add) the android:minSdkVersion attribute to the <uses-sdk> element. To use the new Contacts API, you should set the value of the attribute to "5" (or higher, as appropriate).
        -
      13. Publish both apps on Market, the old app one as an upgrade and the +
      14. Publish both apps on Google Play, the old app one as an upgrade and the other as new. Make sure to explain the difference between the apps in their descriptions.
        15. diff --git a/docs/html/resources/articles/live-wallpapers.jd b/docs/html/resources/articles/live-wallpapers.jd index bfbbb3434544b..0692a626f7666 100644 --- a/docs/html/resources/articles/live-wallpapers.jd +++ b/docs/html/resources/articles/live-wallpapers.jd @@ -76,19 +76,19 @@ live wallpapers. supported only on Android 2.1 (API level 7) and higher versions of the platform. To ensure that your application can only be installed on devices that support live wallpapers, remember to add the following to the application's manifest -before publishing to Android Market:

        +before publishing to Google Play:

        • <uses-sdk android:minSdkVersion="7" />, which indicates -to Android Market and the platform that your application requires Android 2.1 or +to Google Play and the platform that your application requires Android 2.1 or higher. For more information, see the API Levels and the documentation for the <uses-sdk> element.
        • <uses-feature android:name="android.software.live_wallpaper" />, -which tells Android Market that your application includes a live wallpaper -Android Market uses this feature as a filter, when presenting users lists of -available applications. When you declaring this feature, Android Market +which tells Google Play that your application includes a live wallpaper +Google Play uses this feature as a filter, when presenting users lists of +available applications. When you declaring this feature, Google Play displays your application only to users whose devices support live wallpapers, while hiding it from other devices on which it would not be able to run. For more information, see the documentation for the @@ -98,5 +98,5 @@ href="{@docRoot}guide/topics/manifest/uses-feature-element.html">{@code element.
        -

        Many great live wallpapers are already available on Android Market and +

        Many great live wallpapers are already available on Google Play and we can't wait to see more!

        diff --git a/docs/html/resources/articles/speech-input.jd b/docs/html/resources/articles/speech-input.jd index 0867ff26b023b..2f9cd69d4e581 100644 --- a/docs/html/resources/articles/speech-input.jd +++ b/docs/html/resources/articles/speech-input.jd @@ -9,7 +9,7 @@ on.

        Speech input adds another dimension to staying in touch. Google's Voice Search application, which is pre-installed on many Android devices -and available in Android Market, provides powerful features like "search by voice" +and available on Google Play, provides powerful features like "search by voice" and Voice Actions like "Navigate to." Further enhancing the voice experience, Android 2.1 introduces a @@ -21,7 +21,7 @@ any context in which you would normally type.

        We believe speech can fundamentally change the mobile experience. We would like to invite every Android application developer to consider integrating speech input capabilities -via the Android SDK. One of our favorite apps in the Market that integrates +via the Android SDK. One of our favorite apps on Google Play that integrates speech input is Handcent SMS, because you can dictate a reply to any SMS with a quick tap on the SMS popup window. Here is Speech input integrated into diff --git a/docs/html/resources/articles/tts.jd b/docs/html/resources/articles/tts.jd index 7d07a89f89098..929d08438f7e8 100644 --- a/docs/html/resources/articles/tts.jd +++ b/docs/html/resources/articles/tts.jd @@ -43,7 +43,7 @@ our know to install the data that's required for the device to become a multi-lingual talking machine! Downloading and installing the data is accomplished by firing off the ACTION_INSTALL_TTS_DATA intent, which will take -the user to Android Market, and will let her/him initiate the download. +the user to Google Play, and will let her/him initiate the download. Installation of the data will happen automatically once the download completes. Here is an example of what your implementation of onActivityResult() would look like:

        diff --git a/docs/html/resources/articles/ui-1.6.jd b/docs/html/resources/articles/ui-1.6.jd index 09108dd0207b3..b3238e3b0fc9c 100644 --- a/docs/html/resources/articles/ui-1.6.jd +++ b/docs/html/resources/articles/ui-1.6.jd @@ -129,4 +129,4 @@ leaving you more time to concentrate on your application.

        The Android team is committed to helping you write applications in the easiest and most efficient way possible. We hope you find these improvements -useful and we're excited to see your applications on Android Market.

        +useful and we're excited to see your applications on Google Play.

        diff --git a/docs/html/resources/community-groups.jd b/docs/html/resources/community-groups.jd index 599c4aef46b96..6bd347c827350 100644 --- a/docs/html/resources/community-groups.jd +++ b/docs/html/resources/community-groups.jd @@ -14,7 +14,7 @@ page.title=Developer Forums
      15. Using email with the mailing lists
      16. Application developer mailing lists
      13. -
    13. Android Market Help Forum
      14. +
    14. Google Play Help Forum
    @@ -113,8 +113,8 @@ A low-volume group for security-related announcements by the Android Security Te -

    Android Market Help Forum

    +

    Google Play Help Forum

    -

    The Android Market Help Forum is a web-based discussion forum where you can ask questions or report issues relating to Android Market.

    +

    The Google Play Help Forum is a web-based discussion forum where you can ask questions or report issues relating to Google Play.

    -

    http://www.google.com/support/forum/p/Android+Market

    +

    http://support.google.com/googleplay

    diff --git a/docs/html/resources/dashboard/opengl.jd b/docs/html/resources/dashboard/opengl.jd index 6978d62436fb2..b1c32343a8d9b 100644 --- a/docs/html/resources/dashboard/opengl.jd +++ b/docs/html/resources/dashboard/opengl.jd @@ -50,7 +50,7 @@ href="{@docRoot}guide/topics/manifest/supports-gl-texture-element.html">{@code uses.

    Note: This data is based on the number -of Android devices that have accessed Android Market within a 7-day period +of Android devices that have accessed Google Play within a 7-day period ending on the data collection date noted below.

    diff --git a/docs/html/resources/dashboard/platform-versions.jd b/docs/html/resources/dashboard/platform-versions.jd index acb8472e88650..65a55751a9fc2 100644 --- a/docs/html/resources/dashboard/platform-versions.jd +++ b/docs/html/resources/dashboard/platform-versions.jd @@ -47,7 +47,7 @@ platform version, see API Lev

    Current Distribution

    The following pie chart and table is based on the number of Android devices that have accessed -Android Market within a 14-day period ending on the data collection date noted below.

    +Google Play within a 14-day period ending on the data collection date noted below.

    @@ -103,7 +103,7 @@ then it is currently compatible with the percentage of devices indicated on the line for that version meets the y-axis on the right.

    Each dataset in the timeline is based on the number of Android devices that accessed -Android Market within a 14-day period ending on the date indicated on the x-axis.

    +Google Play within a 14-day period ending on the date indicated on the x-axis.

    diff --git a/docs/html/resources/dashboard/screens.jd b/docs/html/resources/dashboard/screens.jd index 6c04f7e3af4a7..e9c738e0e4b27 100644 --- a/docs/html/resources/dashboard/screens.jd +++ b/docs/html/resources/dashboard/screens.jd @@ -53,7 +53,7 @@ application, see Suppor Screens.

    Note: This data is based on the number -of Android devices that have accessed Android Market within a 7-day period +of Android devices that have accessed Google Play within a 7-day period ending on the data collection date noted below.

    diff --git a/docs/html/sdk/android-1.6-highlights.jd b/docs/html/sdk/android-1.6-highlights.jd index 84766d6207c9e..f0a50fb090b06 100644 --- a/docs/html/sdk/android-1.6-highlights.jd +++ b/docs/html/sdk/android-1.6-highlights.jd @@ -38,7 +38,7 @@ This page provides an overview of some new features and technologies.

    @@ -118,14 +118,14 @@ on the new accessibility framework and enable them in Settings.

    -

    Android Market Updates

    +

    Google Play Updates


    -New Android Market UI +New Google Play UI
    -

    For devices with Android Market, the latest version improves the overall user experience and makes +

    For devices with Google Play, the latest version improves the overall user experience and makes it easier for users to discover great apps and games from developers.

      @@ -157,7 +157,7 @@ they'd like to receive suggestions, under Searchable items in the Search setting It allows any Android application to "speak" a string of text with an accent that matches the language. The engine supports the following languages: English (American and British accents), French, Italian, German and Spanish. If you're using a T-Mobile G1 or Dream device, you'll need to download the -SpeechSynthesis Data Installer from Android Market, which includes the "voices" needed by the +SpeechSynthesis Data Installer from Google Play, which includes the "voices" needed by the text-to-speech engine.

      diff --git a/docs/html/sdk/android-2.1.jd b/docs/html/sdk/android-2.1.jd index 3f2855106e44c..1ee833c0094c9 100644 --- a/docs/html/sdk/android-2.1.jd +++ b/docs/html/sdk/android-2.1.jd @@ -191,7 +191,7 @@ href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><uses- <uses-feature android:name="android.software.live_wallpaper" /> -

      When you've published your application, Android Market checks for the +

      When you've published your application, Google Play checks for the presence of this element and uses it as a filter, ensuring that your application is not made available to users whose devices do not support Live Wallpapers.

      diff --git a/docs/html/sdk/android-2.2-highlights.jd b/docs/html/sdk/android-2.2-highlights.jd index 8bed67551ff48..37a20d5065127 100644 --- a/docs/html/sdk/android-2.2-highlights.jd +++ b/docs/html/sdk/android-2.2-highlights.jd @@ -231,7 +231,7 @@ two-way push sync functionality.

      Android Application Error Reports

      -

      New bug reporting feature for Android Market apps enables developers to receive crash and freeze +

      New bug reporting feature for Google Play apps enables developers to receive crash and freeze reports from their users. The reports will be available when they log into their publisher account.

      diff --git a/docs/html/sdk/android-2.3.3.jd b/docs/html/sdk/android-2.3.3.jd index 023e2e41294af..405c063fa857a 100644 --- a/docs/html/sdk/android-2.3.3.jd +++ b/docs/html/sdk/android-2.3.3.jd @@ -192,7 +192,7 @@ underlying hardware support.

      declaring <uses-permission android:name="android.permission.NFC"> in their manifest files.

      -

      Additionally, developers can request filtering on Android Market, such that +

      Additionally, developers can request filtering on Google Play, such that their applications are not discoverable to users whose devices do not support NFC. To request filtering, add <uses-feature android:name="android.hardware.nfc" diff --git a/docs/html/sdk/android-2.3.4.jd b/docs/html/sdk/android-2.3.4.jd index eeaa69ab169f4..4bfdabdb6a4af 100644 --- a/docs/html/sdk/android-2.3.4.jd +++ b/docs/html/sdk/android-2.3.4.jd @@ -197,7 +197,7 @@ accessories support, for runtime testing against connected devices accessories, please see the related developer documentation.

      -

      Additionally, developers can request filtering on Android Market, such that +

      Additionally, developers can request filtering on Google Play, such that their applications are not available to users whose devices do not provide the appropriate accessory support. To request filtering, add the element below to the application manifest:

      diff --git a/docs/html/sdk/android-2.3.jd b/docs/html/sdk/android-2.3.jd index fc4f5aa95a242..b466913098916 100644 --- a/docs/html/sdk/android-2.3.jd +++ b/docs/html/sdk/android-2.3.jd @@ -150,7 +150,7 @@ declaring <uses-permission android:name="android.permission.INTERNET"> and <uses-permission android:name="android.permission.USE_SIP"> in their manifest files.

      -

      Additionally, developers can request filtering on Android Market, such that +

      Additionally, developers can request filtering on Google Play, such that their applications are not discoverable to users whose devices do not include the platform’s SIP stack and services. To request filtering, add <uses-feature android:name="android.software.sip" @@ -197,7 +197,7 @@ however, regardless of underlying hardware support.

      declaring <uses-permission android:name="android.permission.NFC"> in their manifest files.

      -

      Additionally, developers can request filtering on Android Market, such that +

      Additionally, developers can request filtering on Google Play, such that their applications are not discoverable to users whose devices do not support NFC. To request filtering, add <uses-feature android:name="android.hardware.nfc" @@ -219,7 +219,7 @@ code.

      Note that the specific set of hardware sensors available on any given device varies at the discretion of the device manufacturer.

      -

      Developers can request filtering in Android Market, such that their +

      Developers can request filtering on Google Play, such that their applications are not discoverable to users whose devices do not offer a gyroscope sensor. To do so, add <uses-feature android:name="android.hardware.sensor.gyroscope" @@ -726,7 +726,7 @@ the {@link android.net.sip SIP API} to make or receive internet calls.

      The platform adds several new hardware features that developers can declare in their application manifests as being required by their applications. This lets developers control how their application is filtered, when published on -Android Market.

      +Google Play.

      • {@link android.content.pm.PackageManager#FEATURE_AUDIO_LOW_LATENCY diff --git a/docs/html/sdk/android-3.0.jd b/docs/html/sdk/android-3.0.jd index 49fefee535d42..39a234f77d718 100644 --- a/docs/html/sdk/android-3.0.jd +++ b/docs/html/sdk/android-3.0.jd @@ -922,7 +922,7 @@ parse mode is also compatible with the {@link org.json}'s default parser.

        The {@code <uses-feature>} -manfest element should be used to inform external entities (such as Android Market) of the set of +manfest element should be used to inform external entities (such as Google Play) of the set of hardware and software features on which your application depends. In this release, Android adds the following new constants that applications can declare with this element:

        diff --git a/docs/html/sdk/android-3.1.jd b/docs/html/sdk/android-3.1.jd index b9cf969403647..7ec7e331b982c 100644 --- a/docs/html/sdk/android-3.1.jd +++ b/docs/html/sdk/android-3.1.jd @@ -214,7 +214,7 @@ for USB host and open accessory modes on specific devices is determined by their manufacturers. In particular, host mode relies on appropriate USB controller hardware in the Android-powered device.

        -

        Additionally, developers can request filtering on Android Market, such that +

        Additionally, developers can request filtering on Google Play, such that their applications are not availabe to users whose devices do not provide the appropriate USB support. To request filtering, add one or both of the elements below to the application manifest, as appropriate:

        @@ -908,8 +908,8 @@ desktop).

        • New feature constants

        The platform adds new hardware feature constants that developers can declare -in their application manifests, to inform external entities such as Android -Market of the application's requirement for new hardware capabilities supported +in their application manifests, to inform external entities such as Google +Play of the application's requirement for new hardware capabilities supported in this version of the platform. Developers declare these and other feature constants in {@code @@ -926,11 +926,11 @@ to communicate with external hardware devices connected over USB and function as devices.

      -

      Android Market filters applications based on features declared in Google Play filters applications based on features declared in {@code <uses-feature>} manifest elements. For more information about declaring features in an application manifest, read Android Market +href="{@docRoot}guide/appendix/market-filters.html">Google Play Filters.

      diff --git a/docs/html/sdk/android-3.2.jd b/docs/html/sdk/android-3.2.jd index aeaf9c8171ed0..27df22cba0d9d 100644 --- a/docs/html/sdk/android-3.2.jd +++ b/docs/html/sdk/android-3.2.jd @@ -320,7 +320,7 @@ considers the application incompatible with the device, but does not prevent it from being installed and run.
    -

    Note: Android Market does not currently filter +

    Note: Google Play does not currently filter apps based on any of the attributes above. Support for filtering will be added in a later platform release. Applications that require filtering based on screen size can use the existing <supports-screens> @@ -526,13 +526,13 @@ automatically by the platform.

    New feature constants

    The platform adds new hardware feature constants that you can declare -in their application manifests, to inform external entities such as Android -Market of required hardware and software capabilities. You declare these +in their application manifests, to inform external entities such as Google +Play of required hardware and software capabilities. You declare these and other feature constants in {@code <uses-feature>} manifest elements. -

    Android Market filters applications based on their <uses-feature> attributes, to ensure that they are available only to devices on which their requirements are met.

    +

    Google Play filters applications based on their <uses-feature> attributes, to ensure that they are available only to devices on which their requirements are met.

    -

    When developing your Android application to take advantage of multiple APKs on Android Market, +

    When developing your Android application to take advantage of multiple APKs on Google Play, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each covering a slightly different range of API levels. You will also gain some tools @@ -198,7 +198,7 @@ initialization procedures that don’t change much from APK to APK.

    Adjust the Manifests

    -

    When a user downloads an application which uses multiple APKs through Android Market, the correct +

    When a user downloads an application which uses multiple APKs through Google Play, the correct APK to use is chosen using two simple rules:

    • The manifest has to show that particular APK is eligible
      • @@ -278,19 +278,20 @@ green ≥ blue. Therefore we can effectively collapse the chart to look lik

      -Now, let’s further assume that the Red APK has some requirement on it that the other two don’t. The -Market Filters page of the Android Developer guide has a whole list of possible culprits. For the +Now, let’s further assume that the Red APK has some requirement on it that the other two don’t. +Filters on Google Play page of +the Android Developer guide has a whole list of possible culprits. For the sake of example, let’s assume that red requires a front-facing camera. In fact, the entire point of the red APK is to combine the front-facing camera with sweet new functionality that was added in API 11. But, it turns out, not all devices that support API 11 even HAVE front-facing cameras! The horror!

      -

      Fortunately, if a user is browsing Market from one such device, Android Market will look at the +

      Fortunately, if a user is browsing Google Play from one such device, Google Play will look at the manifest, see that Red lists the front-facing camera as a requirement, and quietly ignore it, having determined that Red and that device are not a match made in digital heaven. It will then see that Green is not only forward-compatible with devices with API 11 (since no maxSdkVersion was defined), but also doesn’t care whether or not there’s a front-facing camera! The app can still be downloaded -from Android Market by the user, because despite the whole front-camera mishap, there was still an +from Google Play by the user, because despite the whole front-camera mishap, there was still an APK that supported that particular API level.

      In order to keep all your APKs on separate "tracks", it’s important to have a good version code @@ -330,7 +331,7 @@ Red:11001, 11002, 11003, 11004...

      Go Over Pre-launch Checklist

      -

      Before uploading to Android Market, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all applications being uploaded to Android Market.

      +

      Before uploading to Google Play, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all applications being uploaded to Google Play.

      • All APKs must have the same package name
        • @@ -342,7 +343,7 @@ Red:11001, 11002, 11003, 11004...

      It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t -any surprises that could hide your application in Market. This is actually quite simple using the +any surprises that could hide your application on Google Play. This is actually quite simple using the "aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and packaging your Android applications, and is also a very handy tool for inspecting them.

      @@ -370,10 +371,10 @@ densities: '120' '160' '240' supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values that were added as a result of permissions you set in the manifest. In the example above, the APK won’t be visible to very many devices.

      -

      Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since API 11 is Honeycomb (the version of Android optimized specifically for tablets), and no Honeycomb devices have telephony hardware in them, Market will filter out this APK in all cases, until future devices come along which are higher in API level AND possess telephony hardware. +

      Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since API 11 is Honeycomb (the version of Android optimized specifically for tablets), and no Honeycomb devices have telephony hardware in them, Google Play will filter out this APK in all cases, until future devices come along which are higher in API level AND possess telephony hardware.

      Fortunately this is easily fixed by adding the following to your manifest:

       <uses-feature android:name="android.hardware.telephony" android:required="false" />
      -

      Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have, to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!

      +

      Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have, to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!

      diff --git a/docs/html/training/multiple-apks/index.jd b/docs/html/training/multiple-apks/index.jd index f9b2b43aa8bfc..d92c1064f68cb 100644 --- a/docs/html/training/multiple-apks/index.jd +++ b/docs/html/training/multiple-apks/index.jd @@ -16,7 +16,7 @@ next.link=api.html @@ -30,7 +30,7 @@ Support
    -

    Multiple APK support is a feature in Android Market that allows you to publish multiple APKs +

    Multiple APK support is a feature of Google Play that allows you to publish multiple APKs under the same application listing. Each APK is a complete instance of your application, optimized to target specific device configurations. Each APK can target a specific set of GL textures, API levels, screen sizes, or some combination thereof.

    @@ -39,7 +39,7 @@ textures, API levels, screen sizes, or some combination thereof.

    configuration variables. Each lesson covers basics about how to organize your codebase and target the right devices, as well as the smart way to avoid pitfalls such as unnecessary redundancy across your codebase, and making mistakes in your manifest that could render an APK invisible to all -devices in Android Market. By going through any of these lessons, you'll know how to develop +devices on Google Play. By going through any of these lessons, you'll know how to develop multiple APKs the smart way, make sure they're targeting the devices you want them to, and know how to catch mistakes before your app goes live.

    diff --git a/docs/html/training/multiple-apks/multiple.jd b/docs/html/training/multiple-apks/multiple.jd index 26a3a9352fe17..0c49705dbc367 100644 --- a/docs/html/training/multiple-apks/multiple.jd +++ b/docs/html/training/multiple-apks/multiple.jd @@ -40,7 +40,7 @@ Support
    • -

    When developing your Android application to take advantage of multiple APKs on Android Market, +

    When developing your Android application to take advantage of multiple APKs on Google Play, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each covering a different class of screen size. You will also gain some tools necessary to @@ -227,7 +227,7 @@ initialization procedures that don’t change much from APK to APK.

    Adjust the Manifests

    -

    When a user downloads an application which uses multiple APKs through Android Market, the correct +

    When a user downloads an application which uses multiple APKs through Google Play, the correct APK to use is chosen using two simple rules:

      @@ -329,17 +329,17 @@ preference as follows:

      Purple ≥ Red ≥ Green ≥ Blue

      Why allow all the overlap? Let’s pretend that the Purple APK has some requirement on it that the -other two don’t. The Market Filters page +other two don’t. The Filters on Google Play page of the Android Developer guide has a whole list of possible culprits. For the sake of example, let’s assume that Purple requires a front-facing camera. In fact, the entire point of Purple is to use entertaining things with the front-facing camera! But, it turns out, not all API 11+ devices even HAVE front-facing cameras! The horror!

      -

      Fortunately, if a user is browsing Market from one such device, Android Market will look at the +

      Fortunately, if a user is browsing Google Play from one such device, Google Play will look at the manifest, see that Purple lists the front-facing camera as a requirement, and quietly ignore it, having determined that Purple and that device are not a match made in digital heaven. It will then see that Red is not only compatible with xlarge devices, but also doesn’t care whether or not -there’s a front-facing camera! The app can still be downloaded from Android Market by the user, +there’s a front-facing camera! The app can still be downloaded from Google Play by the user, because despite the whole front-camera mishap, there was still an APK that supported that particular API level.

      @@ -420,9 +420,9 @@ automatically set to false, since that size didn’t exist yet. So be explicit!

      Go Over Pre-launch Checklist

      -

      Before uploading to Android Market, double-check the following items. Remember that these are +

      Before uploading to Google Play, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all -applications being uploaded to Android Market.

      +applications being uploaded to Google Play.

      • All APKs must have the same package name.
      • All APKs must be signed with the same certificate.
        • @@ -439,7 +439,7 @@ customizable device emulators in the business sitting on your development machin

      It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t -any surprises that could hide your application in Market. This is actually quite simple using the +any surprises that could hide your application on Google Play. This is actually quite simple using the "aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and packaging your Android applications, and is also a very handy tool for inspecting them.

      @@ -467,11 +467,11 @@ densities: '120' '160' '240' supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values that were added as a result of permissions you set in the manifest. In the example above, the APK will be invisible to most, if not all devices.

      -

      Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Market will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware. +

      Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Google Play will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware.

      Fortunately this is easily fixed by adding the following to your manifest:

       <uses-feature android:name="android.hardware.telephony" android:required="false" />
      -

      Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!

      +

      Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!

      diff --git a/docs/html/training/multiple-apks/screensize.jd b/docs/html/training/multiple-apks/screensize.jd index 0ed972a944339..cbf17c54ba8dd 100644 --- a/docs/html/training/multiple-apks/screensize.jd +++ b/docs/html/training/multiple-apks/screensize.jd @@ -43,7 +43,7 @@ Support -

      When developing your Android application to take advantage of multiple APKs on Android Market, +

      When developing your Android application to take advantage of multiple APKs on Google Play, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each covering a different class of screen size. You will also gain some tools necessary to @@ -178,7 +178,7 @@ initialization procedures that don’t change much from APK to APK.

      Adjust the Manifests

      -

      When a user downloads an application which uses multiple APKs through Android Market, the correct +

      When a user downloads an application which uses multiple APKs through Google Play, the correct APK to use is chosen using two simple rules:

      • The manifest has to show that particular APK is eligible
        • @@ -227,17 +227,17 @@ each APK such that red ≥ green ≥ blue, the chart effectively collaps

        Now, let’s further assume that the Red APK has some requirement on it that the other two don’t. The -Market Filters page of the Android +Filters on Google Play page of the Android Developer guide has a whole list of possible culprits. For the sake of example, let’s assume that red requires a front-facing camera. In fact, the entire point of the red APK is to use the extra available screen space to do entertaining things with that front-facing camera. But, it turns out, not all xlarge devices even HAVE front-facing cameras! The horror!

        -

        Fortunately, if a user is browsing Market from one such device, Android Market will look at the +

        Fortunately, if a user is browsing Google Play from one such device, Google Play will look at the manifest, see that Red lists the front-facing camera as a requirement, and quietly ignore it, having determined that Red and that device are not a match made in digital heaven. It will then see that Green is not only compatible with xlarge devices, but also doesn’t care whether or not there’s a -front-facing camera! The app can still be downloaded from Android Market by the user, because +front-facing camera! The app can still be downloaded from Google Play by the user, because despite the whole front-camera mishap, there was still an APK that supported that particular screen size.

        @@ -300,9 +300,9 @@ So be explicit!

        Go Over Pre-launch Checklist

        -

        Before uploading to Android Market, double-check the following items. Remember that these are +

        Before uploading to Google Play, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all -applications being uploaded to Android Market.

        +applications being uploaded to Google Play.

        • All APKs must have the same package name
        • All APKs must be signed with the same certificate
          • @@ -317,7 +317,7 @@ customizable device emulators in the business sitting on your development machin

        It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t -any surprises that could hide your application in Market. This is actually quite simple using the +any surprises that could hide your application on Google Play. This is actually quite simple using the "aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and packaging your Android applications, and is also a very handy tool for inspecting them.

        @@ -345,11 +345,11 @@ densities: '120' '160' '240' supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values that were added as a result of permissions you set in the manifest. In the example above, the APK will be invisible to most, if not all devices.

        -

        Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Market will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware. +

        Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Google Play will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware.

        Fortunately this is easily fixed by adding the following to your manifest:

         <uses-feature android:name="android.hardware.telephony" android:required="false" />
        -

        Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!

        +

        Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!

        diff --git a/docs/html/training/multiple-apks/texture.jd b/docs/html/training/multiple-apks/texture.jd index 2bbe511c6d870..0dbee61795320 100644 --- a/docs/html/training/multiple-apks/texture.jd +++ b/docs/html/training/multiple-apks/texture.jd @@ -40,7 +40,7 @@ Support -

        When developing your Android application to take advantage of multiple APKs on Android Market, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each supporting a different subset of OpenGL texture formats. You will also gain some tools necessary to make maintaining a multiple APK codebase as painless as possible.

        +

        When developing your Android application to take advantage of multiple APKs on Google Play, it’s important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. This lesson shows you how to create multiple APKs of your app, each supporting a different subset of OpenGL texture formats. You will also gain some tools necessary to make maintaining a multiple APK codebase as painless as possible.

        Confirm You Need Multiple APKs

        @@ -158,7 +158,7 @@ initialization procedures that don’t change much from APK to APK.

        Adjust the Manifests

        -

        When a user downloads an application which uses multiple APKs through Android Market, the correct +

        When a user downloads an application which uses multiple APKs through Google Play, the correct APK to use is chosen using some simple rules:

          @@ -246,9 +246,9 @@ following:

          Go Over Pre-launch Checklist

          -

          Before uploading to Android Market, double-check the following items. Remember that these are +

          Before uploading to Google Play, double-check the following items. Remember that these are specifically relevant to multiple APKs, and in no way represent a complete checklist for all -applications being uploaded to Android Market.

          +applications being uploaded to Google Play.

          • All APKs must have the same package name
            • @@ -262,7 +262,7 @@ customizable device emulators in the business sitting on your development machin

          It’s also worth inspecting the compiled APK before pushing to market, to make sure there aren’t -any surprises that could hide your application in Market. This is actually quite simple using the +any surprises that could hide your application on Google Play. This is actually quite simple using the "aapt" tool. Aapt (the Android Asset Packaging Tool) is part of the build process for creating and packaging your Android applications, and is also a very handy tool for inspecting them.

          @@ -290,10 +290,10 @@ densities: '120' '160' '240' supports-screens and compatible-screens, and that you don’t have unintended "uses-feature" values that were added as a result of permissions you set in the manifest. In the example above, the APK will be invisible to most, if not all devices.

          -

          Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Market will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware. +

          Why? By adding the required permission SEND_SMS, the feature requirement of android.hardware.telephony was implicitly added. Since most (if not all) xlarge devices are tablets without telephony hardware in them, Google Play will filter out this APK in these cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware.

          Fortunately this is easily fixed by adding the following to your manifest:

           <uses-feature android:name="android.hardware.telephony" android:required="false" />
          -

          Once you’ve completed the pre-launch checklist, upload your APKs to Android Market. It may take a bit for the application to show up when browsing Android Market, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!

          +

          Once you’ve completed the pre-launch checklist, upload your APKs to Google Play. It may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check. Download the application onto any test devices you may have to make sure that the APKs are targeting the intended devices. Congratulations, you’re done!

          diff --git a/docs/html/training/sharing/receive.jd b/docs/html/training/sharing/receive.jd index cc55967a11e0b..a0a5bc8fc6151 100644 --- a/docs/html/training/sharing/receive.jd +++ b/docs/html/training/sharing/receive.jd @@ -34,7 +34,7 @@ Intent Filters from applications. Think about how users interact with your application, and what data types you want to receive from other applications. For example, a social networking application would likely be interested in receiving text content, like an interesting web URL, from another app. The -Google+ Android +Google+ Android application accepts both text and single or multiple images. With this app, a user can easily start a new Google+ post with photos from the Android Gallery app.

          diff --git a/media/libstagefright/codecs/m4v_h263/dec/src/vop.cpp b/media/libstagefright/codecs/m4v_h263/dec/src/vop.cpp index 74fe47889f528..b3c350f607398 100644 --- a/media/libstagefright/codecs/m4v_h263/dec/src/vop.cpp +++ b/media/libstagefright/codecs/m4v_h263/dec/src/vop.cpp @@ -1041,7 +1041,7 @@ PV_STATUS DecodeShortHeader(VideoDecData *video, Vop *currVop) /* Marker Bit */ if (!BitstreamRead1Bits(stream)) { - mp4dec_log("DecodeShortHeader(): Market bit wrong.\n"); + mp4dec_log("DecodeShortHeader(): Marker bit wrong.\n"); status = PV_FAIL; goto return_point; } From 1c2473042236dd63774d7a2c5edfd991b4ef1b3e Mon Sep 17 00:00:00 2001 From: Scott Main Date: Fri, 2 Mar 2012 15:49:34 -0800 Subject: [PATCH 09/17] docs: update homepage announcement for GP Still needs an update with proper blog link (will probably do by hand for launch push) Change-Id: I660082780ffd27cf591351e6b65be61a109a6d5d --- docs/html/images/home/play_logo.png | Bin 0 -> 7707 bytes docs/html/index.jd | 12 ++++++------ 2 files changed, 6 insertions(+), 6 deletions(-) create mode 100644 docs/html/images/home/play_logo.png diff --git a/docs/html/images/home/play_logo.png b/docs/html/images/home/play_logo.png new file mode 100644 index 0000000000000000000000000000000000000000..b8e3ebf051708e0037ab3b0e2a53b54962ae7073 GIT binary patch literal 7707 zcmaKRbyQSg*Zt5XAPv$j(hNCtcY}1#&;!FTbW17C&@F<3f^;L@4I(MsN(o3wefZY* z`{Vt7cddJ$SbOiY&w0*T_pWu{=x8b9<37U$008)^Dhhg!qwn7v8}sog1{VJMI8Y%J zjS>3p_6Q#vI0PUIcDIEvs6uTVAbJoRu%E{eL;?UnV{tMtMi^^qfb86%JT`wZJibua zBO3sakoJYy*ttLu47LylCpSr^gEaZm1O#dF6eRocbk`q;U5r$izL%OO&M$IFvz>ZAq+x1 zeB5??!u$-vf;{|!d}4xPTnqwy{CvFp0=#@8-28kXArTNCKf}K+rpIV-usujmLFr$y z9#@h~jtB${#LMgBPzUfOy)$ zonQzjcQ=N=iZ-_HUI zenoy!ppufJprVi{zk;Zokbuy?xeD%fUQmb|;@@2G|8f=nPwwAlfWjUlD?s2*-Vm@7 z+#SmBkEB6P|HX?a5GX4qFZie@qWIsv{F4j*FJAt|Rs27>ypLvh{~qoCbJYLddhDOS z)BiN?|!clcvtr{OtU0RYe9RTX3nd>0S${9x3VUIQJm;cFN%#l1IDia*;~ zV?obNN}#mWn^y_!n%TvNzYByD@_r<%mP|VdOly?<5Co3ZeIyxZa5d4g9ZCP3)AC;B z9f5lKb4w;xJyMPpkw~E{rXixlCP48CcUo#Vv`JG)k;d%zU1~ zB50&m6**M8=hmg&A(2pEAs!Y}5rFyO&GV@=A8|&H%TtwV7BsJn9}(ET&h1aw{Z5-3 zFwGAf6`bUR8$OUSO_4*M<~$Fzcrv2^lPr7*WBXXq>>9POC1={MJ}3mH7|t$(HGHPq zCpqgKbE~G>>KC^Lc0oE<%!hljX{ZdXGHsZS$45Q8e<0lHVffZQn})fLAG@N8QOi{a z!xaTSeL2Zd1nQ)`n?zFZNoTx)ZVHaawk zXtcnI{j3M)yA&-boUYhh?+=|rTmG?TfxUJcF8f@l+s(F`(Id#G` zh1^2fH*~b>W~KADtBEKxf>wRa+Oa3>UjIe65x<&SW^wdMSy7vre89d4;mpr!yN*JuitXV~u(+CVw=eZ4JeQ+n!h3#zd5T5{b| z_&^!jvB+hb>@ZYG{!)Ktc8J*Tu$h-x0cn`Je0%~<1E|!{JGQ&ix%OdcLI&eiWO2f@ zaASdh5LRO7>~JmV-dMgga%*>9G=Q6!9H^7K5G@%lUe$IM$xe8oHVm54b-LotnNE(4EL<`G&wqGwjWlzlSLWrUl#a zYl;VcCmGCMC$9@`F&!X`3_pBkYYJl!KSvhVh95vU5gwiIs-vHQ*fQf~1O_nBeTpHg z)mHy1K9r&KZ%V2BoO3>ga-R< zJt#kU=Z@wwC6g{^dt)yqcXE=8Y&l} zXjPW9T=>jcr(Fb?2HH4*CcpEuKiXR1$kM^CC*<%4a_YBJThCdH|6o1s2#_vL59<5^ zF?d~x-d*&h6X{*U=;%!YR?{{5bk5FsrG6@~tnE_r#%64L=rI2P)a3IbOYk?QvM4Wm z)2tLbu2hArK@j^>S$Ff`r%fm9*7v4wVMIZ&`65Yj+A3G?-fEHggOm@qdbR?~A%Q?y zt_6$arJb>g84@D-;X15}_p6ah+BiqhSJX}yn#N}>Rr(=-iUI(+D?q^EBY2M}#W7_? z=e?3;v>962nd zYivrJ89VmVsFjQyl0Sbl?*Gjzu|2(Q+?L@(dUycd~%2AQ{(BUH?1zAWgVy=LP%b7=bIBt zN{A7R7PD&7GCKjG%aBGrYv|!Z#kV1P!S^x*KpTiJP;Ukn%{fpgA#7YuJ|G$j`czcqHn(=9}SqkR@ zqq?q#3^bmgk}dy5SwR9ab1}p?mBd2(X7)@WVh_EG)yVxMG+34GO;?<34q5W@-BoSD z9i3u^%M?9T)J{!ns`E${FH7Px1c7uzLNP+`=(>jVhxWAH$QFRcRWn`K2G>Lh1ML&V zMEH1zKID-y6R4Tk9-Z{z$q5U-7=>RQ9l6 z(H)`IadV1<$tcmMy*6l(_uqOdYumq*4 zQSbhGOF&k3?ExlEs!Jv=TS!3&4{=3e{=`y$=0E#<&=*mqcuw$&dS)S-;sGLpJM8{$ z0?&x5;dfj^GfQ3Y3WJ20^MZkuM*2~Y-L+IMi*$9W+B?NMD58XPU@W^_=fq1Tiy*D| zV^^8wFpPP~)9TNzc5+Dmno{ff@QbE)A}apr&{=J_HynL~$cU$KZmdgJ7j(YQ5pHEF zL`-ZCh{DSf84%tAQOyz#Di69&{UylNUab`K*RA#iL*o~^AYG{@Z1 zl$27NgjkBqzjz9@pf;8h>mJ2E_FVfB0t(IbY*b07s!-o-&R>-p%wFKAH=hm~7GIU@82p#h#21>;@-y>EflZ4(Jd7+VRT40_<4j~;@a#2`2KJLfNPU1Jr^o#_RF~a;R)a%(JjbBKH28i9eSvw7h$B@-H!j|S&l#vd!WJuxaeci93&UiwLxy1M zc#Cz9p&q3dq%vN9gZ@@F6N25bn&7_-qg|U~yL_TJm*C7e)i8jE^AoQ2_T^;zi6^AM zLk9~>J<~uY`bCBucv&l^xxtb>|Idl;79I0Mec8I2r5`~=S&HUOaLdk$gMe&}3CAn_ z=9Ie^PlfL*UP@oos><`&66*3eDb;;D?s=ee^G!s{xnHM*Cp1eM>Gh=DwMhw@*DJR+ zF3?%UmQq+nh>25g&h(28A)~}#L^P!>B&9aZ^PW^kt9dd#RB)j1w^x^i#oy27A&gCJ1m%94TwfD~Y-9#&fDFLdZu~vJ z{Ggpum0rn4D*o@YJrWSx`^yBo4jxneuMu>f1V?Q=Db#L1_IHzXy_Gx9$8kSyl#%M} zW2UR!?ngFpCz32_R(;Sqh^>yxF-+^?O%wc`%TsB#L;vdY{kmUqTJrAV=lp62y+WIZ zy_Nj|XPT|r4&!i@oG1d)>zk+AWvwE`FuOG)PPWly#(}l47D-P}rUu_xf zmJTy&+meX^Dc)4Ny$brlrNKsRM0`kZg;v>7D1_lQw4agey;o7N`$uB-q3`Empt-L- zlb)qX^t@N>ULe~lYxKaaZ81tXP0#K7_Y_Bj?J_^7?0L=aP+~j7o~WA(>RB2`MjVdV z;1c$L>-optX=V#e_6VV5s10n)!`0mLsf-9DeKG_hO{ahusDN6f%y&oYyur^C&~9MbvVDhF0RL6 zd7PeRPTuQoBYOtF$dislt>>LFTod=-TQj}ulm}~CNNXH4yW-r*nC*hn-7V^EHVLZ^ zd_I!+ZhmSu>K~mm<*P5JNT5t3-qCO5C1Em1iqHaVk`OabV zG~Ox3_I3n7yFazf&;6w+h;WE7tKXoCk_l^$rs>|Aif<4S`mXP|Y4nx5?=T8a492n3 ztjQ@b(!H$fMDa|Fdp8Gq8d6oTrlw*hKz7!i7GI2Uf?0?qsG7b_-a?;}Uamm6^3zRb zH1UXWeID?E>vit|#n+@Z;VFhQ*uhFBs=ep1fWO;$4=Eetiz&(=|M}2?FB%&UgTwi5 zw>}3&5Vj(mC!JALq4+=mwLL(16yTbPGS63ULYKz7xVoCSlTKcZ-n$KFWM!oykL?3U zq~bq$^0u&$2zq!36Qy|_7pGt=hx$Q_R(f+V&@wH}P}KJdJ3A+b-(j4~HRz{mPq@5^ zkBBbrQwVaD$LT2 zXVm_zG?=Zd*P-CJ2iX_fUstyy1olwY--uIA4cDiZ}RB zM_5!;rP7Ivj*eO!gNTTT8KfPYHw1o0+bL9E&s3N#?Ox${Fxh4l5~8WeJ)Xx);gO}? z@Tuk5dIL6TWj9@hgDY4kNBG`*ulYeI_kXJDOh_v zB|BRVT5WK7?%r`jhl_Vw?YRDG3MFuRIAcSKoBO5pVyc zb~C8lygC=ON|QX*advdWM6}cn#oHOrIy{&7?C`MjxlwWUp?4>~J3!RwcIM%hK3IPD zH^u4=!N$f0>Zd4|xeEP!4~q9?FW-hf%MBA26yCVYqmN0rs6RAA1CfLrpKVk8`ieKf zD7Fx^oS2>-;Jbh5b8^C7u;G$A0z367E!RL;LfM7J4v5`s#8u$&jk5WmC)xSHEG}%Mo7lVgesSSBE{K z^>sOuckkXMrDy+)oWSioE^!!0C?Jig%X+4ntdy>it`$7KTQ20`#n2*oGwPk3btZOF zeQ?Ozah3b)D5qF(_=aO7NE{?y<+SOq8^U?a4_!2H{Qyl%n~@u{ALk;s9J8#b*LS#A zpk;_2=l1>$;H2wh7uRcroxJmv43Yf|0T(mJf>ST8T7xZ8fd@e*CSkFQJvd-S)j~6( z;i=i#gzxzHuN!VMY?ml$)Xhvy6#De*g zKG~;2A*&9qs5%%Cshvr!rK-||LT2&}c;OsumA-OxL^lD5ysy6Y^AjC7Ne4ai zL1%3>VrK|+FA<%9iAC+Bcn?^too@3^Dy(FuIUt zB=iAAPq$@uG*-@OkBfDPo~=6cUFw2}I-DHP0pTIxuQR^mN&x!b5A34_SAoxqg$Xcg#zQR{G1 zft+5PjasO+$0Vp5jM*|%(CddRbAgTuv$P0B{eISAQ+V#(rt?~{5vvQk70E}B1k!>R z1-G`halLF+cZDT2Pruk+pWcAdh*SmHNplgfch$RRZ7nApl9HM%!tcwB-sruSOowD? z=N>Me$0VH=Xj=B>_j=!WhhLRjr)Op|u-trP7uNp>p-yqR!!VzuaH702X=L_Mpyc9a6-CpUr=1oi&Da#j4+NAF{Q=q!d=$~xOy7hRtbD9EG*i@ z+x6IO2bWa1I?5?cHz~&&hDq2&kAjXTI=BUF5(XY__E%qvULDL8T%?#CW28!i6RL^9 z*SlHG?@kwgJ&RkZj86>%T7Rzo>uVHroil@Mm3m zSd32kT1V6xA7M`fLR+tp1xMHB2)1KBj`O{ufrMCp{k*CZ7A$sUmzR~~@qH&bi8DKx zaxG@xBLsf=tk1y?f{*VAt9(|2lTm8nu&9dMqJm3*3E$lcLJy1gN`VLB;w$nVQ-~>9 zljf_S>wKWqk>kw;Jt+=}`>sx(p*+MeZN7v~YWvcv$+~@hf}q;<$Hq+p`DGhVcE{w@ zCc6T(pDzVT9JvIOKO2GvjkF~MFlUg&c%ac0&3R1*^KesM0lZ!z2h#l@OVsi>=!9~x z_^fOs)0z)*X{_WchlmKfb^q%wnBMuq%3b$O^Li6-JWu>P^~)Aes{)o<;iXv%I9Z1# zA@M-f{5yPLdwkHc=T|+>9P5j4t$a}Uz+Ad*fpQn6Ne`6q= z;$Xr2_|z{da-r7+7q2Oto0N95*`eU1tob@Hwhsm)I0Zih!lAbsGvcmehZ8QQiE zv0|v$W{v=>{UBrO%8C>cVkVPbCL%G=*|h#mKHw+%jsUCilPH&6U*}TlZzrknaO%oZ z$3492s?-tV++@S`qU0X}3rmMC6@h&aY*ypQk<5Ht*wGc7c0LNfaSO#sg z>S}ZL3vm@p(@QVL*AxvzVTh8>%M^MCRQv(fe~8bym26_(t1q0@DiBlue!h88+P`)J zHh*^Vi$2k2Uq~>~)dP(q{~GoI1yU$gWV2)=wz)G^U&E|iT~iEJAi*Ov$4V5@S9@Lo zkvH-8|092+!7~8&tWn;+srq&nfx0W0OaE&)1*@L_;bb8kbw?pexx;rGJyDK>Kf7&R zB8}2vJf95h)~@XnxQT8Qw&2nX4#f6$mqYUoa4&hz-eeya1FyuwV;{_&?A2M~F==;| z>!fAPxe8rqQdn2T - +
          -

          Introducing Android Design: The place to learn about principles, building blocks, and patterns - for creating world-class Android user interfaces. Whether you're a UI professional or a developer - playing that role, these docs show you how to make good design decisions, big and small.

          -

          Android Design »

          +

          Introducing Google Play: An integrated digital content destination where +users buy and enjoy all of their favorite content in one place. It's the new destination for +Android apps!

          +

          Read more »

          From 6f5b5ee3212c194cd20750af7adb90f938bc8fcd Mon Sep 17 00:00:00 2001 From: Pin Ting Date: Sat, 3 Mar 2012 00:13:32 +0800 Subject: [PATCH 10/17] Fix document. Change-Id: I661b259c8438f9290d57fae29a828cf4495ce335 --- docs/html/guide/topics/media/camera.jd | 6 +++--- docs/html/training/camera/cameradirect.jd | 6 +++--- docs/html/training/camera/videobasics.jd | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/html/guide/topics/media/camera.jd b/docs/html/guide/topics/media/camera.jd index 4e928b3132642..d15668cb70277 100644 --- a/docs/html/guide/topics/media/camera.jd +++ b/docs/html/guide/topics/media/camera.jd @@ -442,7 +442,7 @@ use or does not exist will cause your application to be shut down by the system. the first, back-facing camera on a device with more than one camera.

          Checking camera features

          -

          Once you obtain access to a camera, you can get further information about its capabilties using +

          Once you obtain access to a camera, you can get further information about its capabilities using the {@link android.hardware.Camera#getParameters() Camera.getParameters()} method and checking the returned {@link android.hardware.Camera.Parameters} object for supported capabilities. When using API Level 9 or higher, use the {@link android.hardware.Camera#getCameraInfo(int, @@ -677,8 +677,8 @@ button {@link android.view.View.OnClickListener}.

           // Add a listener to the Capture button
 Button captureButton = (Button) findViewById(id.button_capture);
-    captureButton.setOnClickListener(
-        new View.OnClickListener() {
+captureButton.setOnClickListener(
+    new View.OnClickListener() {
         @Override
         public void onClick(View v) {
             // get an image from the camera
diff --git a/docs/html/training/camera/cameradirect.jd b/docs/html/training/camera/cameradirect.jd
index 03ad119bbde6c..4b6f0d2557f09 100644
--- a/docs/html/training/camera/cameradirect.jd
+++ b/docs/html/training/camera/cameradirect.jd
@@ -35,7 +35,7 @@ previous.link=videobasics.html
 the framework APIs.
          
 
 
          Directly controlling a device camera requires a lot more code than requesting pictures or videos
-from existing camera applications. However, if you want to build a specialized camera application or
+from existing camera applications. However, if you want to build a specialized camera application
 or something fully integrated in your app UI, this lesson shows you how.
          
 
 
@@ -95,7 +95,7 @@ camera sensor is picking up.
          
 
          To get started with displaying a preview, you need preview class. The
 preview requires an implementation of the {@code
 android.view.SurfaceHolder.Callback} interface, which is used to pass image
-data from the camera hardware the application.
          
+data from the camera hardware to the application.
          
 
 
           class Preview extends ViewGroup implements SurfaceHolder.Callback {
@@ -214,7 +214,7 @@ takePicture()}.
          
 
 
          Restart the Preview
          
 
-
          After a picture is taken, you must to restart the preview before the user
+
          After a picture is taken, you must restart the preview before the user
 can take another picture. In this example, the restart is done by overloading
 the shutter button.
          
 
diff --git a/docs/html/training/camera/videobasics.jd b/docs/html/training/camera/videobasics.jd
index a3512b01f0946..650e1914f3354 100644
--- a/docs/html/training/camera/videobasics.jd
+++ b/docs/html/training/camera/videobasics.jd
@@ -107,7 +107,7 @@ public static boolean isIntentAvailable(Context context, String action) {
 
          The Android Camera application returns the video in the {@link android.content.Intent} delivered
 to {@link android.app.Activity#onActivityResult onActivityResult()} as a {@link
 android.net.Uri} pointing to the video location in storage. The following code
-retrieves this image and displays it in a {@link android.widget.VideoView}.
          
+retrieves this video and displays it in a {@link android.widget.VideoView}.
          
 
 
           private void handleCameraVideo(Intent intent) {

From 9ad3d0ee5bc481933a4acb10397226ffad8e03a2 Mon Sep 17 00:00:00 2001
From: Dirk Dougherty 
Date: Tue, 6 Mar 2012 01:48:26 -0800
Subject: [PATCH 11/17] Update build-a-button to use new assets.

Change-Id: I2218af60519fa3adbe574aaedb1a72270ea3c1da
---
 docs/html/guide/publishing/publishing.jd | 33 ++++++++++++------------
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/docs/html/guide/publishing/publishing.jd b/docs/html/guide/publishing/publishing.jd
index 952e602754127..acceecf693b7e 100644
--- a/docs/html/guide/publishing/publishing.jd
+++ b/docs/html/guide/publishing/publishing.jd
@@ -456,16 +456,17 @@ web browser or the Google Play application to perform the search.
          
 
 
          Build a Google Play button
          
 
-
          Use the following form to generate an "Available on Google Play" button that you can use on
-your web site. Input either your application's package name or publisher name and the button will
-take users to Google Play to either view your application's information or view a list of
-your published apps. If users click the button while on an Android-powered device, the Google
-Play application will respond to show users your application(s).
          
+
          Use the following form to generate a "Get it on Google Play" or "Android App
+on Google Play" button that you can use on your web site. Input either your
+application's package name or publisher name and the button will take users to
+Google Play to either view your application's information or view a list of your
+published apps. If users click the button while on an Android-powered device,
+the Google Play application will respond to show users your application(s).
          
 
-
          This form offers four versions of the official "Available on Google Play" button at
-recommended sizes. If you want to create a different size, you can download an EPS file for
+
          This form offers four versions of the official brand badges at
+recommended sizes. 
 
 
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-
          
-  
           
          
-  
          
-    Previous
-    Next
-  
          
-
          
-
-
-          
-
-
          
-  
          
-    Your inventory of ready-to-use elements for creating outstanding apps.
-    

          
-    Tabs
-  
          
-
-  
-    
-  
-
          
-
-
-
-          
-
-        
          
-
-      
          
-
-      
          
-
-        
-
-        
          
-          Site Terms of Service –
-          Privacy Policy –
-          Brand Guidelines
-        
          
-
-      
          
-    
          
-
-    
-    
-    
-
-
-    
-    
-  
-
diff --git a/docs/html/design/building-blocks/index.jd b/docs/html/design/building-blocks/index.jd
new file mode 100644
index 0000000000000..52b4915f2020a
--- /dev/null
+++ b/docs/html/design/building-blocks/index.jd
@@ -0,0 +1,29 @@
+page.title=Building Blocks
+header.justLinks=1
+footer.hide=1
+@jd:body
+
+
+
+
          
+  
          
+    Your inventory of ready-to-use elements for creating outstanding apps.
+    

          
+    Tabs
+  
          
+
+  
+    
+  
+
          
diff --git a/docs/html/design/building-blocks/lists.html b/docs/html/design/building-blocks/lists.html
deleted file mode 100644
index dfd13d98486c3..0000000000000
--- a/docs/html/design/building-blocks/lists.html
+++ /dev/null
@@ -1,188 +0,0 @@
-
-
-  
-    
-    
-
-Android Design - Lists
-    
-    
-    
-    
-    
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-          
          
-            
          
-              
          Lists
          
-            
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-
-          
-
-
          Lists present multiple line items in a vertical arrangement. They can be used for data selection as
-well as drilldown navigation.
          
-
-
           
          
-
-
          
-  
          
-
-    
-
-  
          
-  
          
-
-
            
-
          1. 
-
            Section Divider
            
-
            Use section dividers to organize the content of your list into groups and facilitate scanning.
            
-
            2. 
-
          2. 
-
            Line Items
            
-
            List items can accommodate a wide range of data types in different arrangements, including
- simple single-line items, multi-line items, and custom items with icons, checkboxes, and action
- buttons.
            
-
            3. 
-
          
-
-  
          
-
          
-
-
-
-          
-          
          
-            
           
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-        
          
-
-      
          
-
-      
          
-
-        
-
-        
          
-          Site Terms of Service –
-          Privacy Policy –
-          Brand Guidelines
-        
          
-
-      
          
-    
          
-
-    
-    
-    
-
-
-    
-    
-  
-
diff --git a/docs/html/design/building-blocks/lists.jd b/docs/html/design/building-blocks/lists.jd
new file mode 100644
index 0000000000000..aaa86b85ec10e
--- /dev/null
+++ b/docs/html/design/building-blocks/lists.jd
@@ -0,0 +1,31 @@
+page.title=Lists
+@jd:body
+
+
          Lists present multiple line items in a vertical arrangement. They can be used for data selection as
+well as drilldown navigation.
          
+
+
           
          
+
+
          
+  
          
+
+    
+
+  
          
+  
          
+
+
            
+
          1. 
+
            Section Divider
            
+
            Use section dividers to organize the content of your list into groups and facilitate scanning.
            
+
            2. 
+
          2. 
+
            Line Items
            
+
            List items can accommodate a wide range of data types in different arrangements, including
+ simple single-line items, multi-line items, and custom items with icons, checkboxes, and action
+ buttons.
            
+
            3. 
+
          
+
+  
          
+
          
diff --git a/docs/html/design/building-blocks/pickers.html b/docs/html/design/building-blocks/pickers.html
deleted file mode 100644
index fc9989c82a88a..0000000000000
--- a/docs/html/design/building-blocks/pickers.html
+++ /dev/null
@@ -1,191 +0,0 @@
-
-
-  
-    
-    
-
-Android Design - Pickers
-    
-    
-    
-    
-    
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-          
          
-            
          
-              
          Pickers
          
-            
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-
-          
-
-
          Pickers provide a simple way to select a single value from a set. In addition to touching the
-up/down arrow buttons, it's possible to set the desired value from the keyboard or via a swipe
-gesture.
          
-
-
          
-  
           
          
-  
          
-
-    
-
-  
          
-  
          
-
-
          Space considerations
          
-
          Pickers can be used inline on a form, but their relatively large footprint is best suited for
-display in a dialog. For inline display, consider using more compact controls such as text fields or
-spinners.
          
-
-  
          
-
          
-
-
          Date and time pickers
          
-
-
          Android provides these as ready-to-use dialogs. Each picker is a dialog with a set of controls for
-entering the parts of the date (month, day, year) or time (hour, minute, AM/PM). Using these in your
-app helps ensure that a user's specification of a data or time input is valid and formatted
-correctly. The format of a time and date picker adjusts automatically to the locale.
          
-
-
-
-
-
-
-
-          
-          
          
-            
           
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-        
          
-
-      
          
-
-      
          
-
-        
-
-        
          
-          Site Terms of Service –
-          Privacy Policy –
-          Brand Guidelines
-        
          
-
-      
          
-    
          
-
-    
-    
-    
-
-
-    
-    
-  
-
diff --git a/docs/html/design/building-blocks/pickers.jd b/docs/html/design/building-blocks/pickers.jd
new file mode 100644
index 0000000000000..85f2187e37b24
--- /dev/null
+++ b/docs/html/design/building-blocks/pickers.jd
@@ -0,0 +1,32 @@
+page.title=Pickers
+@jd:body
+
+
          Pickers provide a simple way to select a single value from a set. In addition to touching the
+up/down arrow buttons, it's possible to set the desired value from the keyboard or via a swipe
+gesture.
          
+
+
          
+  
           
          
+  
          
+
+    
+
+  
          
+  
          
+
+
          Space considerations
          
+
          Pickers can be used inline on a form, but their relatively large footprint is best suited for
+display in a dialog. For inline display, consider using more compact controls such as text fields or
+spinners.
          
+
+  
          
+
          
+
+
          Date and time pickers
          
+
+
          Android provides these as ready-to-use dialogs. Each picker is a dialog with a set of controls for
+entering the parts of the date (month, day, year) or time (hour, minute, AM/PM). Using these in your
+app helps ensure that a user's specification of a data or time input is valid and formatted
+correctly. The format of a time and date picker adjusts automatically to the locale.
          
+
+
diff --git a/docs/html/design/building-blocks/progress.html b/docs/html/design/building-blocks/progress.html
deleted file mode 100644
index 500ccb1921970..0000000000000
--- a/docs/html/design/building-blocks/progress.html
+++ /dev/null
@@ -1,238 +0,0 @@
-
-
-  
-    
-    
-
-Android Design - Progress and Activity
-    
-    
-    
-    
-    
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-
-
-          
-
-
          
-  
          
-    
          Feedback
          
-  
          
-  
          
-    Previous
-    Next
-  
          
-
          
-
-
          When an operation of interest to the user is taking place over a relatively long period of time,
-provide visual feedback that it's still happening and in the process of being completed.
          
-
          Progress
          
-
-
          If you know the percentage of the operation that has been completed, use a determinate progress bar
-to give the user a sense of how much longer it will take.
          
-
-
-
-
          The progress bar should always travel from 0% to 100% completion. Avoid setting the bar to a lower
-value than a previous value, or using the same progress bar to represent the progress of multiple
-events, since doing so makes the display meaningless. If you're not sure how long a particular
-operation will take, use an indeterminate progress indicator.
          
-
-
           
          
-
-
-
          
-  Progress bar in Holo Dark and Holo Light.
-
          
-
-
          Activity
          
-
-
          If you don't know how much longer an operation will continue, use an indeterminate progress
-indicator. There are two styles available: a flat bar and a circle. Use the one that best fits the
-available space.
          
-
-
-
          
-  
          
-
-    
-
-  
          
-  
          
-
-    
            
-      
          1. Activity bar (shown with the Holo Dark theme)
            
-        
            
-
-An indeterminate activity bar is used at the start of an application download because Google Play hasn't
-been able to contact the server yet, and it's not possible to determine how long it will take for
-the download to begin.
-
-        
            
-      
            2. 
-    
          
-
-  
          
-
          
-
-
          
-  
          
-
-    
-
-  
          
-  
          
-
-    
            
-      
          1. Activity circle (shown with the Holo Light theme)
            
-        
            
-
-An indeterminate activity circle is used in the Gmail application when a message is being
-loaded because it's not possible to determine how long it will take to download the email.
-
-        
            
-      
            2. 
-    
          
-
-  
          
-
          
-
-
          You should only use one activity indicator on screen per activity, and it should appropriately sized
-for the surrounding context. For example, the largest activity circle works well when displayed in a
-blank content area, but not in a smaller dialog box.
          
-
-
-
-
-          
-          
          
-            
           
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-        
          
-
-      
          
-
-      
          
-
-        
-
-        
          
-          Site Terms of Service –
-          Privacy Policy –
-          Brand Guidelines
-        
          
-
-      
          
-    
          
-
-    
-    
-    
-
-
-    
-    
-  
-
diff --git a/docs/html/design/building-blocks/progress.jd b/docs/html/design/building-blocks/progress.jd
new file mode 100644
index 0000000000000..dc3ded18bad6d
--- /dev/null
+++ b/docs/html/design/building-blocks/progress.jd
@@ -0,0 +1,80 @@
+page.title=Progress and Activity
+header.title=Feedback
+@jd:body
+
+
          When an operation of interest to the user is taking place over a relatively long period of time,
+provide visual feedback that it's still happening and in the process of being completed.
          
+
          Progress
          
+
+
          If you know the percentage of the operation that has been completed, use a determinate progress bar
+to give the user a sense of how much longer it will take.
          
+
+
+
+
          The progress bar should always travel from 0% to 100% completion. Avoid setting the bar to a lower
+value than a previous value, or using the same progress bar to represent the progress of multiple
+events, since doing so makes the display meaningless. If you're not sure how long a particular
+operation will take, use an indeterminate progress indicator.
          
+
+
           
          
+
+
+
          
+  Progress bar in Holo Dark and Holo Light.
+
          
+
+
          Activity
          
+
+
          If you don't know how much longer an operation will continue, use an indeterminate progress
+indicator. There are two styles available: a flat bar and a circle. Use the one that best fits the
+available space.
          
+
+
+
          
+  
          
+
+    
+
+  
          
+  
          
+
+    
            
+      
          1. Activity bar (shown with the Holo Dark theme)
            
+        
            
+
+An indeterminate activity bar is used at the start of an application download because Google Play hasn't
+been able to contact the server yet, and it's not possible to determine how long it will take for
+the download to begin.
+
+        
            
+      
            2. 
+    
          
+
+  
          
+
          
+
+
          
+  
          
+
+    
+
+  
          
+  
          
+
+    
            
+      
          1. Activity circle (shown with the Holo Light theme)
            
+        
            
+
+An indeterminate activity circle is used in the Gmail application when a message is being
+loaded because it's not possible to determine how long it will take to download the email.
+
+        
            
+      
            2. 
+    
          
+
+  
          
+
          
+
+
          You should only use one activity indicator on screen per activity, and it should appropriately sized
+for the surrounding context. For example, the largest activity circle works well when displayed in a
+blank content area, but not in a smaller dialog box.
          
diff --git a/docs/html/design/building-blocks/scrolling.html b/docs/html/design/building-blocks/scrolling.html
deleted file mode 100644
index 3599a976b6e81..0000000000000
--- a/docs/html/design/building-blocks/scrolling.html
+++ /dev/null
@@ -1,194 +0,0 @@
-
-
-  
-    
-    
-
-Android Design - Scrolling
-    
-    
-    
-    
-    
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-          
          
-            
          
-              
          Scrolling
          
-            
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-
-          
-
-
          Scrolling allows the user to navigate to content in the overflow using a swipe gesture. The
-scrolling speed is proportional to the speed of the gesture.
          
-
          Scroll Indicator
          
-
-
          Appears during scrolling to indicate what portion of the content is currently in view.
          
-
-
          
-  
-
          
-
          
-  
           
          
-
          
-
-
          Index Scrolling
          
-
-
          In addition to traditional scrolling, a long alphabetical list can also offer index scrolling: a way
-to quickly navigate to the items that begin with a particular letter. With index scrolling, a scroll
-indicator appears even when the user isn't scrolling. Touching or dragging it causes the current
-letter to pop up in a prominent way.
          
-
-
          
-  
-
          
-
          
-  
           
          
-
          
-
-
-
-          
-          
          
-            
           
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-        
          
-
-      
          
-
-      
          
-
-        
-
-        
          
-          Site Terms of Service –
-          Privacy Policy –
-          Brand Guidelines
-        
          
-
-      
          
-    
          
-
-    
-    
-    
-
-
-    
-    
-  
-
diff --git a/docs/html/design/building-blocks/scrolling.jd b/docs/html/design/building-blocks/scrolling.jd
new file mode 100644
index 0000000000000..7695157a15cff
--- /dev/null
+++ b/docs/html/design/building-blocks/scrolling.jd
@@ -0,0 +1,37 @@
+page.title=Scrolling
+@jd:body
+
+
          Scrolling allows the user to navigate to content in the overflow using a swipe gesture. The
+scrolling speed is proportional to the speed of the gesture.
          
+
          Scroll Indicator
          
+
+
          Appears during scrolling to indicate what portion of the content is currently in view.
          
+
+
          
+  
+
          
+
          
+  
           
          
+
          
+
+
          Index Scrolling
          
+
+
          In addition to traditional scrolling, a long alphabetical list can also offer index scrolling: a way
+to quickly navigate to the items that begin with a particular letter. With index scrolling, a scroll
+indicator appears even when the user isn't scrolling. Touching or dragging it causes the current
+letter to pop up in a prominent way.
          
+
+
          
+  
+
          
+
          
+  
           
          
+
          
diff --git a/docs/html/design/building-blocks/seek-bars.html b/docs/html/design/building-blocks/seek-bars.html
deleted file mode 100644
index aef1823d00064..0000000000000
--- a/docs/html/design/building-blocks/seek-bars.html
+++ /dev/null
@@ -1,194 +0,0 @@
-
-
-  
-    
-    
-
-Android Design - Seek Bars and Sliders
-    
-    
-    
-    
-    
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-          
          
-            
          
-              
          Seek Bars and Sliders
          
-            
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-
-          
-
-
          Interactive sliders make it possible to select a value from a continuous or discrete range of values
-by moving the slider thumb. The smallest value is to the left, the largest to the right. The
-interactive nature of the slider makes it a great choice for settings that reflect intensity levels,
-such as volume, brightness, or color saturation.
          
-
-
          
-  
          
-
-    
-
-  
          
-  
          
-
-
           
          
-
-
          Example
          
-
          Interactive slider to set the ringer volume. The value can either be set through the hardware volume controls or interactively via a gesture.
          
-
-  
          
-
          
-
-
-
          
-  
          
-
-    
-    
          
-      Seek bars in Holo Light & Dark
-    
          
-
-  
          
-  
           
          
-
          
-
-
-
-
-          
-          
          
-            
           
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-        
          
-
-      
          
-
-      
          
-
-        
-
-        
          
-          Site Terms of Service –
-          Privacy Policy –
-          Brand Guidelines
-        
          
-
-      
          
-    
          
-
-    
-    
-    
-
-
-    
-    
-  
-
diff --git a/docs/html/design/building-blocks/seek-bars.jd b/docs/html/design/building-blocks/seek-bars.jd
new file mode 100644
index 0000000000000..3407ddd07050a
--- /dev/null
+++ b/docs/html/design/building-blocks/seek-bars.jd
@@ -0,0 +1,36 @@
+page.title=Seek Bars and Sliders
+@jd:body
+
+
          Interactive sliders make it possible to select a value from a continuous or discrete range of values
+by moving the slider thumb. The smallest value is to the left, the largest to the right. The
+interactive nature of the slider makes it a great choice for settings that reflect intensity levels,
+such as volume, brightness, or color saturation.
          
+
+
          
+  
          
+
+    
+
+  
          
+  
          
+
+
           
          
+
+
          Example
          
+
          Interactive slider to set the ringer volume. The value can either be set through the hardware volume controls or interactively via a gesture.
          
+
+  
          
+
          
+
+
+
          
+  
          
+
+    
+    
          
+      Seek bars in Holo Light & Dark
+    
          
+
+  
          
+  
           
          
+
          
diff --git a/docs/html/design/building-blocks/spinners.html b/docs/html/design/building-blocks/spinners.html
deleted file mode 100644
index 5ef9d04878a1e..0000000000000
--- a/docs/html/design/building-blocks/spinners.html
+++ /dev/null
@@ -1,194 +0,0 @@
-
-
-  
-    
-    
-
-Android Design - Spinners
-    
-    
-    
-    
-    
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-          
          
-            
          
-              
          Spinners
          
-            
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-
-          
-
-
          Spinners provide a quick way to select one value from a set. In the default state, a spinner shows
-its currently selected value. Touching the spinner displays a dropdown menu with all other available
-values, from which the user can select a new one.
          
-
-
-
          
-  
          
-
-    
-
-
          Spinners in forms
          
-
          Spinners are useful for data picking in forms. They are compact and integrate nicely with other
-components. Use spinners in forms for both simple data input and in combination with other input
-fields. For example, a text field might let you edit an email address for a contact, while its
-associated spinner allows you to select whether it's a Home or Work address.
          
-
-  
          
-  
          
-
-    
-
-
          Spinners in action bars
          
-
          Use spinners in action bars to switch views. For example, Gmail uses a spinner to permit switching
-between accounts or commonly used labels. Spinners are useful when changing the view is important to
-your app, but not necessarily a frequent occurrence. In cases where view switching is frequent, use
-tabs.
          
-
-  
          
-
          
-
-
-
          
-  Spinners in the Holo Dark and Holo Light themes, in various states.
-
          
-
-
-
-          
-          
          
-            
           
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-        
          
-
-      
          
-
-      
          
-
-        
-
-        
          
-          Site Terms of Service –
-          Privacy Policy –
-          Brand Guidelines
-        
          
-
-      
          
-    
          
-
-    
-    
-    
-
-
-    
-    
-  
-
diff --git a/docs/html/design/building-blocks/spinners.jd b/docs/html/design/building-blocks/spinners.jd
new file mode 100644
index 0000000000000..621a57ce74413
--- /dev/null
+++ b/docs/html/design/building-blocks/spinners.jd
@@ -0,0 +1,37 @@
+page.title=Spinners
+@jd:body
+
+
          Spinners provide a quick way to select one value from a set. In the default state, a spinner shows
+its currently selected value. Touching the spinner displays a dropdown menu with all other available
+values, from which the user can select a new one.
          
+
+
+
          
+  
          
+
+    
+
+
          Spinners in forms
          
+
          Spinners are useful for data picking in forms. They are compact and integrate nicely with other
+components. Use spinners in forms for both simple data input and in combination with other input
+fields. For example, a text field might let you edit an email address for a contact, while its
+associated spinner allows you to select whether it's a Home or Work address.
          
+
+  
          
+  
          
+
+    
+
+
          Spinners in action bars
          
+
          Use spinners in action bars to switch views. For example, Gmail uses a spinner to permit switching
+between accounts or commonly used labels. Spinners are useful when changing the view is important to
+your app, but not necessarily a frequent occurrence. In cases where view switching is frequent, use
+tabs.
          
+
+  
          
+
          
+
+
+
          
+  Spinners in the Holo Dark and Holo Light themes, in various states.
+
          
diff --git a/docs/html/design/building-blocks/switches.html b/docs/html/design/building-blocks/switches.html
deleted file mode 100644
index 09af540995ff8..0000000000000
--- a/docs/html/design/building-blocks/switches.html
+++ /dev/null
@@ -1,188 +0,0 @@
-
-
-  
-    
-    
-
-Android Design - Switches
-    
-    
-    
-    
-    
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-          
          
-            
          
-              
          Switches
          
-            
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-
-          
-
-
          Switches allow the user to select options. There are three kinds of switches: checkboxes, radio
-buttons, and on/off switches.
          
-
          Checkboxes
          
-
-
          Checkboxes allow the user to select multiple options from a set. Avoid using a single checkbox to
-turn an option off or on. Instead, use an on/off switch.
          
-
-
          
-  
-
          
-
-
          Radio Buttons
          
-
-
          Radio buttons allow the user to select one option from a set. Use radio buttons for exclusive
-selection if you think that the user needs to see all available options side-by-side. Otherwise,
-consider a spinner, which uses less space.
          
-
-
          
-  
-
          
-
-
          On/off Switches
          
-
-
          On/off switches toggle the state of a single settings option.
          
-
-
          
-  
-
          
-
-
-
-          
-          
          
-            
           
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-        
          
-
-      
          
-
-      
          
-
-        
-
-        
          
-          Site Terms of Service –
-          Privacy Policy –
-          Brand Guidelines
-        
          
-
-      
          
-    
          
-
-    
-    
-    
-
-
-    
-    
-  
-
diff --git a/docs/html/design/building-blocks/switches.jd b/docs/html/design/building-blocks/switches.jd
new file mode 100644
index 0000000000000..607e0b6a08276
--- /dev/null
+++ b/docs/html/design/building-blocks/switches.jd
@@ -0,0 +1,31 @@
+page.title=Switches
+@jd:body
+
+
          Switches allow the user to select options. There are three kinds of switches: checkboxes, radio
+buttons, and on/off switches.
          
+
          Checkboxes
          
+
+
          Checkboxes allow the user to select multiple options from a set. Avoid using a single checkbox to
+turn an option off or on. Instead, use an on/off switch.
          
+
+
          
+  
+
          
+
+
          Radio Buttons
          
+
+
          Radio buttons allow the user to select one option from a set. Use radio buttons for exclusive
+selection if you think that the user needs to see all available options side-by-side. Otherwise,
+consider a spinner, which uses less space.
          
+
+
          
+  
+
          
+
+
          On/off Switches
          
+
+
          On/off switches toggle the state of a single settings option.
          
+
+
          
+  
+
          
diff --git a/docs/html/design/building-blocks/tabs.html b/docs/html/design/building-blocks/tabs.html
deleted file mode 100644
index 029e484e7a581..0000000000000
--- a/docs/html/design/building-blocks/tabs.html
+++ /dev/null
@@ -1,217 +0,0 @@
-
-
-  
-    
-    
-
-Android Design - Tabs
-    
-    
-    
-    
-    
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-          
          
-            
          
-              
          Tabs
          
-            
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-
-          
-
-
-
-
          Tabs in the action bar make it easy to explore and switch between different views or functional
-aspects of your app, or to browse categorized data sets.
          
-
-
-
          Scrollable Tabs
          
-
-
-
          
-  
          
-
-
          Scrolling tab controls can contain a larger number of items than a standard tab control. To navigate
-to the next/previous view, swipe left or right.
          
-
-  
          
-  
          
-
-    
-    
          
-      Scrolling tabs on Google Play.
-      
           
          
-    
          
-
-  
          
-
          
-
-
-
          Fixed Tabs
          
-
-
-
          Fixed tabs display all items concurrently. To navigate to a different view, touch the tab.
          
-
-
-
          
-  Tabs in Holo Dark & Light.
-
          
-
-
-
          
-  Tabs in the YouTube app.
-
          
-
-
-
-
          Stacked Tabs
          
-
-
-
          If view navigation is essential to your app, you can break out tabs into a separate action bar. This
-permits fast view switching even on narrower screens.
          
-
-
-
-
-
-
-          
-          
          
-            
           
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-        
          
-
-      
          
-
-      
          
-
-        
-
-        
          
-          Site Terms of Service –
-          Privacy Policy –
-          Brand Guidelines
-        
          
-
-      
          
-    
          
-
-    
-    
-    
-
-
-    
-    
-  
-
diff --git a/docs/html/design/building-blocks/tabs.jd b/docs/html/design/building-blocks/tabs.jd
new file mode 100644
index 0000000000000..2c854d3c9f916
--- /dev/null
+++ b/docs/html/design/building-blocks/tabs.jd
@@ -0,0 +1,59 @@
+page.title=Tabs
+@jd:body
+
+
+
+
          Tabs in the action bar make it easy to explore and switch between different views or functional
+aspects of your app, or to browse categorized data sets.
          
+
+
+
          Scrollable Tabs
          
+
+
+
          
+  
          
+
+
          Scrolling tab controls can contain a larger number of items than a standard tab control. To navigate
+to the next/previous view, swipe left or right.
          
+
+  
          
+  
          
+
+    
+    
          
+      Scrolling tabs in Google Play.
+      
           
          
+    
          
+
+  
          
+
          
+
+
+
          Fixed Tabs
          
+
+
+
          Fixed tabs display all items concurrently. To navigate to a different view, touch the tab.
          
+
+
+
          
+  Tabs in Holo Dark & Light.
+
          
+
+
+
          
+  Tabs in the YouTube app.
+
          
+
+
+
+
          Stacked Tabs
          
+
+
+
          If view navigation is essential to your app, you can break out tabs into a separate action bar. This
+permits fast view switching even on narrower screens.
          
+
+
diff --git a/docs/html/design/building-blocks/text-fields.html b/docs/html/design/building-blocks/text-fields.html
deleted file mode 100644
index b9ec42d7207db..0000000000000
--- a/docs/html/design/building-blocks/text-fields.html
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-  
-    
-    
-
-Android Design - Text Fields
-    
-    
-    
-    
-    
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-          
          
-            
          
-              
          Text Fields
          
-            
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-
-          
-
-
          Text fields allow the user to type text into your app. They can be either single line or multi-line.
-Touching a text field places the cursor and automatically displays the keyboard. In addition to
-typing, text fields allow for a variety of other activities, such as text selection (cut, copy,
-paste) and data lookup via auto-completion.
          
-
-
-
          
-  
          
-
-    
-
-  
          
-
          
-
-
          Single line and multi line
          
-
          Single-line fields automatically scroll their content to the left as the text input cursor reaches
-the right edge of the input field. Multi-line text fields automatically break to a new line for
-overflow text and scroll vertically when the cursor reaches the lower edge.
          
-
-
-
-
          
-  
          
-
-
          Text field types
          
-
          Text fields can have different types, such as number, message, or email address. The type determines
-what kind of characters are allowed inside the field, and may prompt the virtual keyboard to
-optimize its layout for frequently used characters.
          
-
-  
          
-  
          
-
-
          Auto-complete text fields
          
-
          Use auto-complete text fields to present real-time completions or search results in popups, so users
-can enter information more accurately and efficiently.
          
-
-  
          
-
          
-
-
          Text Selection
          
-
-
          Users can select any word in a text field with a long press. This action triggers a text selection
-mode that facilitates extending the selection or choosing an action to perform on the selected text.
-Selection mode includes:
          
-
-
          
-  
          
-
-    
-
-  
          
-  
          
-
-
            
-
          1. 
-
            Contextual action bar
            
-
            A contextual action bar (CAB) displays the actions available to perform on the selection:
- typically cut, copy, and paste, but apps can insert additional commands as needed.
            
-
            2. 
-
          2. 
-
            Selection handles
            
-
            Selection handles can be dragged to select more or less text while remaining in selection mode.
            
-
            3. 
-
          
-
-  
          
-
          
-
-
-
-          
-          
          
-            
           
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-        
          
-
-      
          
-
-      
          
-
-        
-
-        
          
-          Site Terms of Service –
-          Privacy Policy –
-          Brand Guidelines
-        
          
-
-      
          
-    
          
-
-    
-    
-    
-
-
-    
-    
-  
-
diff --git a/docs/html/design/building-blocks/text-fields.jd b/docs/html/design/building-blocks/text-fields.jd
new file mode 100644
index 0000000000000..1b10420db4f37
--- /dev/null
+++ b/docs/html/design/building-blocks/text-fields.jd
@@ -0,0 +1,70 @@
+page.title=Text Fields
+@jd:body
+
+
          Text fields allow the user to type text into your app. They can be either single line or multi-line.
+Touching a text field places the cursor and automatically displays the keyboard. In addition to
+typing, text fields allow for a variety of other activities, such as text selection (cut, copy,
+paste) and data lookup via auto-completion.
          
+
+
+
          
+  
          
+
+    
+
+  
          
+
          
+
+
          Single line and multi line
          
+
          Single-line fields automatically scroll their content to the left as the text input cursor reaches
+the right edge of the input field. Multi-line text fields automatically break to a new line for
+overflow text and scroll vertically when the cursor reaches the lower edge.
          
+
+
+
+
          
+  
          
+
+
          Text field types
          
+
          Text fields can have different types, such as number, message, or email address. The type determines
+what kind of characters are allowed inside the field, and may prompt the virtual keyboard to
+optimize its layout for frequently used characters.
          
+
+  
          
+  
          
+
+
          Auto-complete text fields
          
+
          Use auto-complete text fields to present real-time completions or search results in popups, so users
+can enter information more accurately and efficiently.
          
+
+  
          
+
          
+
+
          Text Selection
          
+
+
          Users can select any word in a text field with a long press. This action triggers a text selection
+mode that facilitates extending the selection or choosing an action to perform on the selected text.
+Selection mode includes:
          
+
+
          
+  
          
+
+    
+
+  
          
+  
          
+
+
            
+
          1. 
+
            Contextual action bar
            
+
            A contextual action bar (CAB) displays the actions available to perform on the selection:
+ typically cut, copy, and paste, but apps can insert additional commands as needed.
            
+
            2. 
+
          2. 
+
            Selection handles
            
+
            Selection handles can be dragged to select more or less text while remaining in selection mode.
            
+
            3. 
+
          
+
+  
          
+
          
diff --git a/docs/html/design/design_toc.cs b/docs/html/design/design_toc.cs
new file mode 100644
index 0000000000000..19b58d9796659
--- /dev/null
+++ b/docs/html/design/design_toc.cs
@@ -0,0 +1,69 @@
+
\ No newline at end of file
diff --git a/docs/html/design/downloads/index.html b/docs/html/design/downloads/index.html
deleted file mode 100644
index f910b29a9cf72..0000000000000
--- a/docs/html/design/downloads/index.html
+++ /dev/null
@@ -1,278 +0,0 @@
-
-
-  
-    
-    
-
-Android Design - Downloads
-    
-    
-    
-    
-    
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-          
          
-            
          
-              
          Downloads
          
-            
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-
-          
-
-
          
-  
          
-
-
          Want everything? We've bundled all the downloads available on Android Design into a single ZIP file.
-You can also download individual files listed below.
          
-
          You may use these materials without restriction in your apps and to develop your apps.
          
-
-  
          
-  
          
-
-
          
-  Download All
-
          
-
-  
          
-
          
-
-
          Stencils and Sources
          
-
-
          
-  
          
-
-
          Drag and drop your way to beautifully designed Ice Cream Sandwich apps. The stencils feature the
-rich typography, colors, interactive controls, and icons found throughout Android 4.0, along with
-phone and tablet outlines to frame your creations. Source files for icons and controls are also
-available.
          
-
-  
          
-  
          
-
-    
-
-  
          
-  
          
-
-
          
-  Adobe® Fireworks® PNG Stencil
-  Omni® OmniGraffle® Stencil
-  Adobe® Photoshop® Sources
-
          
-
-  
          
-
          
-
-
          Action Bar Icon Pack
          
-
-
          
-  
          
-
-
          Action bar icons are graphic buttons that represent the most important actions people can take
-within your app. More on Action Bar Iconography
          
-
          The download package includes icons that are scaled for various screen densities and suitable for
-use with the Holo Light and Holo Dark themes. The package also includes unstyled icons that you can
-modify to match your theme, plus source files.
          
-
-  
          
-  
          
-
-    
-
-  
          
-  
          
-
-
          
-  Action Bar Icon Pack
-
          
-
-  
          
-
          
-
-
          Style
          
-
-
          
-  
          
-
-
          Roboto
          
-
          Ice Cream Sandwich introduced a new type family named Roboto, created specifically for the
-requirements of UI and high-resolution screens.
          
-
          More on Roboto
          
-
-  
          
-  
          
-
-    
-
-  
          
-  
          
-
-
          
-  Roboto
-  Specimen Book
-
          
-
-  
          
-
          
-
-
          
-  
          
-
-
          Color
          
-
          Blue is the standard accent color in Android's color palette. Each color has a corresponding darker
-shade that can be used as a complement when needed.
          
-
          More on Color
          
-
-  
          
-  
          
-
-    
-
-  
          
-  
          
-
-
          
-  Color Swatches
-
          
-
-  
          
-
          
-
-
-
-          
-          
          
-            
           
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-        
          
-
-      
          
-
-      
          
-
-        
-
-        
          
-          Site Terms of Service –
-          Privacy Policy –
-          Brand Guidelines
-        
          
-
-      
          
-    
          
-
-    
-    
-    
-
-
-    
-    
-  
-
diff --git a/docs/html/design/downloads/index.jd b/docs/html/design/downloads/index.jd
new file mode 100644
index 0000000000000..618c44b8fddf8
--- /dev/null
+++ b/docs/html/design/downloads/index.jd
@@ -0,0 +1,121 @@
+page.title=Downloads
+@jd:body
+
+
          
+  
          
+
+
          Want everything? We've bundled all the downloads available on Android Design into a single ZIP file.
+You can also download individual files listed below.
          
+
          You may use these materials without restriction in your apps and to develop your apps.
          
+
+  
          
+  
          
+
+
          
+  Download All
+
          
+
+  
          
+
          
+
+
          Stencils and Sources
          
+
+
          
+  
          
+
+
          Drag and drop your way to beautifully designed Ice Cream Sandwich apps. The stencils feature the
+rich typography, colors, interactive controls, and icons found throughout Android 4.0, along with
+phone and tablet outlines to frame your creations. Source files for icons and controls are also
+available.
          
+
+  
          
+  
          
+
+    
+
+  
          
+  
          
+
+
          
+  Adobe® Fireworks® PNG Stencil
+  Omni® OmniGraffle® Stencil
+  Adobe® Photoshop® Sources
+
          
+
+  
          
+
          
+
+
          Action Bar Icon Pack
          
+
+
          
+  
          
+
+
          Action bar icons are graphic buttons that represent the most important actions people can take
+within your app. More on Action Bar Iconography
          
+
          The download package includes icons that are scaled for various screen densities and suitable for
+use with the Holo Light and Holo Dark themes. The package also includes unstyled icons that you can
+modify to match your theme, plus source files.
          
+
+  
          
+  
          
+
+    
+
+  
          
+  
          
+
+
          
+  Action Bar Icon Pack
+
          
+
+  
          
+
          
+
+
          Style
          
+
+
          
+  
          
+
+
          Roboto
          
+
          Ice Cream Sandwich introduced a new type family named Roboto, created specifically for the
+requirements of UI and high-resolution screens.
          
+
          More on Roboto
          
+
+  
          
+  
          
+
+    
+
+  
          
+  
          
+
+
          
+  Roboto
+  Specimen Book
+
          
+
+  
          
+
          
+
+
          
+  
          
+
+
          Color
          
+
          Blue is the standard accent color in Android's color palette. Each color has a corresponding darker
+shade that can be used as a complement when needed.
          
+
          More on Color
          
+
+  
          
+  
          
+
+    
+
+  
          
+  
          
+
+
          
+  Color Swatches
+
          
+
+  
          
+
          
diff --git a/docs/html/design/get-started/creative-vision.html b/docs/html/design/get-started/creative-vision.html
deleted file mode 100644
index 154f8d08a785a..0000000000000
--- a/docs/html/design/get-started/creative-vision.html
+++ /dev/null
@@ -1,205 +0,0 @@
-
-
-  
-    
-    
-
-Android Design - Creative Vision
-    
-    
-    
-    
-    
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-          
          
-            
          
-              
          Creative Vision
          
-            
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-
-          
-
-
-
-
           
          
-
-
          Ice Cream Sandwich (Android 4.0) marks a major milestone for Android design. We touched nearly every
-pixel of the system as we expanded the new design approaches introduced in Honeycomb tablets to all
-types of mobile devices. Starting with the most basic elements, we introduced a new font, Roboto,
-designed for high-resolution displays. Other big changes include framework-level action bars on
-phones and support for new phones without physical buttons.
          
-
          We focused the design work with three overarching goals for our core apps and the system at large.
-As you design apps to work with Android, consider these goals:
          
-
-
           
          
-
-
          
-  
          
-
-
          Enchant me
          
-
          Beauty is more than skin deep. Android apps are sleek and aesthetically pleasing on multiple levels.
-Transitions are fast and clear; layout and typography are crisp and meaningful. App icons are works
-of art in their own right. Just like a well-made tool, your app should strive to combine beauty,
-simplicity and purpose to create a magical experience that is effortless and powerful.
          
-
-  
          
-  
          
-
-
          Simplify my life
          
-
          Android apps make life easier and are easy to understand. When people use your app for the first
-time, they should intuitively grasp the most important features. The design work doesn't stop at the
-first use, though. Android apps remove ongoing chores like file management and syncing. Simple tasks
-never require complex procedures, and complex tasks are tailored to the human hand and mind. People
-of all ages and cultures feel firmly in control, and are never overwhelmed by too many choices or
-irrelevant flash.
          
-
-  
          
-  
          
-
-
          Make me amazing
          
-
          It's not enough to make an app that is easy to use. Android apps empower people to try new things
-and to use apps in inventive new ways. Android lets people combine applications into new workflows
-through multitasking, notifications, and sharing across apps. At the same time, your app should feel
-personal, giving people access to superb technology with clarity and grace.
          
-
-  
          
-
          
-
-
-
-          
-          
          
-            
           
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-        
          
-
-      
          
-
-      
          
-
-        
-
-        
          
-          Site Terms of Service –
-          Privacy Policy –
-          Brand Guidelines
-        
          
-
-      
          
-    
          
-
-    
-    
-    
-
-
-    
-    
-  
-
diff --git a/docs/html/design/get-started/creative-vision.jd b/docs/html/design/get-started/creative-vision.jd
new file mode 100644
index 0000000000000..792b97d6d6163
--- /dev/null
+++ b/docs/html/design/get-started/creative-vision.jd
@@ -0,0 +1,48 @@
+page.title=Creative Vision
+@jd:body
+
+
+
+
           
          
+
+
          Ice Cream Sandwich (Android 4.0) marks a major milestone for Android design. We touched nearly every
+pixel of the system as we expanded the new design approaches introduced in Honeycomb tablets to all
+types of mobile devices. Starting with the most basic elements, we introduced a new font, Roboto,
+designed for high-resolution displays. Other big changes include framework-level action bars on
+phones and support for new phones without physical buttons.
          
+
          We focused the design work with three overarching goals for our core apps and the system at large.
+As you design apps to work with Android, consider these goals:
          
+
+
           
          
+
+
          
+  
          
+
+
          Enchant me
          
+
          Beauty is more than skin deep. Android apps are sleek and aesthetically pleasing on multiple levels.
+Transitions are fast and clear; layout and typography are crisp and meaningful. App icons are works
+of art in their own right. Just like a well-made tool, your app should strive to combine beauty,
+simplicity and purpose to create a magical experience that is effortless and powerful.
          
+
+  
          
+  
          
+
+
          Simplify my life
          
+
          Android apps make life easier and are easy to understand. When people use your app for the first
+time, they should intuitively grasp the most important features. The design work doesn't stop at the
+first use, though. Android apps remove ongoing chores like file management and syncing. Simple tasks
+never require complex procedures, and complex tasks are tailored to the human hand and mind. People
+of all ages and cultures feel firmly in control, and are never overwhelmed by too many choices or
+irrelevant flash.
          
+
+  
          
+  
          
+
+
          Make me amazing
          
+
          It's not enough to make an app that is easy to use. Android apps empower people to try new things
+and to use apps in inventive new ways. Android lets people combine applications into new workflows
+through multitasking, notifications, and sharing across apps. At the same time, your app should feel
+personal, giving people access to superb technology with clarity and grace.
          
+
+  
          
+
          
diff --git a/docs/html/design/get-started/principles.html b/docs/html/design/get-started/principles.html
deleted file mode 100644
index f10a90dd68b24..0000000000000
--- a/docs/html/design/get-started/principles.html
+++ /dev/null
@@ -1,457 +0,0 @@
-
-
-  
-    
-    
-
-Android Design - Design Principles
-    
-    
-    
-    
-    
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-          
          
-            
          
-              
          Design Principles
          
-            
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-
-          
-
-
          These design principles were developed by and for the Android User Experience Team to keep users'
-best interests in mind. Consider them as you apply your own creativity and design thinking. Deviate
-with purpose.
          
-
-
          Enchant Me
          
-
-
          
-  
          
-
-
          Delight me in surprising ways
          
-
          A beautiful surface, a carefully-placed animation, or a well-timed sound effect is a joy to
-experience. Subtle effects contribute to a feeling of effortlessness and a sense that a powerful
-force is at hand.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
           
          
-
-
          
-  
          
-
-
          Real objects are more fun than buttons and menus
          
-
          Allow people to directly touch and manipulate objects in your app. It reduces the cognitive effort
-needed to perform a task while making it more emotionally satisfying.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
           
          
-
-
          
-  
          
-
-
          Let me make it mine
          
-
          People love to add personal touches because it helps them feel at home and in control. Provide
-sensible, beautiful defaults, but also consider fun, optional customizations that don't hinder
-primary tasks.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
           
          
-
-
          
-  
          
-
-
          Get to know me
          
-
          Learn peoples' preferences over time. Rather than asking them to make the same choices over and
-over, place previous choices within easy reach.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
          Simplify My Life
          
-
-
          
-  
          
-
-
          Keep it brief
          
-
          Use short phrases with simple words. People are likely to skip sentences if they're long.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
           
          
-
-
          
-  
          
-
-
          Pictures are faster than words
          
-
          Consider using pictures to explain ideas. They get people's attention and can be much more efficient
-than words.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
           
          
-
-
          
-  
          
-
-
          Decide for me but let me have the final say
          
-
          Take your best guess and act rather than asking first. Too many choices and decisions make people
-unhappy. Just in case you get it wrong, allow for 'undo'.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
           
          
-
-
          
-  
          
-
-
          Only show what I need when I need it
          
-
          People get overwhelmed when they see too much at once. Break tasks and information into small,
-digestible chunks. Hide options that aren't essential at the moment, and teach people as they go.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
           
          
-
-
          
-  
          
-
-
          I should always know where I am
          
-
          Give people confidence that they know their way around. Make places in your app look distinct and
-use transitions to show relationships among screens. Provide feedback on tasks in progress.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
           
          
-
-
          
-  
          
-
-
          Never lose my stuff
          
-
          Save what people took time to create and let them access it from anywhere. Remember settings,
-personal touches, and creations across phones, tablets, and computers. It makes upgrading the
-easiest thing in the world.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
           
          
-
-
          
-  
          
-
-
          If it looks the same, it should act the same
          
-
          Help people discern functional differences by making them visually distinct rather than subtle.
-Avoid modes, which are places that look similar but act differently on the same input.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
           
          
-
-
          
-  
          
-
-
          Only interrupt me if it's important
          
-
          Like a good personal assistant, shield people from unimportant minutiae. People want to stay
-focused, and unless it's critical and time-sensitive, an interruption can be taxing and frustrating.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
          Make Me Amazing
          
-
-
          
-  
          
-
-
          Give me tricks that work everywhere
          
-
          People feel great when they figure things out for themselves. Make your app easier to learn by
-leveraging visual patterns and muscle memory from other Android apps. For example, the swipe gesture
-may be a good navigational shortcut.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
           
          
-
-
          
-  
          
-
-
          It's not my fault
          
-
          Be gentle in how you prompt people to make corrections. They want to feel smart when they use your
-app. If something goes wrong, give clear recovery instructions but spare them the technical details.
-If you can fix it behind the scenes, even better.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
           
          
-
-
          
-  
          
-
-
          Sprinkle encouragement
          
-
          Break complex tasks into smaller steps that can be easily accomplished. Give feedback on actions,
-even if it's just a subtle glow.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
           
          
-
-
          
-  
          
-
-
          Do the heavy lifting for me
          
-
          Make novices feel like experts by enabling them to do things they never thought they could. For
-example, shortcuts that combine multiple photo effects can make amateur photographs look amazing in
-only a few steps.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
           
          
-
-
          
-  
          
-
-
          Make important things fast
          
-
          Not all actions are equal. Decide what's most important in your app and make it easy to find and
-fast to use, like the shutter button in a camera, or the pause button in a music player.
          
-
-  
          
-  
          
-
-    
-
-  
          
-
          
-
-
-
-          
-          
          
-            
           
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-        
          
-
-      
          
-
-      
          
-
-        
-
-        
          
-          Site Terms of Service –
-          Privacy Policy –
-          Brand Guidelines
-        
          
-
-      
          
-    
          
-
-    
-    
-    
-
-
-    
-    
-  
-
diff --git a/docs/html/design/get-started/principles.jd b/docs/html/design/get-started/principles.jd
new file mode 100644
index 0000000000000..8f5b44642ea77
--- /dev/null
+++ b/docs/html/design/get-started/principles.jd
@@ -0,0 +1,300 @@
+page.title=Design Principles
+@jd:body
+
+
          These design principles were developed by and for the Android User Experience Team to keep users'
+best interests in mind. Consider them as you apply your own creativity and design thinking. Deviate
+with purpose.
          
+
+
          Enchant Me
          
+
+
          
+  
          
+
+
          Delight me in surprising ways
          
+
          A beautiful surface, a carefully-placed animation, or a well-timed sound effect is a joy to
+experience. Subtle effects contribute to a feeling of effortlessness and a sense that a powerful
+force is at hand.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
           
          
+
+
          
+  
          
+
+
          Real objects are more fun than buttons and menus
          
+
          Allow people to directly touch and manipulate objects in your app. It reduces the cognitive effort
+needed to perform a task while making it more emotionally satisfying.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
           
          
+
+
          
+  
          
+
+
          Let me make it mine
          
+
          People love to add personal touches because it helps them feel at home and in control. Provide
+sensible, beautiful defaults, but also consider fun, optional customizations that don't hinder
+primary tasks.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
           
          
+
+
          
+  
          
+
+
          Get to know me
          
+
          Learn peoples' preferences over time. Rather than asking them to make the same choices over and
+over, place previous choices within easy reach.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
          Simplify My Life
          
+
+
          
+  
          
+
+
          Keep it brief
          
+
          Use short phrases with simple words. People are likely to skip sentences if they're long.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
           
          
+
+
          
+  
          
+
+
          Pictures are faster than words
          
+
          Consider using pictures to explain ideas. They get people's attention and can be much more efficient
+than words.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
           
          
+
+
          
+  
          
+
+
          Decide for me but let me have the final say
          
+
          Take your best guess and act rather than asking first. Too many choices and decisions make people
+unhappy. Just in case you get it wrong, allow for 'undo'.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
           
          
+
+
          
+  
          
+
+
          Only show what I need when I need it
          
+
          People get overwhelmed when they see too much at once. Break tasks and information into small,
+digestible chunks. Hide options that aren't essential at the moment, and teach people as they go.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
           
          
+
+
          
+  
          
+
+
          I should always know where I am
          
+
          Give people confidence that they know their way around. Make places in your app look distinct and
+use transitions to show relationships among screens. Provide feedback on tasks in progress.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
           
          
+
+
          
+  
          
+
+
          Never lose my stuff
          
+
          Save what people took time to create and let them access it from anywhere. Remember settings,
+personal touches, and creations across phones, tablets, and computers. It makes upgrading the
+easiest thing in the world.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
           
          
+
+
          
+  
          
+
+
          If it looks the same, it should act the same
          
+
          Help people discern functional differences by making them visually distinct rather than subtle.
+Avoid modes, which are places that look similar but act differently on the same input.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
           
          
+
+
          
+  
          
+
+
          Only interrupt me if it's important
          
+
          Like a good personal assistant, shield people from unimportant minutiae. People want to stay
+focused, and unless it's critical and time-sensitive, an interruption can be taxing and frustrating.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
          Make Me Amazing
          
+
+
          
+  
          
+
+
          Give me tricks that work everywhere
          
+
          People feel great when they figure things out for themselves. Make your app easier to learn by
+leveraging visual patterns and muscle memory from other Android apps. For example, the swipe gesture
+may be a good navigational shortcut.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
           
          
+
+
          
+  
          
+
+
          It's not my fault
          
+
          Be gentle in how you prompt people to make corrections. They want to feel smart when they use your
+app. If something goes wrong, give clear recovery instructions but spare them the technical details.
+If you can fix it behind the scenes, even better.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
           
          
+
+
          
+  
          
+
+
          Sprinkle encouragement
          
+
          Break complex tasks into smaller steps that can be easily accomplished. Give feedback on actions,
+even if it's just a subtle glow.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
           
          
+
+
          
+  
          
+
+
          Do the heavy lifting for me
          
+
          Make novices feel like experts by enabling them to do things they never thought they could. For
+example, shortcuts that combine multiple photo effects can make amateur photographs look amazing in
+only a few steps.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
+
+
           
          
+
+
          
+  
          
+
+
          Make important things fast
          
+
          Not all actions are equal. Decide what's most important in your app and make it easy to find and
+fast to use, like the shutter button in a camera, or the pause button in a music player.
          
+
+  
          
+  
          
+
+    
+
+  
          
+
          
diff --git a/docs/html/design/get-started/ui-overview.html b/docs/html/design/get-started/ui-overview.html
deleted file mode 100644
index a4881d5072a1d..0000000000000
--- a/docs/html/design/get-started/ui-overview.html
+++ /dev/null
@@ -1,306 +0,0 @@
-
-
-  
-    
-    
-
-Android Design - UI Overview
-    
-    
-    
-    
-    
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-          
          
-            
          
-              
          UI Overview
          
-            
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-
-          
-
-
          Android's system UI provides the framework on top of which you build your app. Important aspects
-include the Home screen experience, global device navigation, and notifications.
          
-
          Your app will play an important part in keeping the overall Android experience consistent and
-enjoyable to use. At the end of this chapter we introduce the main elements for achieving this goal
-in your app.
          
-
          Read on for a quick overview of the most important aspects of the Android user interface.
          
-
-
          Home, All Apps, and Recents
          
-
-
           
          
-
-
          
-  
          
-
-    
-
-
          Home screen
          
-
          Home is a customizable space that houses app shortcuts, folders and widgets. Navigate between
-different home screen panels by swiping left and right.
          
-
          The Favorites Tray at the bottom always keeps your most important shortcuts and folders in view
-regardless of which panel is currently showing.
          
-
          Access the entire collection of apps and widgets by touching the All Apps button at the center of
-the Favorites Tray.
          
-
-  
          
-  
          
-
-    
-
-
          All apps screen
          
-
          The All Apps screen lets you browse the entire set of apps and widgets that are installed on your
-device.
          
-
          Users can drag an app or widget icon from the All Apps screen and place it in any empty location on
-any Home screen.
          
-
-  
          
-  
          
-
-    
-
-
          Recents screen
          
-
          Recents provides an efficient way of switching between recently used applications. It provides a
-clear navigation path between multiple ongoing tasks.
          
-
          The Recents button at the right side of the navigation bar displays the apps that the user has
-interacted with most recently. They are organized in reverse chronological order with the most
-recently used app at the bottom.
          
-
          Switch to an app by touching it. Remove an item by swiping left or right.
          
-
-  
          
-
          
-
-
          System Bars
          
-
-
          The system bars are screen areas dedicated to the display of notifications, communication of device
-status, and device navigation. Typically the system bars are displayed concurrently with your app.
-Apps that display immersive content, such as movies or images, can temporarily hide the system bars
-to allow the user to enjoy full screen content without distraction.
          
-
-
-
-
          
-
-
            
-
          1. 
-
            Status Bar
            
-
            Displays pending notifications on the left and status, such as time, battery level, or signal
-  strength, on the right. Swipe down from the status bar to show notification details.
            
-
            2. 
-
          2. 
-
            Navigation Bar
            
-
            New for phones in Android 4.0, the navigation bar is present only on devices that don't have
-  the traditional hardware keys. It houses the device navigation controls Back, Home, and
-  Recents, and also displays a menu for apps written for Android 2.3 or earlier.
            
-
            3. 
-
          3. 
-
            Combined Bar
            
-
            On tablet form factors the status and navigation bars are combined into a single bar at the
-  bottom of the screen.
            
-
            4. 
-
          
-
-
          
-
-
          Notifications
          
-
-
          Notifications are brief messages that users can access at any time from the status bar. They
-provide updates, reminders, or information that's important, but not critical enough to warrant
-interrupting the user. Open the notifications drawer by swiping down on the status bar. Touching a
-notification opens the associated app. More on Notifications
          
-
-
          
-  
          
-
-    
-
-  
          
-  
          
-
-    
-
-
          Most notifications have a one-line title and a one-line message. The recommended layout for a
-notification includes two lines. If necessary, you can add a third line. Timestamps are optional.
          
-
          Swiping a notification right or left removes it from the notification drawer.
          
-
-  
          
-
          
-
-
-
          Common App UI
          
-
-
-
          
-  
          
-
-    
-
-  
          
-  
          
-
-
          A typical Android app consists of action bars and the app content area.
          
-
            
-
          1. 
-
            Main Action Bar
            
-
            The command and control center for your app. The main action bar includes elements for
-  navigating your app's hierarchy and views, and also surfaces the most important actions.
            
-
            More on the Action Bar
            
-
            2. 
-
          2. 
-
            View Control
            
-
            Allows users to switch between the different views that your app provides. Views typically
-  consist of different arrangements of your data or different functional aspects of your app.
            
-
            3. 
-
          3. 
-
            Content Area
            
-
            The space where the content of your app is displayed.
            
-
            4. 
-
          4. 
-
            Split Action Bar
            
-
            Split action bars provide a way to distribute actions across additional bars located below
-  the main action bar or at the bottom of the screen. In this example, a split action bar moves
-  important actions that won't fit in the main bar to the bottom.
            
-
            5. 
-
          
-
-  
          
-
          
-
-
-
-          
-          
          
-            
           
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-        
          
-
-      
          
-
-      
          
-
-        
-
-        
          
-          Site Terms of Service –
-          Privacy Policy –
-          Brand Guidelines
-        
          
-
-      
          
-    
          
-
-    
-    
-    
-
-
-    
-    
-  
-
diff --git a/docs/html/design/get-started/ui-overview.jd b/docs/html/design/get-started/ui-overview.jd
new file mode 100644
index 0000000000000..34cdd067e94df
--- /dev/null
+++ b/docs/html/design/get-started/ui-overview.jd
@@ -0,0 +1,149 @@
+page.title=UI Overview
+@jd:body
+
+
          Android's system UI provides the framework on top of which you build your app. Important aspects
+include the Home screen experience, global device navigation, and notifications.
          
+
          Your app will play an important part in keeping the overall Android experience consistent and
+enjoyable to use. At the end of this chapter we introduce the main elements for achieving this goal
+in your app.
          
+
          Read on for a quick overview of the most important aspects of the Android user interface.
          
+
+
          Home, All Apps, and Recents
          
+
+
           
          
+
+
          
+  
          
+
+    
+
+
          Home screen
          
+
          Home is a customizable space that houses app shortcuts, folders and widgets. Navigate between
+different home screen panels by swiping left and right.
          
+
          The Favorites Tray at the bottom always keeps your most important shortcuts and folders in view
+regardless of which panel is currently showing.
          
+
          Access the entire collection of apps and widgets by touching the All Apps button at the center of
+the Favorites Tray.
          
+
+  
          
+  
          
+
+    
+
+
          All apps screen
          
+
          The All Apps screen lets you browse the entire set of apps and widgets that are installed on your
+device.
          
+
          Users can drag an app or widget icon from the All Apps screen and place it in any empty location on
+any Home screen.
          
+
+  
          
+  
          
+
+    
+
+
          Recents screen
          
+
          Recents provides an efficient way of switching between recently used applications. It provides a
+clear navigation path between multiple ongoing tasks.
          
+
          The Recents button at the right side of the navigation bar displays the apps that the user has
+interacted with most recently. They are organized in reverse chronological order with the most
+recently used app at the bottom.
          
+
          Switch to an app by touching it. Remove an item by swiping left or right.
          
+
+  
          
+
          
+
+
          System Bars
          
+
+
          The system bars are screen areas dedicated to the display of notifications, communication of device
+status, and device navigation. Typically the system bars are displayed concurrently with your app.
+Apps that display immersive content, such as movies or images, can temporarily hide the system bars
+to allow the user to enjoy full screen content without distraction.
          
+
+
+
+
          
+
+
            
+
          1. 
+
            Status Bar
            
+
            Displays pending notifications on the left and status, such as time, battery level, or signal
+  strength, on the right. Swipe down from the status bar to show notification details.
            
+
            2. 
+
          2. 
+
            Navigation Bar
            
+
            New for phones in Android 4.0, the navigation bar is present only on devices that don't have
+  the traditional hardware keys. It houses the device navigation controls Back, Home, and
+  Recents, and also displays a menu for apps written for Android 2.3 or earlier.
            
+
            3. 
+
          3. 
+
            Combined Bar
            
+
            On tablet form factors the status and navigation bars are combined into a single bar at the
+  bottom of the screen.
            
+
            4. 
+
          
+
+
          
+
+
          Notifications
          
+
+
          Notifications are brief messages that users can access at any time from the status bar. They
+provide updates, reminders, or information that's important, but not critical enough to warrant
+interrupting the user. Open the notifications drawer by swiping down on the status bar. Touching a
+notification opens the associated app. More on Notifications
          
+
+
          
+  
          
+
+    
+
+  
          
+  
          
+
+    
+
+
          Most notifications have a one-line title and a one-line message. The recommended layout for a
+notification includes two lines. If necessary, you can add a third line. Timestamps are optional.
          
+
          Swiping a notification right or left removes it from the notification drawer.
          
+
+  
          
+
          
+
+
+
          Common App UI
          
+
+
+
          
+  
          
+
+    
+
+  
          
+  
          
+
+
          A typical Android app consists of action bars and the app content area.
          
+
            
+
          1. 
+
            Main Action Bar
            
+
            The command and control center for your app. The main action bar includes elements for
+  navigating your app's hierarchy and views, and also surfaces the most important actions.
            
+
            More on the Action Bar
            
+
            2. 
+
          2. 
+
            View Control
            
+
            Allows users to switch between the different views that your app provides. Views typically
+  consist of different arrangements of your data or different functional aspects of your app.
            
+
            3. 
+
          3. 
+
            Content Area
            
+
            The space where the content of your app is displayed.
            
+
            4. 
+
          4. 
+
            Split Action Bar
            
+
            Split action bars provide a way to distribute actions across additional bars located below
+  the main action bar or at the bottom of the screen. In this example, a split action bar moves
+  important actions that won't fit in the main bar to the bottom.
            
+
            5. 
+
          
+
+  
          
+
          
diff --git a/docs/html/design/index.html b/docs/html/design/index.html
deleted file mode 100644
index 8583aa4540cee..0000000000000
--- a/docs/html/design/index.html
+++ /dev/null
@@ -1,168 +0,0 @@
-
-
-  
-    
-    
-
-Android Design - Welcome
-    
-    
-    
-    
-    
-
-
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-
-
-          
-
-
          
-  
          
-    Welcome to Android Design, your place for learning how to design exceptional Android apps.
-    

          
-    Creative Vision
-  
          
-
-  
-    
-  
-
          
-
-
-
-          
-
-        
          
-
-      
          
-
-      
          
-
-        
-
-        
          
-          Site Terms of Service –
-          Privacy Policy –
-          Brand Guidelines
-        
          
-
-      
          
-    
          
-
-    
-    
-    
-
-
-    
-    
-  
-
diff --git a/docs/html/design/index.jd b/docs/html/design/index.jd
new file mode 100644
index 0000000000000..d404aa6e42e2f
--- /dev/null
+++ b/docs/html/design/index.jd
@@ -0,0 +1,29 @@
+page.title=
+header.hide=1
+footer.hide=1
+@jd:body
+
+
+
+
          
+  
          
+    Welcome to Android Design, your place for learning how to design exceptional Android apps.
+    

          
+    Creative Vision
+  
          
+
+  
+    
+  
+
          
diff --git a/docs/html/design/static/content/action_bar_basics.png b/docs/html/design/media/action_bar_basics.png
similarity index 100%
rename from docs/html/design/static/content/action_bar_basics.png
rename to docs/html/design/media/action_bar_basics.png
diff --git a/docs/html/design/static/content/action_bar_cab.png b/docs/html/design/media/action_bar_cab.png
similarity index 100%
rename from docs/html/design/static/content/action_bar_cab.png
rename to docs/html/design/media/action_bar_cab.png
diff --git a/docs/html/design/static/content/action_bar_pattern_action_icons.png b/docs/html/design/media/action_bar_pattern_action_icons.png
similarity index 100%
rename from docs/html/design/static/content/action_bar_pattern_action_icons.png
rename to docs/html/design/media/action_bar_pattern_action_icons.png
diff --git a/docs/html/design/static/content/action_bar_pattern_considerations.png b/docs/html/design/media/action_bar_pattern_considerations.png
similarity index 100%
rename from docs/html/design/static/content/action_bar_pattern_considerations.png
rename to docs/html/design/media/action_bar_pattern_considerations.png
diff --git a/docs/html/design/static/content/action_bar_pattern_default_tabs.png b/docs/html/design/media/action_bar_pattern_default_tabs.png
similarity index 100%
rename from docs/html/design/static/content/action_bar_pattern_default_tabs.png
rename to docs/html/design/media/action_bar_pattern_default_tabs.png
diff --git a/docs/html/design/static/content/action_bar_pattern_overflow.png b/docs/html/design/media/action_bar_pattern_overflow.png
similarity index 100%
rename from docs/html/design/static/content/action_bar_pattern_overflow.png
rename to docs/html/design/media/action_bar_pattern_overflow.png
diff --git a/docs/html/design/static/content/action_bar_pattern_overview.png b/docs/html/design/media/action_bar_pattern_overview.png
similarity index 100%
rename from docs/html/design/static/content/action_bar_pattern_overview.png
rename to docs/html/design/media/action_bar_pattern_overview.png
diff --git a/docs/html/design/static/content/action_bar_pattern_rotation.png b/docs/html/design/media/action_bar_pattern_rotation.png
similarity index 100%
rename from docs/html/design/static/content/action_bar_pattern_rotation.png
rename to docs/html/design/media/action_bar_pattern_rotation.png
diff --git a/docs/html/design/static/content/action_bar_pattern_share_pack.png b/docs/html/design/media/action_bar_pattern_share_pack.png
similarity index 100%
rename from docs/html/design/static/content/action_bar_pattern_share_pack.png
rename to docs/html/design/media/action_bar_pattern_share_pack.png
diff --git a/docs/html/design/static/content/action_bar_pattern_spinner.png b/docs/html/design/media/action_bar_pattern_spinner.png
similarity index 100%
rename from docs/html/design/static/content/action_bar_pattern_spinner.png
rename to docs/html/design/media/action_bar_pattern_spinner.png
diff --git a/docs/html/design/static/content/action_bar_pattern_table.png b/docs/html/design/media/action_bar_pattern_table.png
similarity index 100%
rename from docs/html/design/static/content/action_bar_pattern_table.png
rename to docs/html/design/media/action_bar_pattern_table.png
diff --git a/docs/html/design/static/content/action_bar_pattern_up_app_icon.png b/docs/html/design/media/action_bar_pattern_up_app_icon.png
similarity index 100%
rename from docs/html/design/static/content/action_bar_pattern_up_app_icon.png
rename to docs/html/design/media/action_bar_pattern_up_app_icon.png
diff --git a/docs/html/design/static/content/app_structure_book_detail_page_flip.png b/docs/html/design/media/app_structure_book_detail_page_flip.png
similarity index 100%
rename from docs/html/design/static/content/app_structure_book_detail_page_flip.png
rename to docs/html/design/media/app_structure_book_detail_page_flip.png
diff --git a/docs/html/design/static/content/app_structure_fixedtabs.png b/docs/html/design/media/app_structure_fixedtabs.png
similarity index 100%
rename from docs/html/design/static/content/app_structure_fixedtabs.png
rename to docs/html/design/media/app_structure_fixedtabs.png
diff --git a/docs/html/design/static/content/app_structure_gallery_filmstrip.png b/docs/html/design/media/app_structure_gallery_filmstrip.png
similarity index 100%
rename from docs/html/design/static/content/app_structure_gallery_filmstrip.png
rename to docs/html/design/media/app_structure_gallery_filmstrip.png
diff --git a/docs/html/design/static/content/app_structure_gmail.png b/docs/html/design/media/app_structure_gmail.png
similarity index 100%
rename from docs/html/design/static/content/app_structure_gmail.png
rename to docs/html/design/media/app_structure_gmail.png
diff --git a/docs/html/design/static/content/app_structure_gmail_swipe.png b/docs/html/design/media/app_structure_gmail_swipe.png
similarity index 100%
rename from docs/html/design/static/content/app_structure_gmail_swipe.png
rename to docs/html/design/media/app_structure_gmail_swipe.png
diff --git a/docs/html/design/static/content/app_structure_market.png b/docs/html/design/media/app_structure_market.png
similarity index 100%
rename from docs/html/design/static/content/app_structure_market.png
rename to docs/html/design/media/app_structure_market.png
diff --git a/docs/html/design/static/content/app_structure_music_lndscp.png b/docs/html/design/media/app_structure_music_lndscp.png
similarity index 100%
rename from docs/html/design/static/content/app_structure_music_lndscp.png
rename to docs/html/design/media/app_structure_music_lndscp.png
diff --git a/docs/html/design/static/content/app_structure_overview.png b/docs/html/design/media/app_structure_overview.png
similarity index 100%
rename from docs/html/design/static/content/app_structure_overview.png
rename to docs/html/design/media/app_structure_overview.png
diff --git a/docs/html/design/static/content/app_structure_people_detail.png b/docs/html/design/media/app_structure_people_detail.png
similarity index 100%
rename from docs/html/design/static/content/app_structure_people_detail.png
rename to docs/html/design/media/app_structure_people_detail.png
diff --git a/docs/html/design/static/content/app_structure_scrolltabs.png b/docs/html/design/media/app_structure_scrolltabs.png
similarity index 100%
rename from docs/html/design/static/content/app_structure_scrolltabs.png
rename to docs/html/design/media/app_structure_scrolltabs.png
diff --git a/docs/html/design/static/content/app_structure_shortcut_on_item.png b/docs/html/design/media/app_structure_shortcut_on_item.png
similarity index 100%
rename from docs/html/design/static/content/app_structure_shortcut_on_item.png
rename to docs/html/design/media/app_structure_shortcut_on_item.png
diff --git a/docs/html/design/static/content/building_blocks_landing.png b/docs/html/design/media/building_blocks_landing.png
similarity index 100%
rename from docs/html/design/static/content/building_blocks_landing.png
rename to docs/html/design/media/building_blocks_landing.png
diff --git a/docs/html/design/static/content/buttons_basic.png b/docs/html/design/media/buttons_basic.png
similarity index 100%
rename from docs/html/design/static/content/buttons_basic.png
rename to docs/html/design/media/buttons_basic.png
diff --git a/docs/html/design/static/content/buttons_borderless.png b/docs/html/design/media/buttons_borderless.png
similarity index 100%
rename from docs/html/design/static/content/buttons_borderless.png
rename to docs/html/design/media/buttons_borderless.png
diff --git a/docs/html/design/static/content/buttons_default_small.png b/docs/html/design/media/buttons_default_small.png
similarity index 100%
rename from docs/html/design/static/content/buttons_default_small.png
rename to docs/html/design/media/buttons_default_small.png
diff --git a/docs/html/design/static/content/color_spectrum.png b/docs/html/design/media/color_spectrum.png
similarity index 100%
rename from docs/html/design/static/content/color_spectrum.png
rename to docs/html/design/media/color_spectrum.png
diff --git a/docs/html/design/static/content/compatibility_legacy_apps.png b/docs/html/design/media/compatibility_legacy_apps.png
similarity index 100%
rename from docs/html/design/static/content/compatibility_legacy_apps.png
rename to docs/html/design/media/compatibility_legacy_apps.png
diff --git a/docs/html/design/static/content/compatibility_physical_buttons.png b/docs/html/design/media/compatibility_physical_buttons.png
similarity index 100%
rename from docs/html/design/static/content/compatibility_physical_buttons.png
rename to docs/html/design/media/compatibility_physical_buttons.png
diff --git a/docs/html/design/static/content/compatibility_virtual_nav.png b/docs/html/design/media/compatibility_virtual_nav.png
similarity index 100%
rename from docs/html/design/static/content/compatibility_virtual_nav.png
rename to docs/html/design/media/compatibility_virtual_nav.png
diff --git a/docs/html/design/static/content/creative_vision_main.png b/docs/html/design/media/creative_vision_main.png
similarity index 100%
rename from docs/html/design/static/content/creative_vision_main.png
rename to docs/html/design/media/creative_vision_main.png
diff --git a/docs/html/design/static/content/design_elements_landing.png b/docs/html/design/media/design_elements_landing.png
similarity index 100%
rename from docs/html/design/static/content/design_elements_landing.png
rename to docs/html/design/media/design_elements_landing.png
diff --git a/docs/html/design/static/content/devices_displays_density.png b/docs/html/design/media/devices_displays_density.png
similarity index 100%
rename from docs/html/design/static/content/devices_displays_density.png
rename to docs/html/design/media/devices_displays_density.png
diff --git a/docs/html/design/static/content/devices_displays_main.png b/docs/html/design/media/devices_displays_main.png
similarity index 100%
rename from docs/html/design/static/content/devices_displays_main.png
rename to docs/html/design/media/devices_displays_main.png
diff --git a/docs/html/design/static/content/dialogs_examples.png b/docs/html/design/media/dialogs_examples.png
similarity index 100%
rename from docs/html/design/static/content/dialogs_examples.png
rename to docs/html/design/media/dialogs_examples.png
diff --git a/docs/html/design/static/content/dialogs_main.png b/docs/html/design/media/dialogs_main.png
similarity index 100%
rename from docs/html/design/static/content/dialogs_main.png
rename to docs/html/design/media/dialogs_main.png
diff --git a/docs/html/design/static/content/dialogs_popups_example.png b/docs/html/design/media/dialogs_popups_example.png
similarity index 100%
rename from docs/html/design/static/content/dialogs_popups_example.png
rename to docs/html/design/media/dialogs_popups_example.png
diff --git a/docs/html/design/static/content/dialogs_toasts.png b/docs/html/design/media/dialogs_toasts.png
similarity index 100%
rename from docs/html/design/static/content/dialogs_toasts.png
rename to docs/html/design/media/dialogs_toasts.png
diff --git a/docs/html/design/static/content/dialogs_w_no_title.png b/docs/html/design/media/dialogs_w_no_title.png
similarity index 100%
rename from docs/html/design/static/content/dialogs_w_no_title.png
rename to docs/html/design/media/dialogs_w_no_title.png
diff --git a/docs/html/design/static/content/dialogs_w_title.png b/docs/html/design/media/dialogs_w_title.png
similarity index 100%
rename from docs/html/design/static/content/dialogs_w_title.png
rename to docs/html/design/media/dialogs_w_title.png
diff --git a/docs/html/design/static/content/downloads_color_swatches.png b/docs/html/design/media/downloads_color_swatches.png
similarity index 100%
rename from docs/html/design/static/content/downloads_color_swatches.png
rename to docs/html/design/media/downloads_color_swatches.png
diff --git a/docs/html/design/static/content/downloads_roboto_specimen_preview.png b/docs/html/design/media/downloads_roboto_specimen_preview.png
similarity index 100%
rename from docs/html/design/static/content/downloads_roboto_specimen_preview.png
rename to docs/html/design/media/downloads_roboto_specimen_preview.png
diff --git a/docs/html/design/static/content/downloads_stencils.png b/docs/html/design/media/downloads_stencils.png
similarity index 100%
rename from docs/html/design/static/content/downloads_stencils.png
rename to docs/html/design/media/downloads_stencils.png
diff --git a/docs/html/design/static/content/gesture_doubletouch.png b/docs/html/design/media/gesture_doubletouch.png
similarity index 100%
rename from docs/html/design/static/content/gesture_doubletouch.png
rename to docs/html/design/media/gesture_doubletouch.png
diff --git a/docs/html/design/static/content/gesture_drag.png b/docs/html/design/media/gesture_drag.png
similarity index 100%
rename from docs/html/design/static/content/gesture_drag.png
rename to docs/html/design/media/gesture_drag.png
diff --git a/docs/html/design/static/content/gesture_longtouch.png b/docs/html/design/media/gesture_longtouch.png
similarity index 100%
rename from docs/html/design/static/content/gesture_longtouch.png
rename to docs/html/design/media/gesture_longtouch.png
diff --git a/docs/html/design/static/content/gesture_pinchclose.png b/docs/html/design/media/gesture_pinchclose.png
similarity index 100%
rename from docs/html/design/static/content/gesture_pinchclose.png
rename to docs/html/design/media/gesture_pinchclose.png
diff --git a/docs/html/design/static/content/gesture_pinchopen.png b/docs/html/design/media/gesture_pinchopen.png
similarity index 100%
rename from docs/html/design/static/content/gesture_pinchopen.png
rename to docs/html/design/media/gesture_pinchopen.png
diff --git a/docs/html/design/static/content/gesture_swipe.png b/docs/html/design/media/gesture_swipe.png
similarity index 100%
rename from docs/html/design/static/content/gesture_swipe.png
rename to docs/html/design/media/gesture_swipe.png
diff --git a/docs/html/design/static/content/gesture_touch.png b/docs/html/design/media/gesture_touch.png
similarity index 100%
rename from docs/html/design/static/content/gesture_touch.png
rename to docs/html/design/media/gesture_touch.png
diff --git a/docs/html/design/static/content/gridview_example.png b/docs/html/design/media/gridview_example.png
similarity index 100%
rename from docs/html/design/static/content/gridview_example.png
rename to docs/html/design/media/gridview_example.png
diff --git a/docs/html/design/static/content/gridview_horizontal.png b/docs/html/design/media/gridview_horizontal.png
similarity index 100%
rename from docs/html/design/static/content/gridview_horizontal.png
rename to docs/html/design/media/gridview_horizontal.png
diff --git a/docs/html/design/static/content/gridview_overview.png b/docs/html/design/media/gridview_overview.png
similarity index 100%
rename from docs/html/design/static/content/gridview_overview.png
rename to docs/html/design/media/gridview_overview.png
diff --git a/docs/html/design/static/content/gridview_style.png b/docs/html/design/media/gridview_style.png
similarity index 100%
rename from docs/html/design/static/content/gridview_style.png
rename to docs/html/design/media/gridview_style.png
diff --git a/docs/html/design/static/content/gridview_vertical.png b/docs/html/design/media/gridview_vertical.png
similarity index 100%
rename from docs/html/design/static/content/gridview_vertical.png
rename to docs/html/design/media/gridview_vertical.png
diff --git a/docs/html/design/static/content/iconography_actionbar_colors.png b/docs/html/design/media/iconography_actionbar_colors.png
similarity index 100%
rename from docs/html/design/static/content/iconography_actionbar_colors.png
rename to docs/html/design/media/iconography_actionbar_colors.png
diff --git a/docs/html/design/static/content/iconography_actionbar_focal.png b/docs/html/design/media/iconography_actionbar_focal.png
similarity index 100%
rename from docs/html/design/static/content/iconography_actionbar_focal.png
rename to docs/html/design/media/iconography_actionbar_focal.png
diff --git a/docs/html/design/static/content/iconography_actionbar_size.png b/docs/html/design/media/iconography_actionbar_size.png
similarity index 100%
rename from docs/html/design/static/content/iconography_actionbar_size.png
rename to docs/html/design/media/iconography_actionbar_size.png
diff --git a/docs/html/design/static/content/iconography_actionbar_style.png b/docs/html/design/media/iconography_actionbar_style.png
similarity index 100%
rename from docs/html/design/static/content/iconography_actionbar_style.png
rename to docs/html/design/media/iconography_actionbar_style.png
diff --git a/docs/html/design/static/content/iconography_launcher_example.png b/docs/html/design/media/iconography_launcher_example.png
similarity index 100%
rename from docs/html/design/static/content/iconography_launcher_example.png
rename to docs/html/design/media/iconography_launcher_example.png
diff --git a/docs/html/design/static/content/iconography_launcher_example2.png b/docs/html/design/media/iconography_launcher_example2.png
similarity index 100%
rename from docs/html/design/static/content/iconography_launcher_example2.png
rename to docs/html/design/media/iconography_launcher_example2.png
diff --git a/docs/html/design/static/content/iconography_launcher_focal.png b/docs/html/design/media/iconography_launcher_focal.png
similarity index 100%
rename from docs/html/design/static/content/iconography_launcher_focal.png
rename to docs/html/design/media/iconography_launcher_focal.png
diff --git a/docs/html/design/static/content/iconography_launcher_size.png b/docs/html/design/media/iconography_launcher_size.png
similarity index 100%
rename from docs/html/design/static/content/iconography_launcher_size.png
rename to docs/html/design/media/iconography_launcher_size.png
diff --git a/docs/html/design/static/content/iconography_launcher_style.png b/docs/html/design/media/iconography_launcher_style.png
similarity index 100%
rename from docs/html/design/static/content/iconography_launcher_style.png
rename to docs/html/design/media/iconography_launcher_style.png
diff --git a/docs/html/design/static/content/iconography_notification_example.png b/docs/html/design/media/iconography_notification_example.png
similarity index 100%
rename from docs/html/design/static/content/iconography_notification_example.png
rename to docs/html/design/media/iconography_notification_example.png
diff --git a/docs/html/design/static/content/iconography_notification_focal.png b/docs/html/design/media/iconography_notification_focal.png
similarity index 100%
rename from docs/html/design/static/content/iconography_notification_focal.png
rename to docs/html/design/media/iconography_notification_focal.png
diff --git a/docs/html/design/static/content/iconography_notification_size.png b/docs/html/design/media/iconography_notification_size.png
similarity index 100%
rename from docs/html/design/static/content/iconography_notification_size.png
rename to docs/html/design/media/iconography_notification_size.png
diff --git a/docs/html/design/static/content/iconography_notification_style.png b/docs/html/design/media/iconography_notification_style.png
similarity index 100%
rename from docs/html/design/static/content/iconography_notification_style.png
rename to docs/html/design/media/iconography_notification_style.png
diff --git a/docs/html/design/static/content/iconography_overview.png b/docs/html/design/media/iconography_overview.png
similarity index 100%
rename from docs/html/design/static/content/iconography_overview.png
rename to docs/html/design/media/iconography_overview.png
diff --git a/docs/html/design/static/content/iconography_small_colors.png b/docs/html/design/media/iconography_small_colors.png
similarity index 100%
rename from docs/html/design/static/content/iconography_small_colors.png
rename to docs/html/design/media/iconography_small_colors.png
diff --git a/docs/html/design/static/content/iconography_small_example.png b/docs/html/design/media/iconography_small_example.png
similarity index 100%
rename from docs/html/design/static/content/iconography_small_example.png
rename to docs/html/design/media/iconography_small_example.png
diff --git a/docs/html/design/static/content/iconography_small_focal.png b/docs/html/design/media/iconography_small_focal.png
similarity index 100%
rename from docs/html/design/static/content/iconography_small_focal.png
rename to docs/html/design/media/iconography_small_focal.png
diff --git a/docs/html/design/static/content/iconography_small_size.png b/docs/html/design/media/iconography_small_size.png
similarity index 100%
rename from docs/html/design/static/content/iconography_small_size.png
rename to docs/html/design/media/iconography_small_size.png
diff --git a/docs/html/design/static/content/iconography_small_style.png b/docs/html/design/media/iconography_small_style.png
similarity index 100%
rename from docs/html/design/static/content/iconography_small_style.png
rename to docs/html/design/media/iconography_small_style.png
diff --git a/docs/html/design/static/content/index_landing_page.png b/docs/html/design/media/index_landing_page.png
similarity index 100%
rename from docs/html/design/static/content/index_landing_page.png
rename to docs/html/design/media/index_landing_page.png
diff --git a/docs/html/design/static/content/lists_main.png b/docs/html/design/media/lists_main.png
similarity index 100%
rename from docs/html/design/static/content/lists_main.png
rename to docs/html/design/media/lists_main.png
diff --git a/docs/html/design/static/content/metrics_48.png b/docs/html/design/media/metrics_48.png
similarity index 100%
rename from docs/html/design/static/content/metrics_48.png
rename to docs/html/design/media/metrics_48.png
diff --git a/docs/html/design/static/content/metrics_closeup.png b/docs/html/design/media/metrics_closeup.png
similarity index 100%
rename from docs/html/design/static/content/metrics_closeup.png
rename to docs/html/design/media/metrics_closeup.png
diff --git a/docs/html/design/static/content/metrics_diagram.png b/docs/html/design/media/metrics_diagram.png
similarity index 100%
rename from docs/html/design/static/content/metrics_diagram.png
rename to docs/html/design/media/metrics_diagram.png
diff --git a/docs/html/design/static/content/metrics_forms.png b/docs/html/design/media/metrics_forms.png
similarity index 100%
rename from docs/html/design/static/content/metrics_forms.png
rename to docs/html/design/media/metrics_forms.png
diff --git a/docs/html/design/static/content/migrating_icons.png b/docs/html/design/media/migrating_icons.png
similarity index 100%
rename from docs/html/design/static/content/migrating_icons.png
rename to docs/html/design/media/migrating_icons.png
diff --git a/docs/html/design/static/content/migrating_ios_dialers.png b/docs/html/design/media/migrating_ios_dialers.png
similarity index 100%
rename from docs/html/design/static/content/migrating_ios_dialers.png
rename to docs/html/design/media/migrating_ios_dialers.png
diff --git a/docs/html/design/static/content/migrating_ios_galleries.png b/docs/html/design/media/migrating_ios_galleries.png
similarity index 100%
rename from docs/html/design/static/content/migrating_ios_galleries.png
rename to docs/html/design/media/migrating_ios_galleries.png
diff --git a/docs/html/design/static/content/migrating_ios_settings.png b/docs/html/design/media/migrating_ios_settings.png
similarity index 100%
rename from docs/html/design/static/content/migrating_ios_settings.png
rename to docs/html/design/media/migrating_ios_settings.png
diff --git a/docs/html/design/static/content/migrating_ui_elements.png b/docs/html/design/media/migrating_ui_elements.png
similarity index 100%
rename from docs/html/design/static/content/migrating_ui_elements.png
rename to docs/html/design/media/migrating_ui_elements.png
diff --git a/docs/html/design/static/content/misc_full_galaxynexus_blank_land_span13.png b/docs/html/design/media/misc_full_galaxynexus_blank_land_span13.png
similarity index 100%
rename from docs/html/design/static/content/misc_full_galaxynexus_blank_land_span13.png
rename to docs/html/design/media/misc_full_galaxynexus_blank_land_span13.png
diff --git a/docs/html/design/static/content/misc_full_galaxynexus_blank_port_span5.png b/docs/html/design/media/misc_full_galaxynexus_blank_port_span5.png
similarity index 100%
rename from docs/html/design/static/content/misc_full_galaxynexus_blank_port_span5.png
rename to docs/html/design/media/misc_full_galaxynexus_blank_port_span5.png
diff --git a/docs/html/design/static/content/misc_full_galaxynexus_blank_port_span9.png b/docs/html/design/media/misc_full_galaxynexus_blank_port_span9.png
similarity index 100%
rename from docs/html/design/static/content/misc_full_galaxynexus_blank_port_span9.png
rename to docs/html/design/media/misc_full_galaxynexus_blank_port_span9.png
diff --git a/docs/html/design/static/content/multipane_expand.png b/docs/html/design/media/multipane_expand.png
similarity index 100%
rename from docs/html/design/static/content/multipane_expand.png
rename to docs/html/design/media/multipane_expand.png
diff --git a/docs/html/design/static/content/multipane_show.png b/docs/html/design/media/multipane_show.png
similarity index 100%
rename from docs/html/design/static/content/multipane_show.png
rename to docs/html/design/media/multipane_show.png
diff --git a/docs/html/design/static/content/multipane_stack.png b/docs/html/design/media/multipane_stack.png
similarity index 100%
rename from docs/html/design/static/content/multipane_stack.png
rename to docs/html/design/media/multipane_stack.png
diff --git a/docs/html/design/static/content/multipane_stretch.png b/docs/html/design/media/multipane_stretch.png
similarity index 100%
rename from docs/html/design/static/content/multipane_stretch.png
rename to docs/html/design/media/multipane_stretch.png
diff --git a/docs/html/design/static/content/multipane_view_tablet.png b/docs/html/design/media/multipane_view_tablet.png
similarity index 100%
rename from docs/html/design/static/content/multipane_view_tablet.png
rename to docs/html/design/media/multipane_view_tablet.png
diff --git a/docs/html/design/static/content/multipane_views.png b/docs/html/design/media/multipane_views.png
similarity index 100%
rename from docs/html/design/static/content/multipane_views.png
rename to docs/html/design/media/multipane_views.png
diff --git a/docs/html/design/static/content/navigation_between_siblings_gmail.png b/docs/html/design/media/navigation_between_siblings_gmail.png
similarity index 100%
rename from docs/html/design/static/content/navigation_between_siblings_gmail.png
rename to docs/html/design/media/navigation_between_siblings_gmail.png
diff --git a/docs/html/design/static/content/navigation_between_siblings_market1.png b/docs/html/design/media/navigation_between_siblings_market1.png
similarity index 100%
rename from docs/html/design/static/content/navigation_between_siblings_market1.png
rename to docs/html/design/media/navigation_between_siblings_market1.png
diff --git a/docs/html/design/static/content/navigation_between_siblings_market2.png b/docs/html/design/media/navigation_between_siblings_market2.png
similarity index 100%
rename from docs/html/design/static/content/navigation_between_siblings_market2.png
rename to docs/html/design/media/navigation_between_siblings_market2.png
diff --git a/docs/html/design/static/content/navigation_from_outside_back.png b/docs/html/design/media/navigation_from_outside_back.png
similarity index 100%
rename from docs/html/design/static/content/navigation_from_outside_back.png
rename to docs/html/design/media/navigation_from_outside_back.png
diff --git a/docs/html/design/static/content/navigation_from_outside_up.png b/docs/html/design/media/navigation_from_outside_up.png
similarity index 100%
rename from docs/html/design/static/content/navigation_from_outside_up.png
rename to docs/html/design/media/navigation_from_outside_up.png
diff --git a/docs/html/design/static/content/navigation_up_vs_back_gmail.png b/docs/html/design/media/navigation_up_vs_back_gmail.png
similarity index 100%
rename from docs/html/design/static/content/navigation_up_vs_back_gmail.png
rename to docs/html/design/media/navigation_up_vs_back_gmail.png
diff --git a/docs/html/design/static/content/navigation_with_back_and_up.png b/docs/html/design/media/navigation_with_back_and_up.png
similarity index 100%
rename from docs/html/design/static/content/navigation_with_back_and_up.png
rename to docs/html/design/media/navigation_with_back_and_up.png
diff --git a/docs/html/design/static/content/notifications_dismiss.png b/docs/html/design/media/notifications_dismiss.png
similarity index 100%
rename from docs/html/design/static/content/notifications_dismiss.png
rename to docs/html/design/media/notifications_dismiss.png
diff --git a/docs/html/design/static/content/notifications_pattern_additional_fail.png b/docs/html/design/media/notifications_pattern_additional_fail.png
similarity index 100%
rename from docs/html/design/static/content/notifications_pattern_additional_fail.png
rename to docs/html/design/media/notifications_pattern_additional_fail.png
diff --git a/docs/html/design/static/content/notifications_pattern_additional_win.png b/docs/html/design/media/notifications_pattern_additional_win.png
similarity index 100%
rename from docs/html/design/static/content/notifications_pattern_additional_win.png
rename to docs/html/design/media/notifications_pattern_additional_win.png
diff --git a/docs/html/design/static/content/notifications_pattern_anatomy.png b/docs/html/design/media/notifications_pattern_anatomy.png
similarity index 100%
rename from docs/html/design/static/content/notifications_pattern_anatomy.png
rename to docs/html/design/media/notifications_pattern_anatomy.png
diff --git a/docs/html/design/static/content/notifications_pattern_dialog_toast.png b/docs/html/design/media/notifications_pattern_dialog_toast.png
similarity index 100%
rename from docs/html/design/static/content/notifications_pattern_dialog_toast.png
rename to docs/html/design/media/notifications_pattern_dialog_toast.png
diff --git a/docs/html/design/static/content/notifications_pattern_ongoing_music.png b/docs/html/design/media/notifications_pattern_ongoing_music.png
similarity index 100%
rename from docs/html/design/static/content/notifications_pattern_ongoing_music.png
rename to docs/html/design/media/notifications_pattern_ongoing_music.png
diff --git a/docs/html/design/static/content/notifications_pattern_phone_icons.png b/docs/html/design/media/notifications_pattern_phone_icons.png
similarity index 100%
rename from docs/html/design/static/content/notifications_pattern_phone_icons.png
rename to docs/html/design/media/notifications_pattern_phone_icons.png
diff --git a/docs/html/design/static/content/notifications_pattern_phone_ticker.png b/docs/html/design/media/notifications_pattern_phone_ticker.png
similarity index 100%
rename from docs/html/design/static/content/notifications_pattern_phone_ticker.png
rename to docs/html/design/media/notifications_pattern_phone_ticker.png
diff --git a/docs/html/design/static/content/notifications_pattern_real_time_people.png b/docs/html/design/media/notifications_pattern_real_time_people.png
similarity index 100%
rename from docs/html/design/static/content/notifications_pattern_real_time_people.png
rename to docs/html/design/media/notifications_pattern_real_time_people.png
diff --git a/docs/html/design/static/content/notifications_pattern_social_fail.png b/docs/html/design/media/notifications_pattern_social_fail.png
similarity index 100%
rename from docs/html/design/static/content/notifications_pattern_social_fail.png
rename to docs/html/design/media/notifications_pattern_social_fail.png
diff --git a/docs/html/design/static/content/notifications_pattern_tablet.png b/docs/html/design/media/notifications_pattern_tablet.png
similarity index 100%
rename from docs/html/design/static/content/notifications_pattern_tablet.png
rename to docs/html/design/media/notifications_pattern_tablet.png
diff --git a/docs/html/design/static/content/patterns_landing.png b/docs/html/design/media/patterns_landing.png
similarity index 100%
rename from docs/html/design/static/content/patterns_landing.png
rename to docs/html/design/media/patterns_landing.png
diff --git a/docs/html/design/static/content/picker_datetime.png b/docs/html/design/media/picker_datetime.png
similarity index 100%
rename from docs/html/design/static/content/picker_datetime.png
rename to docs/html/design/media/picker_datetime.png
diff --git a/docs/html/design/static/content/picker_space.png b/docs/html/design/media/picker_space.png
similarity index 100%
rename from docs/html/design/static/content/picker_space.png
rename to docs/html/design/media/picker_space.png
diff --git a/docs/html/design/static/content/principles_decide_for_me.png b/docs/html/design/media/principles_decide_for_me.png
similarity index 100%
rename from docs/html/design/static/content/principles_decide_for_me.png
rename to docs/html/design/media/principles_decide_for_me.png
diff --git a/docs/html/design/static/content/principles_delight.png b/docs/html/design/media/principles_delight.png
similarity index 100%
rename from docs/html/design/static/content/principles_delight.png
rename to docs/html/design/media/principles_delight.png
diff --git a/docs/html/design/static/content/principles_error.png b/docs/html/design/media/principles_error.png
similarity index 100%
rename from docs/html/design/static/content/principles_error.png
rename to docs/html/design/media/principles_error.png
diff --git a/docs/html/design/static/content/principles_get_to_know_me.png b/docs/html/design/media/principles_get_to_know_me.png
similarity index 100%
rename from docs/html/design/static/content/principles_get_to_know_me.png
rename to docs/html/design/media/principles_get_to_know_me.png
diff --git a/docs/html/design/static/content/principles_heavy_lifting.png b/docs/html/design/media/principles_heavy_lifting.png
similarity index 100%
rename from docs/html/design/static/content/principles_heavy_lifting.png
rename to docs/html/design/media/principles_heavy_lifting.png
diff --git a/docs/html/design/static/content/principles_important_interruption.png b/docs/html/design/media/principles_important_interruption.png
similarity index 100%
rename from docs/html/design/static/content/principles_important_interruption.png
rename to docs/html/design/media/principles_important_interruption.png
diff --git a/docs/html/design/static/content/principles_information_when_need_it.png b/docs/html/design/media/principles_information_when_need_it.png
similarity index 100%
rename from docs/html/design/static/content/principles_information_when_need_it.png
rename to docs/html/design/media/principles_information_when_need_it.png
diff --git a/docs/html/design/static/content/principles_keep_it_brief.png b/docs/html/design/media/principles_keep_it_brief.png
similarity index 100%
rename from docs/html/design/static/content/principles_keep_it_brief.png
rename to docs/html/design/media/principles_keep_it_brief.png
diff --git a/docs/html/design/static/content/principles_looks_same.png b/docs/html/design/media/principles_looks_same.png
similarity index 100%
rename from docs/html/design/static/content/principles_looks_same.png
rename to docs/html/design/media/principles_looks_same.png
diff --git a/docs/html/design/static/content/principles_make_important_fast.png b/docs/html/design/media/principles_make_important_fast.png
similarity index 100%
rename from docs/html/design/static/content/principles_make_important_fast.png
rename to docs/html/design/media/principles_make_important_fast.png
diff --git a/docs/html/design/static/content/principles_make_it_mine.png b/docs/html/design/media/principles_make_it_mine.png
similarity index 100%
rename from docs/html/design/static/content/principles_make_it_mine.png
rename to docs/html/design/media/principles_make_it_mine.png
diff --git a/docs/html/design/static/content/principles_navigation.png b/docs/html/design/media/principles_navigation.png
similarity index 100%
rename from docs/html/design/static/content/principles_navigation.png
rename to docs/html/design/media/principles_navigation.png
diff --git a/docs/html/design/static/content/principles_never_lose_stuff.png b/docs/html/design/media/principles_never_lose_stuff.png
similarity index 100%
rename from docs/html/design/static/content/principles_never_lose_stuff.png
rename to docs/html/design/media/principles_never_lose_stuff.png
diff --git a/docs/html/design/static/content/principles_pictures.png b/docs/html/design/media/principles_pictures.png
similarity index 100%
rename from docs/html/design/static/content/principles_pictures.png
rename to docs/html/design/media/principles_pictures.png
diff --git a/docs/html/design/static/content/principles_real_objects.png b/docs/html/design/media/principles_real_objects.png
similarity index 100%
rename from docs/html/design/static/content/principles_real_objects.png
rename to docs/html/design/media/principles_real_objects.png
diff --git a/docs/html/design/static/content/principles_sprinkle_encouragement.png b/docs/html/design/media/principles_sprinkle_encouragement.png
similarity index 100%
rename from docs/html/design/static/content/principles_sprinkle_encouragement.png
rename to docs/html/design/media/principles_sprinkle_encouragement.png
diff --git a/docs/html/design/static/content/principles_tricks.png b/docs/html/design/media/principles_tricks.png
similarity index 100%
rename from docs/html/design/static/content/principles_tricks.png
rename to docs/html/design/media/principles_tricks.png
diff --git a/docs/html/design/static/content/progress_activity.png b/docs/html/design/media/progress_activity.png
similarity index 100%
rename from docs/html/design/static/content/progress_activity.png
rename to docs/html/design/media/progress_activity.png
diff --git a/docs/html/design/static/content/progress_activity2.png b/docs/html/design/media/progress_activity2.png
similarity index 100%
rename from docs/html/design/static/content/progress_activity2.png
rename to docs/html/design/media/progress_activity2.png
diff --git a/docs/html/design/static/content/progress_download.png b/docs/html/design/media/progress_download.png
similarity index 100%
rename from docs/html/design/static/content/progress_download.png
rename to docs/html/design/media/progress_download.png
diff --git a/docs/html/design/static/content/progress_themes.png b/docs/html/design/media/progress_themes.png
similarity index 100%
rename from docs/html/design/static/content/progress_themes.png
rename to docs/html/design/media/progress_themes.png
diff --git a/docs/html/design/static/content/scroll_index.mp4 b/docs/html/design/media/scroll_index.mp4
similarity index 100%
rename from docs/html/design/static/content/scroll_index.mp4
rename to docs/html/design/media/scroll_index.mp4
diff --git a/docs/html/design/static/content/scroll_index.ogv b/docs/html/design/media/scroll_index.ogv
similarity index 100%
rename from docs/html/design/static/content/scroll_index.ogv
rename to docs/html/design/media/scroll_index.ogv
diff --git a/docs/html/design/static/content/scroll_index.webm b/docs/html/design/media/scroll_index.webm
similarity index 100%
rename from docs/html/design/static/content/scroll_index.webm
rename to docs/html/design/media/scroll_index.webm
diff --git a/docs/html/design/static/content/scroll_indicator.mp4 b/docs/html/design/media/scroll_indicator.mp4
similarity index 100%
rename from docs/html/design/static/content/scroll_indicator.mp4
rename to docs/html/design/media/scroll_indicator.mp4
diff --git a/docs/html/design/static/content/scroll_indicator.ogv b/docs/html/design/media/scroll_indicator.ogv
similarity index 100%
rename from docs/html/design/static/content/scroll_indicator.ogv
rename to docs/html/design/media/scroll_indicator.ogv
diff --git a/docs/html/design/static/content/scroll_indicator.webm b/docs/html/design/media/scroll_indicator.webm
similarity index 100%
rename from docs/html/design/static/content/scroll_indicator.webm
rename to docs/html/design/media/scroll_indicator.webm
diff --git a/docs/html/design/static/content/seekbar_example.png b/docs/html/design/media/seekbar_example.png
similarity index 100%
rename from docs/html/design/static/content/seekbar_example.png
rename to docs/html/design/media/seekbar_example.png
diff --git a/docs/html/design/static/content/seekbar_style.png b/docs/html/design/media/seekbar_style.png
similarity index 100%
rename from docs/html/design/static/content/seekbar_style.png
rename to docs/html/design/media/seekbar_style.png
diff --git a/docs/html/design/static/content/selection_adjusting_actions.png b/docs/html/design/media/selection_adjusting_actions.png
similarity index 100%
rename from docs/html/design/static/content/selection_adjusting_actions.png
rename to docs/html/design/media/selection_adjusting_actions.png
diff --git a/docs/html/design/static/content/selection_cab_big.png b/docs/html/design/media/selection_cab_big.png
similarity index 100%
rename from docs/html/design/static/content/selection_cab_big.png
rename to docs/html/design/media/selection_cab_big.png
diff --git a/docs/html/design/static/content/selection_cab_example.png b/docs/html/design/media/selection_cab_example.png
similarity index 100%
rename from docs/html/design/static/content/selection_cab_example.png
rename to docs/html/design/media/selection_cab_example.png
diff --git a/docs/html/design/static/content/selection_context_menu.png b/docs/html/design/media/selection_context_menu.png
similarity index 100%
rename from docs/html/design/static/content/selection_context_menu.png
rename to docs/html/design/media/selection_context_menu.png
diff --git a/docs/html/design/static/content/spinners_actionbar.png b/docs/html/design/media/spinners_actionbar.png
similarity index 100%
rename from docs/html/design/static/content/spinners_actionbar.png
rename to docs/html/design/media/spinners_actionbar.png
diff --git a/docs/html/design/static/content/spinners_form.png b/docs/html/design/media/spinners_form.png
similarity index 100%
rename from docs/html/design/static/content/spinners_form.png
rename to docs/html/design/media/spinners_form.png
diff --git a/docs/html/design/static/content/spinners_hololightanddark.png b/docs/html/design/media/spinners_hololightanddark.png
similarity index 100%
rename from docs/html/design/static/content/spinners_hololightanddark.png
rename to docs/html/design/media/spinners_hololightanddark.png
diff --git a/docs/html/design/static/content/swipe_tabs.mp4 b/docs/html/design/media/swipe_tabs.mp4
similarity index 100%
rename from docs/html/design/static/content/swipe_tabs.mp4
rename to docs/html/design/media/swipe_tabs.mp4
diff --git a/docs/html/design/static/content/swipe_tabs.ogv b/docs/html/design/media/swipe_tabs.ogv
similarity index 100%
rename from docs/html/design/static/content/swipe_tabs.ogv
rename to docs/html/design/media/swipe_tabs.ogv
diff --git a/docs/html/design/static/content/swipe_tabs.png b/docs/html/design/media/swipe_tabs.png
similarity index 100%
rename from docs/html/design/static/content/swipe_tabs.png
rename to docs/html/design/media/swipe_tabs.png
diff --git a/docs/html/design/static/content/swipe_tabs.webm b/docs/html/design/media/swipe_tabs.webm
similarity index 100%
rename from docs/html/design/static/content/swipe_tabs.webm
rename to docs/html/design/media/swipe_tabs.webm
diff --git a/docs/html/design/static/content/swipe_views.png b/docs/html/design/media/swipe_views.png
similarity index 100%
rename from docs/html/design/static/content/swipe_views.png
rename to docs/html/design/media/swipe_views.png
diff --git a/docs/html/design/static/content/swipe_views2.png b/docs/html/design/media/swipe_views2.png
similarity index 100%
rename from docs/html/design/static/content/swipe_views2.png
rename to docs/html/design/media/swipe_views2.png
diff --git a/docs/html/design/static/content/switches_checkboxes.png b/docs/html/design/media/switches_checkboxes.png
similarity index 100%
rename from docs/html/design/static/content/switches_checkboxes.png
rename to docs/html/design/media/switches_checkboxes.png
diff --git a/docs/html/design/static/content/switches_radios.png b/docs/html/design/media/switches_radios.png
similarity index 100%
rename from docs/html/design/static/content/switches_radios.png
rename to docs/html/design/media/switches_radios.png
diff --git a/docs/html/design/static/content/switches_switches.png b/docs/html/design/media/switches_switches.png
similarity index 100%
rename from docs/html/design/static/content/switches_switches.png
rename to docs/html/design/media/switches_switches.png
diff --git a/docs/html/design/static/content/system_ui_landing.png b/docs/html/design/media/system_ui_landing.png
similarity index 100%
rename from docs/html/design/static/content/system_ui_landing.png
rename to docs/html/design/media/system_ui_landing.png
diff --git a/docs/html/design/static/content/tabs_overview.png b/docs/html/design/media/tabs_overview.png
similarity index 100%
rename from docs/html/design/static/content/tabs_overview.png
rename to docs/html/design/media/tabs_overview.png
diff --git a/docs/html/design/static/content/tabs_scrolly.mp4 b/docs/html/design/media/tabs_scrolly.mp4
similarity index 100%
rename from docs/html/design/static/content/tabs_scrolly.mp4
rename to docs/html/design/media/tabs_scrolly.mp4
diff --git a/docs/html/design/static/content/tabs_scrolly.ogv b/docs/html/design/media/tabs_scrolly.ogv
similarity index 100%
rename from docs/html/design/static/content/tabs_scrolly.ogv
rename to docs/html/design/media/tabs_scrolly.ogv
diff --git a/docs/html/design/static/content/tabs_scrolly.webm b/docs/html/design/media/tabs_scrolly.webm
similarity index 100%
rename from docs/html/design/static/content/tabs_scrolly.webm
rename to docs/html/design/media/tabs_scrolly.webm
diff --git a/docs/html/design/static/content/tabs_stacked.png b/docs/html/design/media/tabs_stacked.png
similarity index 100%
rename from docs/html/design/static/content/tabs_stacked.png
rename to docs/html/design/media/tabs_stacked.png
diff --git a/docs/html/design/static/content/tabs_standard.png b/docs/html/design/media/tabs_standard.png
similarity index 100%
rename from docs/html/design/static/content/tabs_standard.png
rename to docs/html/design/media/tabs_standard.png
diff --git a/docs/html/design/static/content/tabs_youtube.png b/docs/html/design/media/tabs_youtube.png
similarity index 100%
rename from docs/html/design/static/content/tabs_youtube.png
rename to docs/html/design/media/tabs_youtube.png
diff --git a/docs/html/design/static/content/text_input_holodarkandlight.png b/docs/html/design/media/text_input_holodarkandlight.png
similarity index 100%
rename from docs/html/design/static/content/text_input_holodarkandlight.png
rename to docs/html/design/media/text_input_holodarkandlight.png
diff --git a/docs/html/design/static/content/text_input_singlevsmultiline.png b/docs/html/design/media/text_input_singlevsmultiline.png
similarity index 100%
rename from docs/html/design/static/content/text_input_singlevsmultiline.png
rename to docs/html/design/media/text_input_singlevsmultiline.png
diff --git a/docs/html/design/static/content/text_input_textselection.png b/docs/html/design/media/text_input_textselection.png
similarity index 100%
rename from docs/html/design/static/content/text_input_textselection.png
rename to docs/html/design/media/text_input_textselection.png
diff --git a/docs/html/design/static/content/text_input_typesandtypedown.png b/docs/html/design/media/text_input_typesandtypedown.png
similarity index 100%
rename from docs/html/design/static/content/text_input_typesandtypedown.png
rename to docs/html/design/media/text_input_typesandtypedown.png
diff --git a/docs/html/design/static/content/themes_holo_dark.png b/docs/html/design/media/themes_holo_dark.png
similarity index 100%
rename from docs/html/design/static/content/themes_holo_dark.png
rename to docs/html/design/media/themes_holo_dark.png
diff --git a/docs/html/design/static/content/themes_holo_inverse.png b/docs/html/design/media/themes_holo_inverse.png
similarity index 100%
rename from docs/html/design/static/content/themes_holo_inverse.png
rename to docs/html/design/media/themes_holo_inverse.png
diff --git a/docs/html/design/static/content/themes_holo_light.png b/docs/html/design/media/themes_holo_light.png
similarity index 100%
rename from docs/html/design/static/content/themes_holo_light.png
rename to docs/html/design/media/themes_holo_light.png
diff --git a/docs/html/design/static/content/touch_feedback_communication.png b/docs/html/design/media/touch_feedback_communication.png
similarity index 100%
rename from docs/html/design/static/content/touch_feedback_communication.png
rename to docs/html/design/media/touch_feedback_communication.png
diff --git a/docs/html/design/static/content/touch_feedback_manipulation.png b/docs/html/design/media/touch_feedback_manipulation.png
similarity index 100%
rename from docs/html/design/static/content/touch_feedback_manipulation.png
rename to docs/html/design/media/touch_feedback_manipulation.png
diff --git a/docs/html/design/static/content/touch_feedback_reaction_response.png b/docs/html/design/media/touch_feedback_reaction_response.png
similarity index 100%
rename from docs/html/design/static/content/touch_feedback_reaction_response.png
rename to docs/html/design/media/touch_feedback_reaction_response.png
diff --git a/docs/html/design/static/content/touch_feedback_states.png b/docs/html/design/media/touch_feedback_states.png
similarity index 100%
rename from docs/html/design/static/content/touch_feedback_states.png
rename to docs/html/design/media/touch_feedback_states.png
diff --git a/docs/html/design/static/content/typography_alphas.png b/docs/html/design/media/typography_alphas.png
similarity index 100%
rename from docs/html/design/static/content/typography_alphas.png
rename to docs/html/design/media/typography_alphas.png
diff --git a/docs/html/design/static/content/typography_defaults.png b/docs/html/design/media/typography_defaults.png
similarity index 100%
rename from docs/html/design/static/content/typography_defaults.png
rename to docs/html/design/media/typography_defaults.png
diff --git a/docs/html/design/static/content/typography_main.png b/docs/html/design/media/typography_main.png
similarity index 100%
rename from docs/html/design/static/content/typography_main.png
rename to docs/html/design/media/typography_main.png
diff --git a/docs/html/design/static/content/typography_sizes.png b/docs/html/design/media/typography_sizes.png
similarity index 100%
rename from docs/html/design/static/content/typography_sizes.png
rename to docs/html/design/media/typography_sizes.png
diff --git a/docs/html/design/static/content/ui_overview_all_apps.png b/docs/html/design/media/ui_overview_all_apps.png
similarity index 100%
rename from docs/html/design/static/content/ui_overview_all_apps.png
rename to docs/html/design/media/ui_overview_all_apps.png
diff --git a/docs/html/design/static/content/ui_overview_app_ui.png b/docs/html/design/media/ui_overview_app_ui.png
similarity index 100%
rename from docs/html/design/static/content/ui_overview_app_ui.png
rename to docs/html/design/media/ui_overview_app_ui.png
diff --git a/docs/html/design/static/content/ui_overview_home_screen.png b/docs/html/design/media/ui_overview_home_screen.png
similarity index 100%
rename from docs/html/design/static/content/ui_overview_home_screen.png
rename to docs/html/design/media/ui_overview_home_screen.png
diff --git a/docs/html/design/static/content/ui_overview_notifications.png b/docs/html/design/media/ui_overview_notifications.png
similarity index 100%
rename from docs/html/design/static/content/ui_overview_notifications.png
rename to docs/html/design/media/ui_overview_notifications.png
diff --git a/docs/html/design/static/content/ui_overview_recents.png b/docs/html/design/media/ui_overview_recents.png
similarity index 100%
rename from docs/html/design/static/content/ui_overview_recents.png
rename to docs/html/design/media/ui_overview_recents.png
diff --git a/docs/html/design/static/content/ui_overview_system_ui.png b/docs/html/design/media/ui_overview_system_ui.png
similarity index 100%
rename from docs/html/design/static/content/ui_overview_system_ui.png
rename to docs/html/design/media/ui_overview_system_ui.png
diff --git a/docs/html/design/static/content/whats_new_action_bar.png b/docs/html/design/media/whats_new_action_bar.png
similarity index 100%
rename from docs/html/design/static/content/whats_new_action_bar.png
rename to docs/html/design/media/whats_new_action_bar.png
diff --git a/docs/html/design/static/content/whats_new_multipanel.png b/docs/html/design/media/whats_new_multipanel.png
similarity index 100%
rename from docs/html/design/static/content/whats_new_multipanel.png
rename to docs/html/design/media/whats_new_multipanel.png
diff --git a/docs/html/design/static/content/whats_new_multiselect.png b/docs/html/design/media/whats_new_multiselect.png
similarity index 100%
rename from docs/html/design/static/content/whats_new_multiselect.png
rename to docs/html/design/media/whats_new_multiselect.png
diff --git a/docs/html/design/static/content/whats_new_nav_bar.png b/docs/html/design/media/whats_new_nav_bar.png
similarity index 100%
rename from docs/html/design/static/content/whats_new_nav_bar.png
rename to docs/html/design/media/whats_new_nav_bar.png
diff --git a/docs/html/design/patterns/actionbar.html b/docs/html/design/patterns/actionbar.jd
similarity index 62%
rename from docs/html/design/patterns/actionbar.html
rename to docs/html/design/patterns/actionbar.jd
index e93498e6b73ed..9e3f48c2d9f54 100644
--- a/docs/html/design/patterns/actionbar.html
+++ b/docs/html/design/patterns/actionbar.jd
@@ -1,112 +1,7 @@
-
-
-  
-    
-    
+page.title=Action Bar
+@jd:body
 
-Android Design - Action Bar
-    
-    
-    
-    
-    
-
-  
-  
-
-    
          
-
-      
          Android Design
          
-
-      
          
-
-        
-
-        
          
-
-          
-          
          
-            
          
-              
          Action Bar
          
-            
          
-            
          
-              Previous
-              Next
-            
          
-          
          
-          
-
-          
-
-
+
 
 
          The action bar is arguably the most important structural element of an Android app. It's a
 dedicated piece of real estate at the top of each screen that is generally persistent throughout the
@@ -125,7 +20,7 @@ your app's interface consistent with the core Android apps.
          
 
          General Organization
          
 
 
          The action bar is split into four different functional areas that apply to most apps.
          
-
+
 
 
          
   
          
@@ -138,10 +33,10 @@ The app icon establishes your app's identity. It can be replaced with a differen
 if you wish.
 Important: If the app is currently not displaying the top-level screen, be sure to display the Up
 caret to the left of the app icon, so the user can navigate up the hierarchy. For more discussion of
-Up navigation, see the Navigation pattern.
+Up navigation, see the Navigation pattern.
 
 
          
-  
+  
   
          
     App icon with and without "up" affordance.
   
          
@@ -195,7 +90,7 @@ rotation on different screen sizes.
          
 
          You can adapt to such changes by using split action bars, which allow you to distribute action bar
 content across multiple bars located below the main action bar or at the bottom of the screen.
          
 
-
+
 
          
   Split action bar showing action buttons at the bottom of the screen in vertical orientation.
 
          
@@ -221,7 +116,7 @@ the top bar.
          
   
          
   
          
 
-    
+    
 
   
          
 
          
@@ -232,7 +127,7 @@ the top bar.
          
 duration of a particular sub-task. CABs are most typically used for tasks that involve acting on
 selected data or text.
          
 
-
+
 
          
   Contextual action bar shown in Browser and Gmail
 
          
@@ -255,7 +150,7 @@ content of a CAB in order to insert the actions you would like the user to be ab
 
          Tabs display app views concurrently and make it easy to explore and switch between them. Use tabs
 if you expect your users to switch views frequently.
          
 
-
+
 
 
          There are two types of tabs: fixed and scrollable.
          
 
@@ -276,12 +171,12 @@ themselves.
          
   
          
 
     
     
          
-      Scrolling tabs on Google Play.
+      Scrolling tabs in Google Play.
       
           
          
     
          
 
@@ -298,7 +193,7 @@ tabs. Fixed tabs in the main action bar can move to the top bar when the screen
   
          
   
          
 
-    
+    
     
          
       Default fixed tabs shown in Holo Dark & Light.
     
          
@@ -320,7 +215,7 @@ tabs. Fixed tabs in the main action bar can move to the top bar when the screen
   
          
   
          
 
-    
+    
     
          
       Action bar spinner from Calendar application.
     
          
@@ -336,7 +231,7 @@ action overflow. The action bar and the action overflow should only present acti
 are available. If an action is unavailable in the current context, hide it. Do not show it as
 disabled.
          
 
-
+
 
          
   A sampling of action buttons used throughout the Gmail application.
 
          
@@ -403,7 +298,7 @@ display the action overflow when the user presses the key.
          
   
          
   
          
 
-    
+    
     
          
       Action overflow is pinned to the right side.
     
          
@@ -427,7 +322,7 @@ rules:
        - +
        In the above table "o" denotes an action bar item and "=" an overflow icon.
        @@ -438,7 +333,7 @@ provider in your action bar. The share action provider is designed to speed displaying the most recently used sharing service next to a spinner button that contains other sharing options.

        - +
        The Gallery app's share action provider with extended spinner for additional sharing options.
        @@ -457,55 +352,3 @@ actions exceeds the capacity of the main action bar, display them separately in 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.

        - - - - -
        -
         
        -
        - Previous - Next -
        -
        - - - - - -
        - - - -

        - Site Terms of Service – - Privacy Policy – - Brand Guidelines -

        - -
        - - - - - - - - - - - diff --git a/docs/html/design/patterns/app-structure.html b/docs/html/design/patterns/app-structure.jd similarity index 57% rename from docs/html/design/patterns/app-structure.html rename to docs/html/design/patterns/app-structure.jd index 678059495552c..b54b12ff3262d 100644 --- a/docs/html/design/patterns/app-structure.html +++ b/docs/html/design/patterns/app-structure.jd @@ -1,110 +1,5 @@ - - - - - - -Android Design - Application Structure - - - - - - - - - -
        - -
        Android Design
        - -
        - - - -
        - - -
        -
        -

        Application Structure

        -
        -
        - Previous - Next -
        -
        - - - +page.title=Application Structure +@jd:body

        Apps come in many varieties that address very different needs. For example:

          @@ -112,7 +7,7 @@ Android Design - Application Structure single screen
        • Apps such as Phone whose main purpose is to switch between different activities without deeper navigation
          • -
        • Apps such as Gmail and Google Play that combine a broad set of data views with deep navigation
          • +
        • Apps such as Gmail or Google Play that combine a broad set of data views with deep navigation

        Your app's structure depends largely on the content and tasks you want to surface for your users.

        General Structure

        @@ -123,7 +18,7 @@ deep and complex, category views connect top level and detail views.

        - +
        @@ -163,7 +58,7 @@ layouts that are visually engaging and appropriate for the data type and screen
        - +
        The Google Play app's start screen primarily allows navigation into the stores for Apps, Music, Books, Movies and Games. It is also enriched with tailored recommendations and promotions that @@ -194,7 +89,7 @@ important actions.

        - +
        Email is about productivity, so an efficient, easy-to-skim list with higher data density works well. Navigation supports switching between accounts and recent labels. Icons for creating a @@ -216,7 +111,7 @@ monotony of simple list views.

        - +
        The 3D carousel celebrates cover art and establishes a unique identity for the Music app. Defaulting to the Recent view keeps the focus on music the user has been listening to lately. @@ -248,7 +143,7 @@ experience than to an explicit navigation step.

        items are in view simultaneously). Keep the number of scrolling tabs at a manageable level to minimize navigational effort. Rule of thumb: no more than 5–7 tabs.

        - +
        Google Play uses tabs to simultaneously show category choice and content. To navigate between categories, users can swipe left/right on the content. @@ -260,7 +155,7 @@ minimize navigational effort. Rule of thumb: no more than 5–7 tabs.

        If the categories in the tabs are not closely related, favor fixed tabs, so that all categories are in view at the same time.

        - +
        YouTube uses fixed tabs to switch between different, relatively unrelated functional areas.
        @@ -275,7 +170,7 @@ invocation of actions for a data item from within list or grid views, display pr directly on list view items using drop-downs or split list items. This lets people invoke actions on data without having to navigate all the way down the hierarchy.

        - +
        Music allows the user to act upon a data item (song) from within the category view (album), thereby removing the need to navigate all the way down to the song's detail view. @@ -301,12 +196,12 @@ the data type being displayed, and therefore differs widely among apps.

        For immersive content, make use of the lights-out mode to allow for distraction-free viewing of full-screen content.

        - +
        - +
        Google Books' detail view is all about replicating the experience of reading an actual book. The page-flip animation reinforces that notion. To create an immersive experience the app @@ -327,12 +222,12 @@ full-screen content.

        between items from within the detail view. Use swipe views or other techniques, such as filmstrips, to achieve this.

        - +
        Gmail using swipe views to navigate from detail view to detail view.
        - +
        In addition to supporting swipe gestures to move left or right through images, Gallery provides a filmstrip control that lets people quickly jump to specific images. @@ -357,55 +252,3 @@ to achieve this.

        Allow for quick navigation between detail items with swipe views.

      - - - - -
      -
       
      -
      - Previous - Next -
      -
      - - - - - -
      - - - -

      - Site Terms of Service – - Privacy Policy – - Brand Guidelines -

      - -
      - - - - - - - - - - - diff --git a/docs/html/design/patterns/compatibility.html b/docs/html/design/patterns/compatibility.html deleted file mode 100644 index d6e59f572037a..0000000000000 --- a/docs/html/design/patterns/compatibility.html +++ /dev/null @@ -1,218 +0,0 @@ - - - - - - -Android Design - Backwards Compatibility - - - - - - - - - -
      - -
      Android Design
      - -
      - - - -
      - - -
      -
      -

      Backwards Compatibility

      -
      -
      - Previous - Next -
      -
      - - - - -

      Significant changes in Android 3.0 included:

      -
        -
      • Deprecation of navigation hardware keys (Back, Menu, Search, Home) in favor of handling navigation - via virtual controls (Back, Home, Recents).
        • -
      • Robust pattern for the use of menus in action bars.
        • -
      -

      Android 4.0 brings these changes for tablets to the phone platform.

      - -

      Adapting Android 4.0 to Older Hardware and Apps

      - -
      -
      - -

      Phones with virtual navigation controls

      -

      Android apps written for Android 3.0 and later display actions in the action bar. Actions that don't -fit in the action bar or aren't important enough to be displayed at the top level appear in the -action overflow.

      -

      Users access the action overflow by touching it in the action bar.

      - -
      -
      - - - -
      -
      - -
      -
      - -

      Phones with physical navigation keys

      -

      Android phones with traditional navigation hardware keys don't display the virtual navigation bar at -the bottom of the screen. Instead, the action overflow is available from the menu hardware key. The -resulting actions popup has the same style as in the previous example, but is displayed at the bottom of the screen.

      - -
      -
      - - - -
      -
      - -
      -
      - -

      Legacy apps on phones with virtual navigation controls

      -

      When you run an app that was built for Android 2.3 or earlier on a phone with virtual navigation -controls, an action overflow control appears at the right side of the virtual navigation bar. You -can touch the control to display the app's actions in the traditional Android menu styling.

      - -
      -
      - - - -
      -
      - - - - -
      -
       
      -
      - Previous - Next -
      -
      - -
      - -
      - -
      - - - -

      - Site Terms of Service – - Privacy Policy – - Brand Guidelines -

      - -
      -
      - - - - - - - - - - diff --git a/docs/html/design/patterns/compatibility.jd b/docs/html/design/patterns/compatibility.jd new file mode 100644 index 0000000000000..84ae3375a8afc --- /dev/null +++ b/docs/html/design/patterns/compatibility.jd @@ -0,0 +1,61 @@ +page.title=Backwards Compatibility +@jd:body + +

      Significant changes in Android 3.0 included:

      +
        +
      • Deprecation of navigation hardware keys (Back, Menu, Search, Home) in favor of handling navigation + via virtual controls (Back, Home, Recents).
        • +
      • Robust pattern for the use of menus in action bars.
        • +
      +

      Android 4.0 brings these changes for tablets to the phone platform.

      + +

      Adapting Android 4.0 to Older Hardware and Apps

      + +
      +
      + +

      Phones with virtual navigation controls

      +

      Android apps written for Android 3.0 and later display actions in the action bar. Actions that don't +fit in the action bar or aren't important enough to be displayed at the top level appear in the +action overflow.

      +

      Users access the action overflow by touching it in the action bar.

      + +
      +
      + + + +
      +
      + +
      +
      + +

      Phones with physical navigation keys

      +

      Android phones with traditional navigation hardware keys don't display the virtual navigation bar at +the bottom of the screen. Instead, the action overflow is available from the menu hardware key. The +resulting actions popup has the same style as in the previous example, but is displayed at the bottom of the screen.

      + +
      +
      + + + +
      +
      + +
      +
      + +

      Legacy apps on phones with virtual navigation controls

      +

      When you run an app that was built for Android 2.3 or earlier on a phone with virtual navigation +controls, an action overflow control appears at the right side of the virtual navigation bar. You +can touch the control to display the app's actions in the traditional Android menu styling.

      + +
      +
      + + + +
      +
      diff --git a/docs/html/design/patterns/gestures.html b/docs/html/design/patterns/gestures.html deleted file mode 100644 index c88817f1668d1..0000000000000 --- a/docs/html/design/patterns/gestures.html +++ /dev/null @@ -1,272 +0,0 @@ - - - - - - -Android Design - Gestures - - - - - - - - - -
      - -
      Android Design
      - -
      - - - -
      - - -
      -
      -

      Gestures

      -
      -
      - Previous - Next -
      -
      - - - - -

      Gestures allow users to interact with your app by manipulating the screen objects you provide. The -following table shows the core gesture set that is supported in Android.

      - -
      -
      - - - -

      Touch

      -

      Triggers the default functionality for a given item.

      - -
        -
      • -

        Action

        -

        Press, lift

        • -
      - -
      -
      - - - -

      Long press

      -

      Enters data selection mode. Allows you to select one or more items in a view and act upon - the data using a contextual action bar. Avoid using long press for showing contextual menus.

      - -
        -
      • -

        Action

        -

        Press, wait, lift

        • -
      - -
      -
      - - - -

      Swipe

      -

      Scrolls overflowing content, or navigates between views in the same hierarchy.

      - -
        -
      • -

        Action

        -

        Press, move, lift

        • -
      - -
      -
      - - -
      -
      - - - -

      Drag

      -

      Rearranges data within a view, or moves data into a container (e.g. folders on Home Screen).

      - -
        -
      • -

        Action

        -

        Long press, move, lift

        • -
      - -
      -
      - - - -

      Double touch

      -

      Zooms into content. Also used as a secondary gesture for text selection.

      - -
        -
      • -

        Action

        -

        Two touches in quick succession

        • -
      - -
      -
      - - - -

      Pinch open

      -

      Zooms into content.

      - -
        -
      • -

        Action

        -

        2-finger press, move outwards, lift

        • -
      - -
      -
      - - -
      -
      - - - -

      Pinch close

      -

      Zooms out of content.

      - -
        -
      • -

        Action

        -

        2-finger press, move inwards, lift

        • -
      - -
      -
      - - - - -
      -
       
      -
      - Previous - Next -
      -
      - -
      - -
      - -
      - - - -

      - Site Terms of Service – - Privacy Policy – - Brand Guidelines -

      - -
      -
      - - - - - - - - - - diff --git a/docs/html/design/patterns/gestures.jd b/docs/html/design/patterns/gestures.jd new file mode 100644 index 0000000000000..9868df204c62b --- /dev/null +++ b/docs/html/design/patterns/gestures.jd @@ -0,0 +1,115 @@ +page.title=Gestures +@jd:body + +

      Gestures allow users to interact with your app by manipulating the screen objects you provide. The +following table shows the core gesture set that is supported in Android.

      + +
      +
      + + + +

      Touch

      +

      Triggers the default functionality for a given item.

      + +
        +
      • +

        Action

        +

        Press, lift

        • +
      + +
      +
      + + + +

      Long press

      +

      Enters data selection mode. Allows you to select one or more items in a view and act upon + the data using a contextual action bar. Avoid using long press for showing contextual menus.

      + +
        +
      • +

        Action

        +

        Press, wait, lift

        • +
      + +
      +
      + + + +

      Swipe

      +

      Scrolls overflowing content, or navigates between views in the same hierarchy.

      + +
        +
      • +

        Action

        +

        Press, move, lift

        • +
      + +
      +
      + + +
      +
      + + + +

      Drag

      +

      Rearranges data within a view, or moves data into a container (e.g. folders on Home Screen).

      + +
        +
      • +

        Action

        +

        Long press, move, lift

        • +
      + +
      +
      + + + +

      Double touch

      +

      Zooms into content. Also used as a secondary gesture for text selection.

      + +
        +
      • +

        Action

        +

        Two touches in quick succession

        • +
      + +
      +
      + + + +

      Pinch open

      +

      Zooms into content.

      + +
        +
      • +

        Action

        +

        2-finger press, move outwards, lift

        • +
      + +
      +
      + + +
      +
      + + + +

      Pinch close

      +

      Zooms out of content.

      + +
        +
      • +

        Action

        +

        2-finger press, move inwards, lift

        • +
      + +
      +
      diff --git a/docs/html/design/patterns/index.html b/docs/html/design/patterns/index.html deleted file mode 100644 index 863baa996baad..0000000000000 --- a/docs/html/design/patterns/index.html +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - -Android Design - Design Patterns - - - - - - - - - - - -
      - -
      Android Design
      - - - -
      - - - -

      - Site Terms of Service – - Privacy Policy – - Brand Guidelines -

      - -
      -
      - - - - - - - - - - diff --git a/docs/html/design/patterns/index.jd b/docs/html/design/patterns/index.jd new file mode 100644 index 0000000000000..732e4dbc60bc5 --- /dev/null +++ b/docs/html/design/patterns/index.jd @@ -0,0 +1,29 @@ +page.title=Patterns +header.justLinks=1 +footer.hide=1 +@jd:body + + + +
      +
      + Design apps that behave in a consistent, predictable fashion. +

      + New in Android 4.0 +
      + + + + +
      diff --git a/docs/html/design/patterns/multi-pane-layouts.html b/docs/html/design/patterns/multi-pane-layouts.html deleted file mode 100644 index 7925c9818d86b..0000000000000 --- a/docs/html/design/patterns/multi-pane-layouts.html +++ /dev/null @@ -1,267 +0,0 @@ - - - - - - -Android Design - Multi-pane Layouts - - - - - - - - - -
      - -
      Android Design
      - -
      - - - -
      - - -
      -
      -

      Multi-pane Layouts

      -
      -
      - Previous - Next -
      -
      - - - - -

      When writing an app for Android, keep in mind that Android devices come in many different screen -sizes and types. Make sure that your app consistently provides a balanced and aesthetically pleasing -layout by adjusting its content to varying screen sizes and orientations.

      -

      Panels are a great way for your app to achieve this. They allow you to combine multiple views into -one compound view when a lot of horizontal screen real estate is available and by splitting them up -when less space is available.

      -

      Combining Multiple Views Into One

      - -

      On smaller devices your content is typically divided into a master grid or list view and a detail -view. Touching an item in the master view opens a different screen showing that item's detail -information.

      - - - -

      Because tablets have more screen real estate than phones, you can use panels to combine the related -list and detail views into a single compound view. This uses the additional space more efficiently -and makes navigating the app easier.

      - - - -

      In general, use the pane on the right to present more information about the item you selected in the -left pane. Make sure to keep the item in the left pane selected in order to establish the -relationship between the panels.

      -

      Compound Views and Orientation Changes

      - -

      Screens should have the same functionality regardless of orientation. If you use a compound view in -one orientation, don't split it up when the user rotates the screen. There are several techniques -you can use to adjust the layout after orientation change while keeping functional parity intact.

      - -
      -
      - - - -
      -
      - -

      Stretch/compress

      -

      Adjust the column width of your left pane to achieve a balanced layout in both orientations.

      - -
      -
      - -
      -
      - - - -
      -
      - -

      Stack

      -

      Rearrange the panels on your screen to match the orientation.

      - -
      -
      - -
      -
      - - - -
      -
      - -

      Expand/collapse

      -

      When the device rotates, collapse the left pane view to only show the most important information. -Provide an expand control that allows the user to bring the left pane content back to its original -width and vice versa.

      - -
      -
      - -
      -
      - - - -
      -
      - -

      Show/hide

      -

      After rotating the device, show the right pane in fullscreen view. Use the Up icon in the action bar -to show the left panel and allow navigation to a different email. Hide the left panel by touching -the content in the detail panel.

      - -
      -
      - -

      Checklist

      - -
        -
      • -

        Plan in advance on how your app scales to different screen sizes and screen orientations.

        -
        • -
      • -

        Identify the most appropriate method for the panels in your compound views to reorganize - themselves when screen orientation changes.

        -
        • -
      • -

        Look for opportunities to consolidate your views into multi-panel compound views.

        -
        • -
      • -

        Make sure that your screens provide functional parity after the screen orientation - changes.

        -
        • -
      - - - - -
      -
       
      -
      - Previous - Next -
      -
      - -
      - -
      - -
      - - - -

      - Site Terms of Service – - Privacy Policy – - Brand Guidelines -

      - -
      -
      - - - - - - - - - - diff --git a/docs/html/design/patterns/multi-pane-layouts.jd b/docs/html/design/patterns/multi-pane-layouts.jd new file mode 100644 index 0000000000000..0e63e32e72e26 --- /dev/null +++ b/docs/html/design/patterns/multi-pane-layouts.jd @@ -0,0 +1,110 @@ +page.title=Multi-pane Layouts +@jd:body + +

      When writing an app for Android, keep in mind that Android devices come in many different screen +sizes and types. Make sure that your app consistently provides a balanced and aesthetically pleasing +layout by adjusting its content to varying screen sizes and orientations.

      +

      Panels are a great way for your app to achieve this. They allow you to combine multiple views into +one compound view when a lot of horizontal screen real estate is available and by splitting them up +when less space is available.

      +

      Combining Multiple Views Into One

      + +

      On smaller devices your content is typically divided into a master grid or list view and a detail +view. Touching an item in the master view opens a different screen showing that item's detail +information.

      + + + +

      Because tablets have more screen real estate than phones, you can use panels to combine the related +list and detail views into a single compound view. This uses the additional space more efficiently +and makes navigating the app easier.

      + + + +

      In general, use the pane on the right to present more information about the item you selected in the +left pane. Make sure to keep the item in the left pane selected in order to establish the +relationship between the panels.

      +

      Compound Views and Orientation Changes

      + +

      Screens should have the same functionality regardless of orientation. If you use a compound view in +one orientation, don't split it up when the user rotates the screen. There are several techniques +you can use to adjust the layout after orientation change while keeping functional parity intact.

      + +
      +
      + + + +
      +
      + +

      Stretch/compress

      +

      Adjust the column width of your left pane to achieve a balanced layout in both orientations.

      + +
      +
      + +
      +
      + + + +
      +
      + +

      Stack

      +

      Rearrange the panels on your screen to match the orientation.

      + +
      +
      + +
      +
      + + + +
      +
      + +

      Expand/collapse

      +

      When the device rotates, collapse the left pane view to only show the most important information. +Provide an expand control that allows the user to bring the left pane content back to its original +width and vice versa.

      + +
      +
      + +
      +
      + + + +
      +
      + +

      Show/hide

      +

      After rotating the device, show the right pane in fullscreen view. Use the Up icon in the action bar +to show the left panel and allow navigation to a different email. Hide the left panel by touching +the content in the detail panel.

      + +
      +
      + +

      Checklist

      + +
        +
      • +

        Plan in advance on how your app scales to different screen sizes and screen orientations.

        +
        • +
      • +

        Identify the most appropriate method for the panels in your compound views to reorganize + themselves when screen orientation changes.

        +
        • +
      • +

        Look for opportunities to consolidate your views into multi-panel compound views.

        +
        • +
      • +

        Make sure that your screens provide functional parity after the screen orientation + changes.

        +
        • +
      diff --git a/docs/html/design/patterns/navigation.html b/docs/html/design/patterns/navigation.html deleted file mode 100644 index 5d1568e971118..0000000000000 --- a/docs/html/design/patterns/navigation.html +++ /dev/null @@ -1,275 +0,0 @@ - - - - - - -Android Design - Navigation with Back and Up - - - - - - - - - -
      - -
      Android Design
      - -
      - - - -
      - - -
      -
      -

      Navigation with Back and Up

      -
      -
      - Previous - Next -
      -
      - - - - -

      Consistent navigation is an essential component of the overall user experience. Few things frustrate -users more than basic navigation that behaves in inconsistent and unexpected ways. Android 3.0 -introduced significant changes to the global navigation behavior. Thoughtfully following the -guidelines for Back and Up will make your app's navigation predictable and reliable for your users.

      -

      Android 2.3 and earlier relied upon the system Back button for supporting navigation within an -app. With the introduction of action bars in Android 3.0, a second navigation mechanism appeared: -the Up button, consisting of the app icon and a left-point caret.

      - - - -

      Up vs. Back

      - -

      The Up button is used to navigate within an application based on the hierarchical relationships -between screens. For instance, if screen A displays a list of items, and selecting an item leads to -screen B (which presents that item in more detail), then screen B should offer an Up button that -returns to screen A.

      -

      If a screen is the topmost one in an app (i.e. the home of the app), it should not present an Up -button.

      -

      The system Back key is used to navigate based on the history of screens the user has recently seen, -in reverse chronological order—in effect, the temporal relationships between screens.

      -

      When the previously viewed screen is also the hierarchical parent of the current screen, pressing -the Back key will have the same result as pressing an Up button -- this is a common occurrence. -However, unlike the Up button, which ensures the user remains within your app, the Back key can -return the user to the Home screen, or even to a different application.

      - - - -

      The Back key also supports a few behaviors not directly tied to screen-to-screen navigation:

      -
        -
      • Back dismisses floating windows (dialogs, popups)
        • -
      • Back dismisses contextual action bars, and removes the highlight from the selected items
        • -
      • Back hides the onscreen keyboard (IME)
        • -
      -

      Navigation Within Your App

      - -

      Navigating to screens with multiple entry points

      -

      Sometimes a screen doesn't have a strict position within the app's hierarchy, and can be reached -from multiple entry points—e.g., a settings screen which can be navigated to from any screen -in your app. In this case, the Up button should choose to return to the referring screen, behaving -identically to Back.

      -

      Changing view within a screen

      -

      Changing view options for a screen does not change the behavior of Up or Back: the screen is still -in the same place within the app's hierarchy, and no new navigation history is created.

      -

      Examples of such view changes are:

      -
        -
      • Switching views using tabs and/or left-and-right swipes
        • -
      • Switching views using a dropdown (aka collapsed tabs)
        • -
      • Filtering a list
        • -
      • Sorting a list
        • -
      • Changing display characteristics (e.g. zooming)
        • -
      -

      Navigating between sibling screens

      -

      When your app supports navigation from a list of items to a detail view of one of those items, it's -often desirable to support direction navigation from that item to another one which precedes or -follows it in the list. For example, in Gmail, it's easy to swipe left or right from a conversation -to view a newer or older one in the same Inbox. Just as when changing view within a screen, such -navigation does not change the behavior of Up or Back.

      - - - -

      However, a notable exception to this occurs when browsing between "related" detail views not tied -together by the referring list—for example, when browsing on Google Play between apps from -the same developer, or albums by the same artist. In these cases, following each link does create -history, causing the Back button to step through each screen of related content which has been -viewed. Up should continue to bypass these related screens and navigate to the most recently viewed -container screen.

      - - - -

      You have the ability to make the Up behavior even smarter based on your knowledge of detail -view. If we extend our Google Play sample from above, imagine the user has navigated from the last Book -viewed to the details for the Movie adaptation. In that case, Up can return to a container (Movies) -which the user had not previously navigated through.

      - - - -

      Navigation From Outside Your App

      - -

      There are two categories of navigation from outside your app to screens deep within the app's -hierarchy:

      -
        -
      • App-to-app navigation, such as via intent completion.
        • -
      • System-to-app navigation, such as via notifications and home screen widgets.
        • -
      -

      Gmail provides examples of each of these. For app-to-app navigation, a "Share" intent goes directly -to the compose screen. For system-to-app navigation, both a new message notification and a home -screen widget can bypass the Inbox screen, taking the user directly to a conversation view.

      -

      App-to-app navigation

      -

      When navigating deep into your app's hierarchy directly from another app via an intent, Back will -return to the referring app.

      -

      The Up button is handled as follows: -- If the destination screen is typically reached from one particular screen within your app, Up - should navigate to that screen. -- Otherwise, Up should navigate to the topmost ("Home") screen of your app.

      -

      For example, after choosing to share a book being viewed on Google Play, the user navigates directly to -Gmail's compose screen. From there, Up returns to the Inbox (which happens to be both the -typical referrer to compose, as well as the topmost screen of the app), while Back returns to -Google Play.

      - - - -

      System-to-app navigation

      -

      If your app was reached via the system mechanisms of notifications or home screen widgets, Up -behaves as described for app-to-app navigation, above.

      -

      For the Back key, you should make navigation more predictably by inserting into the task's back -stack the complete upward navigation path to the app's topmost screen. This way, a user who has -forgotten how they entered your app can safely navigate to the app's topmost screen before exiting -it.

      -

      For example, Gmail's Home screen widget has a button for diving directly to its compose screen. -After following that path, the Back key first returns to the Inbox, and from there continues to -Home.

      - - - - - - - - -
      -
       
      -
      - Previous - Next -
      -
      - -
      - -
      - -
      - - - -

      - Site Terms of Service – - Privacy Policy – - Brand Guidelines -

      - -
      -
      - - - - - - - - - - diff --git a/docs/html/design/patterns/navigation.jd b/docs/html/design/patterns/navigation.jd new file mode 100644 index 0000000000000..d35cd8298eb04 --- /dev/null +++ b/docs/html/design/patterns/navigation.jd @@ -0,0 +1,116 @@ +page.title=Navigation with Back and Up +@jd:body + +

      Consistent navigation is an essential component of the overall user experience. Few things frustrate +users more than basic navigation that behaves in inconsistent and unexpected ways. Android 3.0 +introduced significant changes to the global navigation behavior. Thoughtfully following the +guidelines for Back and Up will make your app's navigation predictable and reliable for your users.

      +

      Android 2.3 and earlier relied upon the system Back button for supporting navigation within an +app. With the introduction of action bars in Android 3.0, a second navigation mechanism appeared: +the Up button, consisting of the app icon and a left-point caret.

      + + + +

      Up vs. Back

      + +

      The Up button is used to navigate within an application based on the hierarchical relationships +between screens. For instance, if screen A displays a list of items, and selecting an item leads to +screen B (which presents that item in more detail), then screen B should offer an Up button that +returns to screen A.

      +

      If a screen is the topmost one in an app (i.e. the home of the app), it should not present an Up +button.

      +

      The system Back key is used to navigate based on the history of screens the user has recently seen, +in reverse chronological order—in effect, the temporal relationships between screens.

      +

      When the previously viewed screen is also the hierarchical parent of the current screen, pressing +the Back key will have the same result as pressing an Up button -- this is a common occurrence. +However, unlike the Up button, which ensures the user remains within your app, the Back key can +return the user to the Home screen, or even to a different application.

      + + + +

      The Back key also supports a few behaviors not directly tied to screen-to-screen navigation:

      +
        +
      • Back dismisses floating windows (dialogs, popups)
        • +
      • Back dismisses contextual action bars, and removes the highlight from the selected items
        • +
      • Back hides the onscreen keyboard (IME)
        • +
      +

      Navigation Within Your App

      + +

      Navigating to screens with multiple entry points

      +

      Sometimes a screen doesn't have a strict position within the app's hierarchy, and can be reached +from multiple entry points—e.g., a settings screen which can be navigated to from any screen +in your app. In this case, the Up button should choose to return to the referring screen, behaving +identically to Back.

      +

      Changing view within a screen

      +

      Changing view options for a screen does not change the behavior of Up or Back: the screen is still +in the same place within the app's hierarchy, and no new navigation history is created.

      +

      Examples of such view changes are:

      +
        +
      • Switching views using tabs and/or left-and-right swipes
        • +
      • Switching views using a dropdown (aka collapsed tabs)
        • +
      • Filtering a list
        • +
      • Sorting a list
        • +
      • Changing display characteristics (e.g. zooming)
        • +
      +

      Navigating between sibling screens

      +

      When your app supports navigation from a list of items to a detail view of one of those items, it's +often desirable to support direction navigation from that item to another one which precedes or +follows it in the list. For example, in Gmail, it's easy to swipe left or right from a conversation +to view a newer or older one in the same Inbox. Just as when changing view within a screen, such +navigation does not change the behavior of Up or Back.

      + + + +

      However, a notable exception to this occurs when browsing between "related" detail views not tied +together by the referring list—for example, when browsing on Google Play between apps from +the same developer, or albums by the same artist. In these cases, following each link does create +history, causing the Back button to step through each screen of related content which has been +viewed. Up should continue to bypass these related screens and navigate to the most recently viewed +container screen.

      + + + +

      You have the ability to make the Up behavior even smarter based on your knowledge of detail +view. If we extend our Google Play sample from above, imagine the user has navigated from the last Book +viewed to the details for the Movie adaptation. In that case, Up can return to a container (Movies) +which the user had not previously navigated through.

      + + + +

      Navigation From Outside Your App

      + +

      There are two categories of navigation from outside your app to screens deep within the app's +hierarchy:

      +
        +
      • App-to-app navigation, such as via intent completion.
        • +
      • System-to-app navigation, such as via notifications and home screen widgets.
        • +
      +

      Gmail provides examples of each of these. For app-to-app navigation, a "Share" intent goes directly +to the compose screen. For system-to-app navigation, both a new message notification and a home +screen widget can bypass the Inbox screen, taking the user directly to a conversation view.

      +

      App-to-app navigation

      +

      When navigating deep into your app's hierarchy directly from another app via an intent, Back will +return to the referring app.

      +

      The Up button is handled as follows: +- If the destination screen is typically reached from one particular screen within your app, Up + should navigate to that screen. +- Otherwise, Up should navigate to the topmost ("Home") screen of your app.

      +

      For example, after choosing to share a book being viewed on Google Play, the user navigates directly to +Gmail's compose screen. From there, Up returns to the Inbox (which happens to be both the +typical referrer to compose, as well as the topmost screen of the app), while Back returns to +Google Play.

      + + + +

      System-to-app navigation

      +

      If your app was reached via the system mechanisms of notifications or home screen widgets, Up +behaves as described for app-to-app navigation, above.

      +

      For the Back key, you should make navigation more predictably by inserting into the task's back +stack the complete upward navigation path to the app's topmost screen. This way, a user who has +forgotten how they entered your app can safely navigate to the app's topmost screen before exiting +it.

      +

      For example, Gmail's Home screen widget has a button for diving directly to its compose screen. +After following that path, the Back key first returns to the Inbox, and from there continues to +Home.

      + + diff --git a/docs/html/design/patterns/new-4-0.html b/docs/html/design/patterns/new-4-0.html deleted file mode 100644 index 2e2cbc2f2a105..0000000000000 --- a/docs/html/design/patterns/new-4-0.html +++ /dev/null @@ -1,228 +0,0 @@ - - - - - - -Android Design - New in Android 4.0 - - - - - - - - - -
      - -
      Android Design
      - -
      - - - -
      - - -
      -
      -

      New in Android 4.0

      -
      -
      - Previous - Next -
      -
      - - - - -
      -
      - -

      Navigation bar

      -

      Android 4.0 removes the need for traditional hardware keys on phones by replacing them with a -virtual navigation bar that houses the Back, Home and Recents buttons. Read the -Compatibility pattern to learn how the OS adapts to -phones with hardware buttons and how pre-Android 3.0 apps that rely on menu keys are supported.

      - -
      -
      - - - -
      -
      - -
       
      - -
      -
      - -

      Action bar

      -

      The action bar is the most important structural element of an Android app. It provides consistent -navigation across the platform and allows your app to surface actions.

      - -
      -
      - - - -
      -
      - -
       
      - -
      -
      - -

      Multi-pane layouts

      -

      Creating apps that scale well across different form factors and screen sizes is important in the -Android world. Multi-pane layouts allow you to combine different activities that show separately on -smaller devices into richer compound views for tablets.

      - -
      -
      - - - -
      -
      - -
       
      - -
      -
      - -

      Selection

      -

      The long press gesture which was traditionally used to show contextual actions for objects is now -used for data selection. When selecting data, contextual action bars allow you to surface actions.

      - -
      -
      - - - -
      -
      - - - - -
      -
       
      -
      - Previous - Next -
      -
      - -
      - -
      - -
      - - - -

      - Site Terms of Service – - Privacy Policy – - Brand Guidelines -

      - -
      -
      - - - - - - - - - - diff --git a/docs/html/design/patterns/new-4-0.jd b/docs/html/design/patterns/new-4-0.jd new file mode 100644 index 0000000000000..91ebba7e9cfdb --- /dev/null +++ b/docs/html/design/patterns/new-4-0.jd @@ -0,0 +1,71 @@ +page.title=New in Android 4.0 +@jd:body + +
      +
      + +

      Navigation bar

      +

      Android 4.0 removes the need for traditional hardware keys on phones by replacing them with a +virtual navigation bar that houses the Back, Home and Recents buttons. Read the +Compatibility pattern to learn how the OS adapts to +phones with hardware buttons and how pre-Android 3.0 apps that rely on menu keys are supported.

      + +
      +
      + + + +
      +
      + +
       
      + +
      +
      + +

      Action bar

      +

      The action bar is the most important structural element of an Android app. It provides consistent +navigation across the platform and allows your app to surface actions.

      + +
      +
      + + + +
      +
      + +
       
      + +
      +
      + +

      Multi-pane layouts

      +

      Creating apps that scale well across different form factors and screen sizes is important in the +Android world. Multi-pane layouts allow you to combine different activities that show separately on +smaller devices into richer compound views for tablets.

      + +
      +
      + + + +
      +
      + +
       
      + +
      +
      + +

      Selection

      +

      The long press gesture which was traditionally used to show contextual actions for objects is now +used for data selection. When selecting data, contextual action bars allow you to surface actions.

      + +
      +
      + + + +
      +
      diff --git a/docs/html/design/patterns/notifications.html b/docs/html/design/patterns/notifications.jd similarity index 58% rename from docs/html/design/patterns/notifications.html rename to docs/html/design/patterns/notifications.jd index 99af4189ee7bf..ad88a01f11cde 100644 --- a/docs/html/design/patterns/notifications.html +++ b/docs/html/design/patterns/notifications.jd @@ -1,110 +1,5 @@ - - - - - - -Android Design - Notifications - - - - - - - - - -
      - -
      Android Design
      - -
      - - - -
      - - -
      -
      -

      Notifications

      -
      -
      - Previous - Next -
      -
      - - - +page.title=Notifications +@jd:body

      The notification system allows your app to keep the user informed about important events, such as new messages in a chat app or a calendar event.

      @@ -128,7 +23,7 @@ synchronous form of communication: there is another user actively waiting on you Calendar events are another good example of when to use a notification and grab the user's attention, because the event is imminent, and calendar events often involve other people.

      - +
       
      @@ -172,7 +67,7 @@ develop a widget that they can choose to place on their home screen.

      - +
      @@ -182,7 +77,7 @@ develop a widget that they can choose to place on their home screen.

      - +
      @@ -204,7 +99,7 @@ stacked (see Stacked notifications below) and references multiple items the user is taken to a hierarchy level below your app's top-level, insert navigation into your app's back stack to allow them to navigate to your app's top level using the system back key. For more information, see the chapter on System-to-app navigation in the -Navigation design pattern.

      +Navigation design pattern.

      Timestamps for time sensitive events

      By default, standard Android notifications include a timestamp in the upper right corner. Consider whether the timestamp is valuable in the context of your notification. If the timestamp is not @@ -222,11 +117,11 @@ an altogether new notification object. Instead, stack the notification.

      notifications of a particular kind are pending.

      Don't:

      - +

      Do:

      - +

      If you keep the summary and detail information on different screens, a stacked notification may need to open to a different place in the app than a single notification.

      @@ -252,7 +147,7 @@ hides automatically.

      - +
      @@ -278,7 +173,7 @@ currently pending.

      - +
      @@ -301,7 +196,7 @@ notification drawer is opened by touching anywhere inside the notification area.
      - +
      @@ -309,7 +204,7 @@ notification drawer is opened by touching anywhere inside the notification area.
      - +
      @@ -338,57 +233,4 @@ and toasts can echo back that an action has been successfully taken.

       
      - - - - - - -
      -
       
      -
      - Previous - Next -
      -
      - -
      - -
      - -
      - - - -

      - Site Terms of Service – - Privacy Policy – - Brand Guidelines -

      - -
      -
      - - - - - - - - - - + diff --git a/docs/html/design/patterns/pure-android.html b/docs/html/design/patterns/pure-android.html deleted file mode 100644 index f5a804266d61a..0000000000000 --- a/docs/html/design/patterns/pure-android.html +++ /dev/null @@ -1,292 +0,0 @@ - - - - - - -Android Design - Pure Android - - - - - - - - - -
      - -
      Android Design
      - -
      - - - -
      - - -
      -
      -

      Pure Android

      -
      -
      - Previous - Next -
      -
      - - - - -

      Most developers want to distribute their apps on multiple platforms. As you plan your app for -Android, keep in mind that different platforms play by different rules and conventions. Design -decisions that make perfect sense on one platform will look and feel misplaced in the context of a -different platform. While a "design once, ship anywhere" approach might save you time up-front, you -run the very real risk of creating inconsistent apps that alienate users. Consider the following -guidelines to avoid the most common traps and pitfalls.

      - -
       
      - -
      -
      - -

      Don't mimic UI elements from other platforms

      -

      Platforms typically provide a carefully designed set of UI elements that are themed in a very -distinctive fashion. For example, some platforms advocate rounded corners for their buttons, others -use gradients in their title bars. In some cases, elements may have the same purpose, but are -designed to work a bit differently.

      -

      As you build your app for Android, don't carry over themed UI elements from other platforms and -don't mimic their specific behaviors. Review the Building Blocks section in this styleguide to learn about Android's most important UI elements -and the way they look in the system default themes. Also examine Android's platform apps to get a -sense of how elements are applied in the context of an app. If you want to customize the theme of UI -elements, customize carefully according to your specific branding - and not according to the -conventions of a different platform.

      - -
      -
      - - -
      - Sampling of UI elements from Android, iOS and Windows Phone 7. -
      - -
      -
      - -
       
      - -
      -
      - -

      Don't carry over platform-specific icons

      -

      Platforms typically provide sets of icons for common functionality, such as sharing, creating a new -document or deleting.

      -

      As you are migrating your app to Android, please swap out platform-specific icons with their Android -counterparts.

      -

      You can find a wide variety of icons for use in your app in the Android SDK.

      - -
      -
      - - -
      - Sampling of icons from Android, iOS and Windows Phone 7. -
      - -
      -
      - -
       
      - -
      -
      - -

      Don't use bottom tab bars

      -

      Other platforms use the bottom tab bar to switch between the app's views. Per platform convention, -Android's tabs for view control are shown in action bars at the top of the screen instead. In -addition, Android apps may use a bottom bar to display actions on a split action bar.

      -

      You should follow this guideline to create a consistent experience with other apps on the Android -platform and to avoid confusion between actions and view switching on Android.

      -

      For more information on how to properly use action bars for view control, see -Action Bars.

      - -
      -
      - - -
      - Android dialer with tabs in an action bar vs. bottom tabs in iOS. -
      - -
      -
      - -
      -
      - -

      Don't use labeled back buttons on action bars

      -

      Other platforms use an explicit back button with label to allow the user to navigate up the -application's hierarchy. Instead, Android uses the main action bar's app icon for hierarchical -navigation and the navigation bar's back button for temporal navigation. For more information, -please review the Navigation pattern.

      -

      Follow this guideline to provide a consistent navigation experience across the platform.

      - -
      -
      - - -
      - Android action bar with up caret vs. iOS labeled "Back" button. -
      - -
      -
      - -
      -
      - -

      Don't use right-pointing carets on line items

      -

      A common pattern on other platforms is the display of right-pointing carets on line items that allow -the user to drill deeper into additional content.

      -

      Android does not use such indicators on drill-down line items. Avoid them to stay consistent with -the platform and in order to not have the user guess as to what the meaning of those carets may be.

      - -
      -
      - - -
      - Android settings without right-pointing carets in line items vs. iOS settings. -
      - -
      -
      - -

      Device Independence

      - -

      Remember that your app will run on a wide variety of different screen sizes. Create visual assets -for different screen sizes and densities and make use of concepts such as multi-pane layouts to -appropriately scale your UI on different device form factors.

      -

      For more information, read Devices and Displays as -well as Multi-pane Layouts in this design guide.

      - - - - -
      -
       
      -
      - Previous - Next -
      -
      - -
      - -
      - -
      - - - -

      - Site Terms of Service – - Privacy Policy – - Brand Guidelines -

      - -
      -
      - - - - - - - - - - diff --git a/docs/html/design/patterns/pure-android.jd b/docs/html/design/patterns/pure-android.jd new file mode 100644 index 0000000000000..8ed1347db35c5 --- /dev/null +++ b/docs/html/design/patterns/pure-android.jd @@ -0,0 +1,136 @@ +page.title=Pure Android +@jd:body + +

      Most developers want to distribute their apps on multiple platforms. As you plan your app for +Android, keep in mind that different platforms play by different rules and conventions. Design +decisions that make perfect sense on one platform will look and feel misplaced in the context of a +different platform. While a "design once, ship anywhere" approach might save you time up-front, you +run the very real risk of creating inconsistent apps that alienate users. Consider the following +guidelines to avoid the most common traps and pitfalls.

      + +
       
      + +
      +
      + +

      Don't mimic UI elements from other platforms

      +

      Platforms typically provide a carefully designed set of UI elements that are themed in a very +distinctive fashion. For example, some platforms advocate rounded corners for their buttons, others +use gradients in their title bars. In some cases, elements may have the same purpose, but are +designed to work a bit differently.

      +

      As you build your app for Android, don't carry over themed UI elements from other platforms and +don't mimic their specific behaviors. Review the +Building Blocks +section in this styleguide to learn about Android's most important UI elements +and the way they look in the system default themes. Also examine Android's platform apps to get a +sense of how elements are applied in the context of an app. If you want to customize the theme of UI +elements, customize carefully according to your specific branding - and not according to the +conventions of a different platform.

      + +
      +
      + + +
      + Sampling of UI elements from Android, iOS and Windows Phone 7. +
      + +
      +
      + +
       
      + +
      +
      + +

      Don't carry over platform-specific icons

      +

      Platforms typically provide sets of icons for common functionality, such as sharing, creating a new +document or deleting.

      +

      As you are migrating your app to Android, please swap out platform-specific icons with their Android +counterparts.

      +

      You can find a wide variety of icons for use in your app in the Android SDK.

      + +
      +
      + + +
      + Sampling of icons from Android, iOS and Windows Phone 7. +
      + +
      +
      + +
       
      + +
      +
      + +

      Don't use bottom tab bars

      +

      Other platforms use the bottom tab bar to switch between the app's views. Per platform convention, +Android's tabs for view control are shown in action bars at the top of the screen instead. In +addition, Android apps may use a bottom bar to display actions on a split action bar.

      +

      You should follow this guideline to create a consistent experience with other apps on the Android +platform and to avoid confusion between actions and view switching on Android.

      +

      For more information on how to properly use action bars for view control, see +Action Bars.

      + +
      +
      + + +
      + Android dialer with tabs in an action bar vs. bottom tabs in iOS. +
      + +
      +
      + +
      +
      + +

      Don't use labeled back buttons on action bars

      +

      Other platforms use an explicit back button with label to allow the user to navigate up the +application's hierarchy. Instead, Android uses the main action bar's app icon for hierarchical +navigation and the navigation bar's back button for temporal navigation. For more information, +please review the Navigation pattern.

      +

      Follow this guideline to provide a consistent navigation experience across the platform.

      + +
      +
      + + +
      + Android action bar with up caret vs. iOS labeled "Back" button. +
      + +
      +
      + +
      +
      + +

      Don't use right-pointing carets on line items

      +

      A common pattern on other platforms is the display of right-pointing carets on line items that allow +the user to drill deeper into additional content.

      +

      Android does not use such indicators on drill-down line items. Avoid them to stay consistent with +the platform and in order to not have the user guess as to what the meaning of those carets may be.

      + +
      +
      + + +
      + Android settings without right-pointing carets in line items vs. iOS settings. +
      + +
      +
      + +

      Device Independence

      + +

      Remember that your app will run on a wide variety of different screen sizes. Create visual assets +for different screen sizes and densities and make use of concepts such as multi-pane layouts to +appropriately scale your UI on different device form factors.

      +

      For more information, read Devices and Displays as +well as Multi-pane Layouts in this design guide.

      diff --git a/docs/html/design/patterns/selection.html b/docs/html/design/patterns/selection.html deleted file mode 100644 index 44c6a84942851..0000000000000 --- a/docs/html/design/patterns/selection.html +++ /dev/null @@ -1,257 +0,0 @@ - - - - - - -Android Design - Selection - - - - - - - - - -
      - -
      Android Design
      - -
      - - - -
      - - -
      -
      -

      Selection

      -
      -
      - Previous - Next -
      -
      - - - - -

      Android 3.0 introduced the long press gesture—that is, a touch that's held in the same -position for a moment—as the global gesture to select data. This affects the way you should -handle multi-select and contextual actions in your apps.

      - -
       
      - -
      -
      - -

      What has changed?

      -

      In previous versions of Android, the long press gesture was universally used to display contextual -actions for a given data item in a contextual menu.

      -

      This pattern changed with Android 3.0. The long press gesture is now used to select data, combining -contextual actions and selection management functions for selected data into a new element called -the contextual action bar (CAB).

      - -
      -
      - - -
      - Traditional use of the long press gesture to show contextual menus. -
      - -
      -
      - -

      Using the contextual action bar (CAB)

      -

      The selection CAB is a temporary action bar that overlays your app's current action bar while data -is selected. It appears after the user long presses on a selectable data item.

      - - - -
       
      - -
      -
      - -

      From here the user can:

      -
        -
      • Select additional data items by touching them.
        • -
      • Trigger an action from the CAB that applies to all highlighted data items. The CAB then - automatically dismisses itself.
        • -
      • Dismiss the CAB via the navigation bar's Back button or the CAB's checkmark button. This removes - the CAB along with all selection highlights.
        • -
      - -
      -
      - - - -
      -
      - -
      -
      - -

      Selecting CAB actions

      -

      You can decide which actions and elements appear in the CAB. Use the guidelines in the Action Bar -pattern to decide which items to surface at the top level and which to move to the -action overflow.

      -

      Dynamically adjust CAB actions

      -

      In most cases you need to adjust the actions in the CAB dynamically as the user adds more items to -the selection. Actions that apply to a single selected data item don't necessarily apply to multiple -selected data items of the same kind.

      - -
      -
      - - -
      - Adjusting actions in the CAB as additional items are selected. -
      - -
      -
      - -

      Checklist

      - -
        -
      • -

        Whenever your app supports the selection of multiple data items, make use of the contextual action - bar (CAB).

        -
        • -
      • -

        Reserve the long press gesture for selection exclusively. Don't use it to display traditional - contextual menus.

        -
        • -
      • -

        If you don't support multi-selection within a list, long press should do nothing.

        -
        • -
      • -

        Plan the actions you want to display inside of a CAB in the same way you would plan the actions - inside your app's action bar.

        -
        • -
      - - - - -
      -
       
      -
      - Previous - Next -
      -
      - -
      - -
      - -
      - - - -

      - Site Terms of Service – - Privacy Policy – - Brand Guidelines -

      - -
      -
      - - - - - - - - - - diff --git a/docs/html/design/patterns/selection.jd b/docs/html/design/patterns/selection.jd new file mode 100644 index 0000000000000..e3ee90ed73ad3 --- /dev/null +++ b/docs/html/design/patterns/selection.jd @@ -0,0 +1,100 @@ +page.title=Selection +@jd:body + +

      Android 3.0 introduced the long press gesture—that is, a touch that's held in the same +position for a moment—as the global gesture to select data. This affects the way you should +handle multi-select and contextual actions in your apps.

      + +
       
      + +
      +
      + +

      What has changed?

      +

      In previous versions of Android, the long press gesture was universally used to display contextual +actions for a given data item in a contextual menu.

      +

      This pattern changed with Android 3.0. The long press gesture is now used to select data, combining +contextual actions and selection management functions for selected data into a new element called +the contextual action bar (CAB).

      + +
      +
      + + +
      + Traditional use of the long press gesture to show contextual menus. +
      + +
      +
      + +

      Using the contextual action bar (CAB)

      +

      The selection CAB is a temporary action bar that overlays your app's current action bar while data +is selected. It appears after the user long presses on a selectable data item.

      + + + +
       
      + +
      +
      + +

      From here the user can:

      +
        +
      • Select additional data items by touching them.
        • +
      • Trigger an action from the CAB that applies to all highlighted data items. The CAB then + automatically dismisses itself.
        • +
      • Dismiss the CAB via the navigation bar's Back button or the CAB's checkmark button. This removes + the CAB along with all selection highlights.
        • +
      + +
      +
      + + + +
      +
      + +
      +
      + +

      Selecting CAB actions

      +

      You can decide which actions and elements appear in the CAB. Use the guidelines in the Action Bar +pattern to decide which items to surface at the top level and which to move to the +action overflow.

      +

      Dynamically adjust CAB actions

      +

      In most cases you need to adjust the actions in the CAB dynamically as the user adds more items to +the selection. Actions that apply to a single selected data item don't necessarily apply to multiple +selected data items of the same kind.

      + +
      +
      + + +
      + Adjusting actions in the CAB as additional items are selected. +
      + +
      +
      + +

      Checklist

      + +
        +
      • +

        Whenever your app supports the selection of multiple data items, make use of the contextual action + bar (CAB).

        +
        • +
      • +

        Reserve the long press gesture for selection exclusively. Don't use it to display traditional + contextual menus.

        +
        • +
      • +

        If you don't support multi-selection within a list, long press should do nothing.

        +
        • +
      • +

        Plan the actions you want to display inside of a CAB in the same way you would plan the actions + inside your app's action bar.

        +
        • +
      diff --git a/docs/html/design/patterns/swipe-views.html b/docs/html/design/patterns/swipe-views.html deleted file mode 100644 index acc9f3954859c..0000000000000 --- a/docs/html/design/patterns/swipe-views.html +++ /dev/null @@ -1,231 +0,0 @@ - - - - - - -Android Design - Swipe Views - - - - - - - - - -
      - -
      Android Design
      - -
      - - - -
      - - -
      -
      -

      Swipe Views

      -
      -
      - Previous - Next -
      -
      - - - - -

      Efficient navigation is one of the cornerstones of a well-designed app. While apps are generally -built in a hierarchical fashion, there are instances where horizontal navigation can flatten -vertical hierarchies and make access to related data items faster and more enjoyable. Swipe views -allow the user to efficiently move from item to item using a simple gesture and thereby make -browsing and consuming data a more fluent experience.

      -

      Swiping Between Detail Views

      - -

      An app's data is often organized in a master/detail relationship: The user can view a list of -related data items, such as images, chats, or emails, and then pick one of the items to see the -detail contents in a separate screen.

      - - -
      - Master (left) and detail (right) views. -
      - -

      On a phone, since the master and detail are on separate screens, this typically requires the user to -jump back and forth between the list and the detail view, aka "pogo-sticking".

      -

      In cases where users will want to view multiple detail items in succession, avoid pogo-sticking by -using the swipe gesture to navigate to the next/previous detail view.

      - - -
      - Navigating between consecutive Email messages using the swipe gesture. -
      - -

      Swiping Between Tabs

      - -
      -
      - -
      - -
      -
      - People app with swipe gesture navigation between top-level screens. -
       
      -
      - -
      -
      - -

      If your app uses action bar tabs, use swipe to navigate between the different views.

      -
       
      - -

      Checklist

      - -
        -
      • -

        Use swipe to quickly navigate between detail views or tabs.

        -
        • -
      • -

        Transition between the views as the user performs the swipe gesture. Do not wait for the - gesture to complete and then transition between views.

        -
        • -
      • -

        If you used buttons in the past for previous/next navigation, replace them with - the swipe gesture.

        -
        • -
      • -

        Consider adding contextual information in your detail view that informs the user about the - relative list position of the currently visible item.

        -
        • -
      - -
      -
      - - - - -
      -
       
      -
      - Previous - Next -
      -
      - -
      - -
      - -
      - - - -

      - Site Terms of Service – - Privacy Policy – - Brand Guidelines -

      - -
      -
      - - - - - - - - - - diff --git a/docs/html/design/patterns/swipe-views.jd b/docs/html/design/patterns/swipe-views.jd new file mode 100644 index 0000000000000..95d65ddc56c34 --- /dev/null +++ b/docs/html/design/patterns/swipe-views.jd @@ -0,0 +1,74 @@ +page.title=Swipe Views +@jd:body + +

      Efficient navigation is one of the cornerstones of a well-designed app. While apps are generally +built in a hierarchical fashion, there are instances where horizontal navigation can flatten +vertical hierarchies and make access to related data items faster and more enjoyable. Swipe views +allow the user to efficiently move from item to item using a simple gesture and thereby make +browsing and consuming data a more fluent experience.

      +

      Swiping Between Detail Views

      + +

      An app's data is often organized in a master/detail relationship: The user can view a list of +related data items, such as images, chats, or emails, and then pick one of the items to see the +detail contents in a separate screen.

      + + +
      + Master (left) and detail (right) views. +
      + +

      On a phone, since the master and detail are on separate screens, this typically requires the user to +jump back and forth between the list and the detail view, aka "pogo-sticking".

      +

      In cases where users will want to view multiple detail items in succession, avoid pogo-sticking by +using the swipe gesture to navigate to the next/previous detail view.

      + + +
      + Navigating between consecutive Email messages using the swipe gesture. +
      + +

      Swiping Between Tabs

      + +
      +
      + +
      + +
      +
      + People app with swipe gesture navigation between top-level screens. +
       
      +
      + +
      +
      + +

      If your app uses action bar tabs, use swipe to navigate between the different views.

      +
       
      + +

      Checklist

      + +
        +
      • +

        Use swipe to quickly navigate between detail views or tabs.

        +
        • +
      • +

        Transition between the views as the user performs the swipe gesture. Do not wait for the + gesture to complete and then transition between views.

        +
        • +
      • +

        If you used buttons in the past for previous/next navigation, replace them with + the swipe gesture.

        +
        • +
      • +

        Consider adding contextual information in your detail view that informs the user about the + relative list position of the currently visible item.

        +
        • +
      + +
      +
      diff --git a/docs/html/design/static/callout.png b/docs/html/design/static/callout.png deleted file mode 100644 index 5d49f34b9ca9b8748240b31acf38abd20eeca6dc..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 1383 zcmeAS@N?(olHy`uVBq!ia0vp^3P3E&!3HEx&&z8EQj#UE5hcO-X(i=}MX3yqDfvmM z3ZA)%>8U}fi7AzZCsS=07?_nZLn2Bde0{8v^Ko2Tt~skz|cV7z)0WFNY~KZ%Gk)tz(4^Clz_GsrKDK}xwt{?0`hE?GD=Dctn~HE z%ggo3jrH=2()A53EiFN27#ZmTRp=I1=9MH?=;jqG!%T2VElw`VEGWs$&r<-In3$Ab zT4JjNbScCOxdm`z^NOLt1Pn0!io^naLp=kKmtYEgeeo;J&4sHjE(uCSxEHIz#UYgi zsro^w#rdU0$-sz9QwCX8VC7ttnpl!w6q28x0}I7~jQo=P;*9(P1?ON>1>eNv%sdbu ztlrnx$}_LHBrz{J)zigR321^|W@d_&vyrp2xw(s*p|OjJp`ojxg}J4x(xwAm%KD6=dz#jPkmR{`v0t4!Q(alvUG zRBsASx45|C)TknMZjdO*x!Aefr0V1r;B4q z#jPZhd%vbUT(jLon3hJI0*JO6`U(*{l%Lno+W`22py}y0Swm_{sLXmv=wY-cD2&s8}8Qs|5LHG(C_`^ooCw@veh*HY?|WG@aiYu z(f<+-XN#7oS+WZhJI?mmBei#SZR4l^yw~qnD?Xb)iBF`MA<0%@nj@EPo{)j~6~2hi z^BV7a$b_3H{PwS%% z(~R$};_3cT_4rMF#)aB8R@)1o>aTdr(5blf;mmX9sgoBv9%~RO-@h`|GLAjwbWt7O z)c@UA=Kf;#5)OI0MnGeU#Kd1E|2@wXxiB^`Ff-gbwsaTE@=QNa(dX&v=d#Wzp$Py# Cv;?XE diff --git a/docs/html/design/static/default.css b/docs/html/design/static/default.css deleted file mode 100644 index 3aa1db3b28ae1..0000000000000 --- a/docs/html/design/static/default.css +++ /dev/null @@ -1,633 +0,0 @@ -/* color definitions */ -/* 16 column layout */ -/* clearfix idiom */ -/* common mixins */ -/* page layout + top-level styles */ -::-webkit-selection, -::-moz-selection, -::selection { - background-color: #0099cc; - color: #fff; } - -html, body { - height: 100%; - margin: 0; - padding: 0; - background: #eee none no-repeat fixed top left; - background-image: -webkit-gradient(linear, 100% 0%, 100% 100%, from(#dddddd), color-stop(25%, #f2f2f2), color-stop(75%, #f2f2f2), to(#dddddd)); - background-image: -moz-linear-gradient(top, #dddddd, #f2f2f2, #f2f2f2, #dddddd); - -webkit-font-smoothing: antialiased; - /* prevent subpixel antialiasing, which thickens the text */ - text-rendering: optimizeLegibility; - /* opentype ftw */ } - -body { - color: #555555; - font: 14px/20px Roboto, sans-serif; - font-weight: 400; } - -#page-container { - width: 940px; - margin: 0 40px; } - -#page-header { - height: 80px; - margin-bottom: 20px; - font-size: 48px; - line-height: 48px; - font-weight: 100; - padding-left: 10px; } - #page-header a { - display: block; - position: relative; - top: 20px; - text-decoration: none; - color: #555555 !important; } - -#main-row { - display: inline-block; } - #main-row:after { - content: "."; - display: block; - height: 0; - clear: both; - visibility: hidden; } - * html #main-row { - height: 1px; } - -#page-footer { - margin-left: 190px; - margin-top: 80px; - color: #999999; - padding-bottom: 40px; - font-size: 12px; - line-height: 15px; } - #page-footer a { - color: #777777; } - #page-footer #copyright { - margin-bottom: 10px; } - -#nav { - width: 160px; - margin-right: 20px; - float: left; } - -#content { - width: 760px; - float: left; } - -a, -a:visited { - color: #333333; } - -a:hover, -acronym:hover { - color: #7aa1b0 !important; } - -a:focus, -a:active { - color: #33b5e5 !important; } - -img { - border: none; } - -ul { - margin: 0; - padding: 0; } - -strong { - font-weight: 500; } - -em { - font-style: italic; } - -code { - font-family: Courier New, monospace; } - -acronym { - border-bottom: 1px dotted #555555; - cursor: help; } - -acronym:hover { - border-bottom-color: #7aa1b0; } - -img.with-shadow, -video.with-shadow { - box-shadow: 0 2px 4px rgba(0, 0, 0, 0.25); } - -/* disclosures mixin */ -/* content layout */ -.layout-content-row { - display: inline-block; - margin-bottom: 10px; } - .layout-content-row:after { - content: "."; - display: block; - height: 0; - clear: both; - visibility: hidden; } - * html .layout-content-row { - height: 1px; } - -.layout-content-col { - float: left; - margin-left: 20px; } - .layout-content-col:first-child { - margin-left: 0; } - -.layout-content-col.span-1 { - width: 40px; } - -.layout-content-col.span-2 { - width: 100px; } - -.layout-content-col.span-3 { - width: 160px; } - -.layout-content-col.span-4 { - width: 220px; } - -.layout-content-col.span-5 { - width: 280px; } - -.layout-content-col.span-6 { - width: 340px; } - -.layout-content-col.span-7 { - width: 400px; } - -.layout-content-col.span-8 { - width: 460px; } - -.layout-content-col.span-9 { - width: 520px; } - -.layout-content-col.span-10 { - width: 580px; } - -.layout-content-col.span-11 { - width: 640px; } - -.layout-content-col.span-12 { - width: 700px; } - -.layout-content-col.span-13 { - width: 760px; } - -.vspace.size-1 { - height: 10px; } - -.vspace.size-2 { - height: 20px; } - -.vspace.size-3 { - height: 30px; } - -.vspace.size-4 { - height: 40px; } - -.vspace.size-5 { - height: 50px; } - -.vspace.size-6 { - height: 60px; } - -.vspace.size-7 { - height: 70px; } - -.vspace.size-8 { - height: 80px; } - -.vspace.size-9 { - height: 90px; } - -.vspace.size-10 { - height: 100px; } - -.vspace.size-11 { - height: 110px; } - -.vspace.size-12 { - height: 120px; } - -.vspace.size-13 { - height: 130px; } - -.vspace.size-14 { - height: 140px; } - -.vspace.size-15 { - height: 150px; } - -.vspace.size-16 { - height: 160px; } - -/* nav */ -#nav { - /* section header divs */ - /* expanded section header divs */ - /* sublinks */ } - #nav li { - list-style-type: none; - font-size: 14px; - line-height: 10px; } - #nav a { - color: #555555; - text-decoration: none; } - #nav li.selected > a, - #nav li.selected .nav-section-header a { - font-weight: 500; - color: #0099cc !important; } - #nav .nav-section-header { - position: relative; - padding: 10px; - margin-bottom: 1px; - /* section header links */ } - #nav .nav-section-header a { - color: #333333; - font-weight: 500; - text-transform: uppercase; } - #nav .nav-section-header:after { - content: ''; - background: transparent url(disclosure_down.png) no-repeat scroll top left; - width: 10px; - height: 10px; - display: block; - position: absolute; - top: 10px; - right: 10px; } - #nav .nav-section-header.empty:after { - display: none; } - #nav li.expanded .nav-section-header { - background: rgba(0, 0, 0, 0.05); } - #nav li.expanded .nav-section-header:after { - content: ''; - background: transparent url(disclosure_up.png) no-repeat scroll top left; - width: 10px; - height: 10px; } - #nav > li > ul { - height: 0; - overflow: hidden; - margin-bottom: 0; } - #nav > li > ul.animate-height { - -webkit-transition: height 0.25s ease-in; - -moz-transition: height 0.25s ease-in; - transition: height 0.25s ease-in; } - #nav > li > ul li { - padding: 10px 10px 11px 10px; } - #nav > li.expanded > ul { - height: auto; } - #nav > li.expanded > ul li { - background: rgba(0, 0, 0, 0.03); } - #nav #back-dac-section { - padding: 10px; - border-top: 1px solid #ddd; } - #nav #back-dac-section a { - color: #333333; - font-weight: 500; - text-transform: uppercase; } - -/* content header */ -.content-header { - border-bottom: 1px solid #33b5e5; - height: 30px; } - .content-header h2 { - border-bottom: 0; } - .content-header.just-links { - border-bottom: 0; } - -.content-footer { - border-top: 1px solid #33b5e5; - margin-top: 10px; - height: 30px; } - -.paging-links { - position: relative; } - .paging-links a { - position: absolute; - font-size: 14px; - line-height: 30px; - color: #555555; - text-decoration: none; - text-transform: uppercase; } - .paging-links .prev-page-link { - display: none; - left: -5px; } - .paging-links .prev-page-link:before { - content: ''; - background: transparent url(disclosure_left.png) no-repeat scroll top left; - width: 10px; - height: 10px; - display: inline-block; - margin-right: 5px; } - .paging-links .next-page-link { - display: none; - right: 10px; } - .paging-links .next-page-link:after { - content: ''; - background: transparent url(disclosure_right.png) no-repeat scroll top left; - width: 10px; - height: 10px; - display: inline-block; - margin-left: 5px; } - -/* content body */ -@-webkit-keyframes glowheader { - from { - background-color: #33b5e5; - color: #000; - border-bottom-color: #000; } - - to { - background-color: transparent; - color: #33b5e5; - border-bottom-color: #33b5e5; } } - -@-moz-keyframes glowheader { - from { - background-color: #33b5e5; - color: #000; - border-bottom-color: #000; } - - to { - background-color: transparent; - color: #33b5e5; - border-bottom-color: #33b5e5; } } - -@keyframes glowheader { - from { - background-color: #33b5e5; - color: #000; - border-bottom-color: #000; } - - to { - background-color: transparent; - color: #33b5e5; - border-bottom-color: #33b5e5; } } - -#content p, -#content ul, -#content ol, -#content h3 { - margin: 0 10px 10px 10px; } -#content h2 { - padding-left: 10px; - padding-right: 10px; - margin-bottom: 10px; - font-size: 16px; - line-height: 30px; - font-weight: 500; - color: #33b5e5; - border-bottom: 1px solid #33b5e5; - height: 30px; } - #content h2:target { - -webkit-animation-name: glowheader; - -moz-animation-name: glowheader; - animation-name: glowheader; - -webkit-animation-duration: 0.7s; - -moz-animation-duration: 0.7s; - animation-duration: 0.7s; - -webkit-animation-timing-function: ease-out; - -moz-animation-timing-function: ease-out; - animation-timing-function: ease-out; } -#content hr { - border: 0; - border-bottom: 1px solid #33b5e5; - margin-bottom: 20px; } -#content h3 { - color: #33b5e5; - text-transform: uppercase; - font-size: 14px; - line-height: 20px; - font-weight: 500; } -#content h4 { - margin: 0 10px; - color: #333333; - font-weight: 500; - font-size: 14px; - line-height: 20px; } -#content strong { - color: #333333; } -#content ul li, -#content ol li { - margin-left: 20px; } - #content ul li h4, - #content ol li h4 { - margin: 0; } - #content ul li p, - #content ol li p { - margin-left: 0; } -#content ul li { - list-style-type: square; - list-style-type: none; - position: relative; } - #content ul li:before { - content: '\2022'; - font-family: verdana; - font-size: 14px; - line-height: 20px; - position: absolute; - left: -20px; - top: -1px; } -#content ol { - counter-reset: item; } - #content ol li { - font-size: 14px; - line-height: 20px; - list-style-type: none; - position: relative; } - #content ol li:before { - content: counter(item) ". "; - counter-increment: item; - position: absolute; - left: -20px; - top: 0; } - #content ol li.value-1:before { - content: "1. "; } - #content ol li.value-2:before { - content: "2. "; } - #content ol li.value-3:before { - content: "3. "; } - #content ol li.value-4:before { - content: "4. "; } - #content ol li.value-5:before { - content: "5. "; } - #content ol li.value-6:before { - content: "6. "; } - #content ol li.value-7:before { - content: "7. "; } - #content ol li.value-8:before { - content: "8. "; } - #content ol li.value-9:before { - content: "9. "; } - #content ol li.value-10:before { - content: "10. "; } -#content .with-callouts ol li { - list-style-position: inside; - margin-left: 0; } - #content .with-callouts ol li:before { - position: static; - display: inline; - left: 0; - float: left; - width: 17px; - color: #33b5e5; - font-weight: 500; } - -/* special list items */ -li.no-bullet { - list-style-type: none !important; } - -#content li.with-icon { - position: relative; - margin-left: 40px; - min-height: 30px; } - #content li.with-icon p { - margin-left: 0 !important; } - #content li.with-icon:before { - position: absolute; - left: -40px; - top: 0; - content: ''; - width: 30px; - height: 30px; } - #content li.with-icon.tablet:before { - background-image: url(ico_phone_tablet.png); } - #content li.with-icon.web:before { - background-image: url(ico_web.png); } - #content li.with-icon.checklist:before { - background-image: url(ico_checklist.png); } - #content li.with-icon.action:before { - background-image: url(ico_action.png); } - #content li.with-icon.use:before { - background-image: url(ico_use.png); } - -/* figures and callouts */ -.figure { - position: relative; } - .figure.pad-below { - margin-bottom: 20px; } - .figure .figure-callout { - position: absolute; - color: #fff; - font-weight: 500; - font-size: 16px; - line-height: 23px; - text-align: center; - background: transparent url(callout.png) no-repeat scroll 50% 50%; - padding-right: 2px; - width: 30px; - height: 29px; - z-index: 1000; } - .figure .figure-callout.top { - top: -9px; } - .figure .figure-callout.right { - right: -5px; } - -.figure-caption { - margin: 0 10px 20px 10px; - font-size: 14px; - line-height: 20px; - font-style: italic; } - -/* rows of figures */ -.figure-row { - font-size: 0; - line-height: 0; - /* to prevent space between figures */ } - .figure-row .figure { - display: inline-block; - vertical-align: top; } - .figure-row .figure + .figure { - margin-left: 10px; - /* reintroduce space between figures */ } - -/* video containers */ -.framed-galaxynexus-land-span-13 { - background: transparent url(content/misc_full_galaxynexus_blank_land_span13.png) no-repeat scroll top left; - padding: 42px 122px 62px 126px; - overflow: hidden; } - .framed-galaxynexus-land-span-13, .framed-galaxynexus-land-span-13 video, .framed-galaxynexus-land-span-13 img { - width: 512px; - height: 286px; } - -.framed-galaxynexus-port-span-9 { - background: transparent url(content/misc_full_galaxynexus_blank_port_span9.png) no-repeat scroll top left; - padding: 95px 122px 107px 124px; - overflow: hidden; } - .framed-galaxynexus-port-span-9, .framed-galaxynexus-port-span-9 video, .framed-galaxynexus-port-span-9 img { - width: 274px; - height: 488px; } - -.framed-galaxynexus-port-span-5 { - background: transparent url(content/misc_full_galaxynexus_blank_port_span5.png) no-repeat scroll top left; - padding: 75px 31px 76px 33px; - overflow: hidden; } - .framed-galaxynexus-port-span-5, .framed-galaxynexus-port-span-5 video, .framed-galaxynexus-port-span-5 img { - width: 216px; - height: 384px; } - -/* landing page disclosures */ -.landing-page-link { - text-decoration: none; - font-weight: 500; - color: #333333; } - .landing-page-link:after { - content: ''; - background: transparent url(disclosure_right.png) no-repeat scroll top left; - width: 10px; - height: 10px; - display: inline-block; - margin-left: 5px; } - -/* tooltips */ -.tooltip-box { - position: absolute; - background-color: rgba(0, 0, 0, 0.9); - border-radius: 2px; - font-size: 14px; - line-height: 20px; - color: #fff; - padding: 6px 10px; - max-width: 250px; - z-index: 10000; } - .tooltip-box.below:after { - position: absolute; - content: ''; - line-height: 0; - display: block; - top: -10px; - left: 5px; - border: 5px solid transparent; - border-bottom-color: rgba(0, 0, 0, 0.9); } - -/* video note */ -.video-instructions { - margin-top: 10px; - margin-bottom: 10px; } - .video-instructions:before { - content: ''; - background: transparent url(ico_movie_inline.png) no-repeat scroll top left; - display: inline-block; - width: 12px; - height: 12px; - margin-right: 8px; } - .video-instructions:after { - content: 'Click to replay movie.'; } - -/* download buttons */ -.download-button { - display: block; - margin-bottom: 5px; - text-decoration: none; - background-color: #33b5e5; - color: #fff !important; - font-weight: 500; - box-shadow: 0 1px 1px rgba(0, 0, 0, 0.12); - padding: 6px 12px; - border-radius: 2px; } - .download-button:hover, .download-button:focus { - background-color: #0099cc; - color: #fff !important; } - .download-button:active { - background-color: #006699; } diff --git a/docs/html/design/static/default.js b/docs/html/design/static/default.js deleted file mode 100644 index b213dd92b7668..0000000000000 --- a/docs/html/design/static/default.js +++ /dev/null @@ -1,169 +0,0 @@ -$(document).ready(function() { - // prep nav expandos - var pagePath = document.location.pathname; - if (pagePath.indexOf(SITE_ROOT) == 0) { - pagePath = pagePath.substr(SITE_ROOT.length); - if (pagePath == '' || pagePath.charAt(pagePath.length - 1) == '/') { - pagePath += 'index.html'; - } - } - - if (SITE_ROOT.match(/\.\.\//) || SITE_ROOT == '') { - // If running locally, SITE_ROOT will be a relative path, so account for that by - // finding the relative URL to this page. This will allow us to find links on the page - // leading back to this page. - var pathParts = pagePath.split('/'); - var relativePagePathParts = []; - var upDirs = (SITE_ROOT.match(/(\.\.\/)+/) || [''])[0].length / 3; - for (var i = 0; i < upDirs; i++) { - relativePagePathParts.push('..'); - } - for (var i = 0; i < upDirs; i++) { - relativePagePathParts.push(pathParts[pathParts.length - (upDirs - i) - 1]); - } - relativePagePathParts.push(pathParts[pathParts.length - 1]); - pagePath = relativePagePathParts.join('/'); - } else { - // Otherwise the page path should be an absolute URL. - pagePath = SITE_ROOT + pagePath; - } - - // select current page in sidenav and set up prev/next links if they exist - var $selNavLink = $('#nav').find('a[href="' + pagePath + '"]'); - if ($selNavLink.length) { - $selListItem = $selNavLink.closest('li'); - - $selListItem.addClass('selected'); - $selListItem.closest('li.nav-section').addClass('expanded'); - - // set up prev links - var $prevLink = []; - var $prevListItem = $selListItem.prev('li'); - if ($prevListItem.length) { - if ($prevListItem.hasClass('nav-section')) { - // jump to last topic of previous section - $prevLink = $prevListItem.find('a:last'); - } else { - // jump to previous topic in this section - $prevLink = $prevListItem.find('a:eq(0)'); - } - } else { - // jump to this section's index page (if it exists) - $prevLink = $selListItem.parents('li').find('a'); - } - - if ($prevLink.length) { - var prevHref = $prevLink.attr('href'); - if (prevHref == SITE_ROOT + 'index.html') { - // Don't show Previous when it leads to the homepage - $('.prev-page-link').hide(); - } else { - $('.prev-page-link').attr('href', prevHref).show(); - } - } else { - $('.prev-page-link').hide(); - } - - // set up next links - var $nextLink = []; - if ($selListItem.hasClass('nav-section')) { - // we're on an index page, jump to the first topic - $nextLink = $selListItem.find('ul').find('a:eq(0)') - } else { - // jump to the next topic in this section (if it exists) - $nextLink = $selListItem.next('li').find('a:eq(0)'); - if (!$nextLink.length) { - // no more topics in this section, jump to the first topic in the next section - $nextLink = $selListItem.parents('li').next('li.nav-section').find('a:eq(0)'); - } - } - if ($nextLink.length) { - $('.next-page-link').attr('href', $nextLink.attr('href')).show(); - } else { - $('.next-page-link').hide(); - } - } - - // Set up expand/collapse behavior - $('#nav li.nav-section').click(function() { - if ($(this).hasClass('expanded')) { - return; - } - - // hide other - var $old = $('#nav li.nav-section.expanded'); - if ($old.length) { - var $oldUl = $old.children('ul'); - $oldUl.css('height', $oldUl.height() + 'px'); - window.setTimeout(function() { - $oldUl - .addClass('animate-height') - .css('height', ''); - }, 0); - $old.removeClass('expanded'); - } - - // show me - $(this).addClass('expanded'); - var $ul = $(this).children('ul'); - var expandedHeight = $ul.height(); - $ul - .removeClass('animate-height') - .css('height', 0); - window.setTimeout(function() { - $ul - .addClass('animate-height') - .css('height', expandedHeight + 'px'); - }, 0); - }); - - // Stop expand/collapse behavior when clicking on nav section links (since we're navigating away - // from the page) - $('.nav-section-header').find('a:eq(0)').click(function(evt) { - window.location.href = $(this).attr('href'); - return false; - }); - - // Set up play-on-hover
    -

    Notice the xlarge qualifier in the directory name of the second layout. This layout -will be selected on devices with screens classified as extra-large (for example, 10" tablets). The +

    Notice the large qualifier in the directory name of the second layout. This layout +will be selected on devices with screens classified as large (for example, 7" tablets and above). The other layout (without qualifiers) will be selected for smaller devices.

    @@ -188,7 +188,7 @@ though they are all considered to be "large" screens. That's why Android introdu width given in dp. For example, the typical 7" tablet has a minimum width of 600 dp, so if you want your UI to have two panes on those screens (but a single list on smaller screens), you can use the same two layouts from the previous section for single -and two-pane layouts, but instead of the xlarge size qualifier, use +and two-pane layouts, but instead of the large size qualifier, use sw600dp to indicate the two-pane layout is for screens on which the smallest-width is 600 dp:

    @@ -209,9 +209,9 @@ while smaller screens will select the layout/main.xml (single-pane) layout.

    However, this won't work well on pre-3.2 devices, because they don't -recognize sw600dp as a size qualifier, so you still have to use the xlarge +recognize sw600dp as a size qualifier, so you still have to use the large qualifier as well. So, you should have a file named -res/layout-xlarge/main.xml +res/layout-large/main.xml which is identical to res/layout-sw600dp/main.xml. In the next section you'll see a technique that allows you to avoid duplicating the layout files this way.

    @@ -222,20 +222,20 @@ you'll see a technique that allows you to avoid duplicating the layout files thi Therefore, you should also still use the abstract size bins (small, normal, large and xlarge) to be compatible with earlier versions. For example, if you want to design your UI so that it shows a single-pane UI on phones but a -multi-pane UI on 7" tablets and larger devices, you'd have to supply these +multi-pane UI on 7" tablets, TVs and other large devices, you'd have to supply these files:

    • res/layout/main.xml: single-pane layout
      • -
    • res/layout-xlarge: multi-pane layout
      • +
    • res/layout-large: multi-pane layout
    • res/layout-sw600dp: multi-pane layout

    The last two files are identical, because one of them will be matched by -Android 3.2 devices, and the other one is for the benefit of tablets with +Android 3.2 devices, and the other one is for the benefit of tablets and TVs with earlier versions of Android.

    -

    To avoid this duplication of the same file for tablets (and the maintenance +

    To avoid this duplication of the same file for tablets and TVs (and the maintenance headache resulting from it), you can use alias files. For example, you can define the following layouts:

    @@ -247,7 +247,7 @@ layouts:

    And add these two files:

      -
    • res/values-xlarge/layout.xml: +
    • res/values-large/layout.xml: 
       <resources>
     <item name="main" type="layout">@layout/main_twopanes</item>
@@ -267,9 +267,9 @@ layouts:
      
 
 
      These latter two files have identical content, but they don’t actually define
 the layout. They merely set up {@code main} to be an alias to {@code main_twopanes}. Since
-these files have xlarge and sw600dp selectors, they are
-applied to tablets regardless of Android version (pre-3.2 tablets match
-{@code xlarge}, and post-3.2 will match sw600dp).
      
+these files have large and sw600dp selectors, they are
+applied to tablets and TVs regardless of Android version (pre-3.2 tablets and TVs match
+{@code large}, and post-3.2 will match sw600dp).
      
 
 
 
      Use Orientation Qualifiers
       
@@ -285,6 +285,7 @@ behaves in each screen size and orientation:
      
 
    • 7" tablet, landscape: dual pane, wide, with action bar
      • 
 
    • 10" tablet, portrait: dual pane, narrow, with action bar
      • 
 
    • 10" tablet, landscape: dual pane, wide, with action bar
      • 
+
    • TV, landscape: dual pane, wide, with action bar
      •

    So each of these layouts is defined in an XML file in the @@ -319,11 +320,11 @@ all} {@sample development/samples/training/multiscreen/newsreader/res/values-sw600dp-port/layouts.xml all} -

    res/values-xlarge-land/layouts.xml:

    -{@sample development/samples/training/multiscreen/newsreader/res/values-xlarge-land/layouts.xml all} +

    res/values-large-land/layouts.xml:

    +{@sample development/samples/training/multiscreen/newsreader/res/values-large-land/layouts.xml all} -

    res/values-xlarge-port/layouts.xml:

    -{@sample development/samples/training/multiscreen/newsreader/res/values-xlarge-port/layouts.xml all} +

    res/values-large-port/layouts.xml:

    +{@sample development/samples/training/multiscreen/newsreader/res/values-large-port/layouts.xml all}