am b7d1f69a: am 84668136: Merge "delete obsolete duplicate files" into jb-mr1.1-ub-dev

page.title=Preparing for Release

@jd:body

<div id="qv-wrapper">

  <div id="qv">

    <h2>Quickview</h2>

    <ul>

      <li>Learn which resources you'll need to release your app.</li>

      <li>Find out how to configure and build your app for release.</li>

      <li>Learn best practices for releasing your app.</li>

    </ul>

    <h2>In this document</h2>

    <ol>

      <li><a href="#publishing-intro">Introduction</a></li>

      <li><a href="#publishing-gather">Gathering Materials and Resources</a></li>

      <li><a href="#publishing-configure">Configuring Your Application</a></li>

      <li><a href="#publishing-build">Building Your Application</a></li>

      <li><a href="#publishing-resources">Preparing External Servers and Resources</a></li>

      <li><a href="#publishing-test">Testing Your Application for Release</a></li>

    </ol>

    <h2>See also</h2>

    <ol>

      <li><a href="{@docRoot}tools/publishing/publishing_overview.html">Publishing Overview</a></li>

      <li><a href="{@docRoot}tools/publishing/app-signing.html">Signing Your Applications</a></li>

      <li><a href="{@docRoot}tools/publishing/publishing.html">Publishing on Google Play</a></li>

    </ol>

  </div>

</div>

<p>Before you distribute your Android application to users you need to prepare it for release. The

preparation process is a required <a href="{@docRoot}tools/workflow/index.html">development

task</a> for all Android applications and is the first step in the publishing process (see figure

1).</p>

<p>When you prepare your application for release, you configure, build, and test a release

version of your application. The configuration tasks are straightforward, involving basic code

cleanup and code modification tasks that help optimize your application. The build process is

similar to the debug build process and can be done using JDK and Android SDK tools. The testing

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

<code>.apk</code> file, which you can distribute directly to users or distribute through an

application marketplace such as Google Play.</p>

<p>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 Google

Play, you should also read <a href="{@docRoot}tools/publishing/publishing.html">Publishing on

Google Play</a> to be sure your release-ready application satisfies all Google Play

requirements.</p>

<p class="note"><strong>Note:</strong> As a best practice, your application should meet all of your

release criteria for functionality, performance, and stability before you perform the tasks outlined

in this document.</p>

<img src="{@docRoot}images/publishing/publishing_overview_prep.png"

     alt="Shows how the preparation process fits into the development process"

     height="190"

     id="figure1" />

<p class="img-caption">

  <strong>Figure 1.</strong> Preparing for release is a required <a

href="{@docRoot}tools/workflow/index.html">development

task</a> and is the first step in the publishing process.

</p>

<h2 id="publishing-intro">Introduction</h2>

<p>To release your application to users you need to create a release-ready package that users can

install and run on their Android-powered devices. The release-ready package contains the same

components as the debug <code>.apk</code> file &mdash; compiled source code, resources, manifest

file, and so on — and it is built using the same build tools. However, unlike the debug

<code>.apk</code> file, the release-ready <code>.apk</code> file is signed with your own certificate

and it is optimized with the zipalign tool.</p>

<div class="figure" style="width:331px">

  <img src="{@docRoot}images/publishing/publishing_preparing.png"

       alt="Shows the five tasks you perform to prepare your app for release"

       height="450" />

  <p class="img-caption">

    <strong>Figure 2.</strong> You perform five main tasks to prepare your application for

    release.

  </p>

</div>

<p>The signing and optimization tasks are usually seamless if you are building your application with

Eclipse and the ADT plugin or with the Ant build script (included with the Android SDK). For

example, you can use the Eclipse Export Wizard to compile, sign, and optimize your application all

at once. You can also configure the Ant build script to do the same when you build from the command

line.</p>

<p>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 Google Play you may want

to add special filtering rules to your manifest while you are configuring your application for

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.</p>

<p>You usually perform the tasks listed in figure 2 after you have throroughly debugged and tested

your application. The Android SDK contains several tools to help you test and debug your Android

applications. For more information, see the <a

href="{@docRoot}tools/debugging/index.html">Debugging</a> and <a

href="{@docRoot}tools/testing/index.html">Testing</a> sections in the Dev Guide.</p>

<h2 id="publishing-gather">Gathering Materials and Resources</h2>

<p>To begin preparing your application for release you need to gather several supporting items. At a

minimum this includes cryptographic keys for signing your application and an application icon. You

might also want to include an end-user license agreement.</p>

<h4 id="publishing-keys">Cryptographic keys</h4>

<p>The Android system requires that each installed application be digitally signed with a

certificate that is owned by the application's developer (that is, a certificate for which the

developer holds the private key). The Android system uses the certificate as a means of identifying

the author of an application and establishing trust relationships between applications. The

certificate that you use for signing does not need to be signed by a certificate authority; the

Android system allows you to sign your applications with a self-signed certificate. To learn about

certificate requirements, see <a href="{@docRoot}tools/publishing/app-signing.html#cert">Obtain a

suitable private key</a>.</p>

<p class="caution"><strong>Important:</strong> Your application must be signed with a cryptographic

key whose validity period ends after 22 October 2033.</p>

<p>You may also have to obtain other release keys if your application accesses a service or uses a

third-party library that requires you to use a key that is based on your private key. For example,

if your application uses the <a

href="http://code.google.com/android/add-ons/google-apis/reference/com/google/android/maps/MapView.html">MapView</a>

class, which is part of the <a

href="http://code.google.com/android/add-ons/google-apis/maps-overview.html">Google Maps external

library</a>, you will need to register your application with the Google Maps service and obtain

a Maps API key. For information about getting a Maps API key, see <a

href="http://code.google.com/android/add-ons/google-apis/mapkey.html"> Obtaining a Maps API

key</a>.</p>

<h4>Application Icon</h4>

<p>Be sure you have an application icon and that it meets the recommended <a

href="{@docRoot}guide/practices/ui_guidelines/icon_design_launcher.html">icon guidelines</a>. 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 Google Play display your icon to users.</p>

<p class="note"><strong>Note:</strong> If you are releasing your application on Google Play, you

need to create a high resolution

  version of your icon. See <a

href="https://www.google.com/support/androidmarket/developer/bin/answer.py?answer=1078870">Graphic

Assets for your Application</a> for more information.</p>

<h4>End-user License Agreement</h4>

<p>Consider preparing an End User License Agreement (EULA) for your application. A EULA can help

protect your person, organization, and intellectual property, and we recommend that you provide one

with your application.</p>

<h4>Miscellaneous Materials</h4>

<p>You might also have to prepare promotional and marketing materials to publicize your application.

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

<a href="https://www.google.com/support/androidmarket/developer/bin/answer.py?answer=1078870">

Graphic Assets for your Application</a></p>

<h2 id="publishing-configure">Configuring Your Application for Release</h2>

<p>After you gather all of your supporting materials you can start configuring your application

for release. This section provides a summary of the configuration changes we recommend that you make

to your source code, resource files, and application manifest prior to releasing your application.

Although most of the configuration changes listed in this section are optional, they are

considered good coding practices and we encourage you to implement them. In some cases,

you may have already made these configuration changes as part of your development process.</p>

<h4>Choose a good package name</h4>

<p>Make sure you choose a package name that is suitable over the life of your application. You

cannot change the package name after you distribute your application to users. You can set the

package name in application's manifest file. For more information, see the <a

href="{@docRoot}guide/topics/manifest/manifest-element.html#package">package</a> attribute

documentation.</p>

<h4>Turn off logging and debugging</h4>

<p>Make sure you deactivate logging and disable the debugging option before you build your

application for release. You can deactivate logging by removing calls to

{@link android.util.Log} methods in your source files. You can disable debugging by removing the

<code>android:debuggable</code> attribute from the <code>&lt;application&gt;</code> tag in your

manifest file, or by setting the <code>android:debuggable</code> attribute to

<code>false</code> in your manifest file. Also, remove any log files or static test files that

were created in your project.</p>

<p>Also, you should remove all {@link android.os.Debug} tracing calls that you

added to your code, such as {@link android.os.Debug#startMethodTracing()} and

{@link android.os.Debug#stopMethodTracing()} method calls.</p>

<h4>Clean up your project directories</h4>

<p>Clean up your project and make sure it conforms to the directory structure described in <a

href="{@docRoot}tools/projects/index.html#ApplicationProjects">Android Projects</a>.

Leaving stray or orphaned files in your project can prevent your application from compiling and

cause your application to behave unpredictably. At a minimum you should do the following cleanup

tasks:</p>

<ul>

  <li>Review the contents of your <code>jni/</code>, <code>lib/</code>, and <code>src/</code>

  directories.  The <code>jni/</code> directory should contain only source files associated with the

  <a href="{@docRoot}tools/sdk/ndk/index.html">Android NDK</a>, such as

  <code>.c</code>, <code>.cpp</code>, <code>.h</code>, and <code>.mk</code> files. The

  <code>lib/</code> directory should contain only third-party library files or private library

  files, including prebuilt shared and static libraries (for example, <code>.so</code> files). The

  <code>src/</code> directory should contain only the source files for your application

  (<code>.java</code> and <code>.aidl</code> files). The <code>src/</code> directory should not

  contain any <code>.jar</code> files.</li>

  <li>Check your project for private or proprietary data files that your application does not use

  and remove them. For example, look in your project's <code>res/</code> directory for old

  drawable files, layout files, and values files that you are no longer using and delete them.</li>

  <li>Check your <code>lib/</code> directory for test libraries and remove them if they are no

  longer being used by your application.</li>

  <li>Review the contents of your <code>assets/</code> directory and your <code>res/raw/</code>

    directory for raw asset files and static files that you need to update or remove prior to

    release.</li>

</ul>

<h4>Review and update your manifest settings</h4>

<p>Verify that the following manifest items are set correctly:</p>

<ul>

  <li><a href="{@docRoot}guide/topics/manifest/uses-permission-element.html">

  &lt;uses-permission&gt;</a> element

    <p>You should specify only those permissions that are relevant and required for your application.</p>

  </li>

  <li><code>android:icon</code> and <code>android:label</code> attributes

    <p>You must specify values for these attributes, which are located in the

    <a href="{@docRoot}guide/topics/manifest/application-element.html">&lt;application&gt;</a>

    element.</p>

  </li>

  <li><code>android:versionCode</code> and <code>android:versionName</code> attributes.

    <p>We recommend that you specify values for these attributes, which are located in the

      <a href="{@docRoot}guide/topics/manifest/manifest-element.html">&lt;manifest&gt;</a>

      element. For more information see

      <a href="{@docRoot}tools/publishing/versioning.html">Versioning your Application</a>.</p>

  </li>

</ul>

<p>There are several additional manifest elements that you can set if you are releasing your

application on Google Play. For example, the <code>android:minSdkVersion</code> and

<code>android:targetSdkVersion</code> attributes, which are located in the <a

href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"> &lt;uses-sdk&gt;</a> element. For more

information about these and other Google Play settings, see <a

href="{@docRoot}/guide//appendix/market-filters.html">Filters on Google Play</a>.</p>

<h4>Address compatibility issues</h4>

<p>Android provides several tools and techniques to make your application compatible with a wide

range of devices. To make your application available to the largest number of users, consider

doing the following:</p>

<ul>

  <li><strong>Add support for multiple screen configurations</strong>

    <p>Make sure you meet the

    <a href="{@docRoot}guide/practices/screens_support.html#screen-independence">

    best practices for supporting multiple screens</a>. By supporting multiple screen configurations

    you can create an application that functions properly and looks good on any of the screen sizes

    supported by Android.</p>

  </li>

  <li><strong>Optimize your application for Android 3.0 devices.</strong>

    <p>If your application is designed for devices older than Android 3.0, make it compatible

    with Android 3.0 devices by following the guidelines and best practices described in

    <a href="{@docRoot}guide/practices/optimizing-for-3.0.html">Optimizing Apps for Android 3.0

    </a>.</p>

  </li>

  <li><strong>Consider using the Support Library</strong>

    <p>If your application is designed for devices running Android 3.x, make your application

    compatible with older versions of Android by adding the

    <a href="{@docRoot}tools/extras/support-library.html">Support Library</a> to your

    application project. The Support Library provides static support libraries that you can add to

    your Android application, which enables you to use APIs that are either not available on

    older platform versions or use utility APIs that are not part of the framework APIs.</p>

  </li>

</ul>

<h4>Update URLs for servers and services</h4>

<p>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.</p>

<h4>Implement Licensing (if you are releasing on Google Play)</h4>

<p>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.</p>

<p>For more information about Google Play Licensing Service and how to use it in your

application, see <a href="{@docRoot}google/play/licensing/index.html">Application Licensing</a>.</p>

<h2 id="publishing-build">Building Your Application for Release</h2>

<p>After you finish configuring your application you can build it into a release-ready

<code>.apk</code> fle that is signed and optimized. The JDK includes the tools for signing the

<code>.apk</code> file (Keytool and Jarsigner); the Android SDK includes the tools for compiling and

optimizing the <code>.apk</code> file. If you are using Eclipse with the ADT plugin or you are using

the Ant build script from the command line, you can automate the entire build process.</p>

<h3>Building with Eclipse</h3>

<p>You can use the Eclipse Export Wizard to build a release-ready <code>.apk</code> file that is

signed with your private key and optimized. To learn how to run the Export Wizard, see

<a href="{@docRoot}tools/publishing/app-signing.html#ExportWizard">Compile and sign with Eclipse

ADT</a>. The Export Wizard compiles your application for release, signs your application with your

private key, and optimizes your application with the zipalign tool. The Export Wizard should run

successfully if you have run or debugged your application from Eclipse and you have no errors in

your application (see <a href="{@docRoot}tools/building/building-eclipse.html">Building

and Running from Eclipse with ADT</a> for more information.</p>

<p>The Export Wizard assumes that you have a <a href="#billing-keys">certificate and private key</a>

suitable for signing your application. If you do not have a suitable certificate and private key,

the Export Wizard will help you generate one (see

<a href="{@docRoot}tools/publishing/app-signing.html">Signing Your Applications</a> for more

information about the signing process and signing guidelines.</p>

<h3>Building with Ant</h3>

<p>You can use the Ant build script (included in the Android SDK) to build a release-ready

<code>.apk</code> file that is signed with your private key and optimized. To learn how to do this,

see <a href="{@docRoot}tools/building/building-cmdline.html#ReleaseMode">Building in

Release Mode</a>. This build method assumes you have a <a href="#billing-keys">certificate and

private key</a> suitable for signing your application. If you do not have a suitable certificate and

private key, the Export Wizard will help you generate one (see

<a href="{@docRoot}tools/publishing/app-signing.html">Signing Your Applications</a> for more

information about the signing process and signing guidelines.</p>

<h2 id="publishing-resources">Preparing External Servers and Resources</h2>

<p>If your application relies on a remote server, make sure the server is secure and that it is

configured for production use. This is particularly important if you are implementing <a

href="{@docRoot}google/play/billing/index.html">in-app billing</a> in your application and you are

performing the signature verification step on a remote server.</p>

<p>Also, if your application fetches content from a remote server or a real-time service (such as a

content feed), be sure the content you are providing is up to date and production-ready.</p>

<h2 id="publishing-test">Testing Your Application for Release</h2>

<p>Testing the release version of your application helps ensure that your application runs properly

under realistic device and network conditions. Ideally, you should test your application on at least

one handset-sized device and one tablet-sized device to verify that your user interface elements are

sized correctly and that your application's performance and battery efficiency are acceptable.</p>

<p>As a starting point for testing, see

<a href="{@docRoot}tools/testing/what_to_test.html">What to Test</a>. This article provides

a summary of common Android situations that you should consider when you are testing. When you are

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

<a href="{@docRoot}tools/publishing/publishing_overview.html#publishing-release">Releasing Your

Application to Users</a>. If you are publishing your application on Google Play, see

<a href="{@docRoot}tools/publishing/publishing.html">Publishing on Google Play</a>.</p>