1 page.title=Preparing for Release 2 @jd:body 3 4 <div id="qv-wrapper"> 5 <div id="qv"> 6 <h2>Quickview</h2> 7 <ul> 8 <li>Learn which resources you'll need to release your app.</li> 9 <li>Find out how to configure and build your app for release.</li> 10 <li>Learn best practices for releasing your app.</li> 11 </ul> 12 <h2>In this document</h2> 13 <ol> 14 <li><a href="#publishing-intro">Introduction</a></li> 15 <li><a href="#publishing-gather">Gathering Materials and Resources</a></li> 16 <li><a href="#publishing-configure">Configuring Your Application</a></li> 17 <li><a href="#publishing-build">Building Your Application</a></li> 18 <li><a href="#publishing-resources">Preparing External Servers and Resources</a></li> 19 <li><a href="#publishing-test">Testing Your Application for Release</a></li> 20 </ol> 21 <h2>See also</h2> 22 <ol> 23 <li><a href="{@docRoot}tools/publishing/publishing_overview.html">Publishing Overview</a></li> 24 <li><a href="{@docRoot}tools/publishing/app-signing.html">Signing Your Applications</a></li> 25 <li><a href="{@docRoot}distribute/googleplay/publish/preparing.html">Launch Checklist for Google Play</a></li> 26 </ol> 27 </div> 28 </div> 29 30 <p>Before you distribute your Android application to users you need to prepare it for release. The 31 preparation process is a required <a href="{@docRoot}tools/workflow/index.html">development 32 task</a> for all Android applications and is the first step in the publishing process (see figure 33 1).</p> 34 35 <p>When you prepare your application for release, you configure, build, and test a release 36 version of your application. The configuration tasks are straightforward, involving basic code 37 cleanup and code modification tasks that help optimize your application. The build process is 38 similar to the debug build process and can be done using JDK and Android SDK tools. The testing 39 tasks serve as a final check, ensuring that your application performs as expected under real-world 40 conditions. When you are finished preparing your application for release you have a signed 41 <code>.apk</code> file, which you can distribute directly to users or distribute through an 42 application marketplace such as Google Play.</p> 43 44 <p>This document summarizes the main tasks you need to perform to prepare your application for 45 release. The tasks that are described in this document apply to all Android applications regardless 46 how they are released or distributed to users. If you are releasing your application through Google 47 Play, you should also read <a href="{@docRoot}distribute/googleplay/publish/preparing.html">Publishing 48 Checklist for Google Play</a> to be sure your release-ready application satisfies all Google Play 49 requirements.</p> 50 51 <p class="note"><strong>Note:</strong> As a best practice, your application should meet all of your 52 release criteria for functionality, performance, and stability before you perform the tasks outlined 53 in this document.</p> 54 55 <img src="{@docRoot}images/publishing/publishing_overview_prep.png" 56 alt="Shows how the preparation process fits into the development process" 57 height="190" 58 id="figure1" /> 59 <p class="img-caption"> 60 <strong>Figure 1.</strong> Preparing for release is a required <a 61 href="{@docRoot}tools/workflow/index.html">development 62 task</a> and is the first step in the publishing process. 63 </p> 64 65 <h2 id="publishing-intro">Introduction</h2> 66 67 <p>To release your application to users you need to create a release-ready package that users can 68 install and run on their Android-powered devices. The release-ready package contains the same 69 components as the debug <code>.apk</code> file — compiled source code, resources, manifest 70 file, and so on — and it is built using the same build tools. However, unlike the debug 71 <code>.apk</code> file, the release-ready <code>.apk</code> file is signed with your own certificate 72 and it is optimized with the zipalign tool.</p> 73 74 <div class="figure" style="width:331px"> 75 <img src="{@docRoot}images/publishing/publishing_preparing.png" 76 alt="Shows the five tasks you perform to prepare your app for release" 77 height="450" /> 78 <p class="img-caption"> 79 <strong>Figure 2.</strong> You perform five main tasks to prepare your application for 80 release. 81 </p> 82 </div> 83 84 <p>The signing and optimization tasks are usually seamless if you are building your application with 85 Eclipse and the ADT plugin or with the Ant build script (included with the Android SDK). For 86 example, you can use the Eclipse Export Wizard to compile, sign, and optimize your application all 87 at once. You can also configure the Ant build script to do the same when you build from the command 88 line.</p> 89 90 <p>To prepare your application for release you typically perform five main tasks (see figure 2). 91 Each main task may include one or more smaller tasks depending on how you are releasing your 92 application. For example, if you are releasing your application through Google Play you may want 93 to add special filtering rules to your manifest while you are configuring your application for 94 release. Similarly, to meet Google Play publishing guidelines you may have to prepare screenshots 95 and create promotional text while you are gathering materials for release.</p> 96 97 <p>You usually perform the tasks listed in figure 2 after you have throroughly debugged and tested 98 your application. The Android SDK contains several tools to help you test and debug your Android 99 applications. For more information, see the <a 100 href="{@docRoot}tools/debugging/index.html">Debugging</a> and <a 101 href="{@docRoot}tools/testing/index.html">Testing</a> sections in the Dev Guide.</p> 102 103 <h2 id="publishing-gather">Gathering Materials and Resources</h2> 104 105 <p>To begin preparing your application for release you need to gather several supporting items. At a 106 minimum this includes cryptographic keys for signing your application and an application icon. You 107 might also want to include an end-user license agreement.</p> 108 109 <h4 id="publishing-keys">Cryptographic keys</h4> 110 111 <p>The Android system requires that each installed application be digitally signed with a 112 certificate that is owned by the application's developer (that is, a certificate for which the 113 developer holds the private key). The Android system uses the certificate as a means of identifying 114 the author of an application and establishing trust relationships between applications. The 115 certificate that you use for signing does not need to be signed by a certificate authority; the 116 Android system allows you to sign your applications with a self-signed certificate. To learn about 117 certificate requirements, see <a href="{@docRoot}tools/publishing/app-signing.html#cert">Obtain a 118 suitable private key</a>.</p> 119 120 <p class="caution"><strong>Important:</strong> Your application must be signed with a cryptographic 121 key whose validity period ends after 22 October 2033.</p> 122 123 <p>You may also have to obtain other release keys if your application accesses a service or uses a 124 third-party library that requires you to use a key that is based on your private key. For example, 125 if your application uses the <a 126 href="http://code.google.com/android/add-ons/google-apis/reference/com/google/android/maps/MapView.html">MapView</a> 127 class, which is part of the <a 128 href="http://code.google.com/android/add-ons/google-apis/maps-overview.html">Google Maps external 129 library</a>, you will need to register your application with the Google Maps service and obtain 130 a Maps API key. For information about getting a Maps API key, see <a 131 href="http://code.google.com/android/add-ons/google-apis/mapkey.html"> Obtaining a Maps API 132 key</a>.</p> 133 134 <h4>Application Icon</h4> 135 136 <p>Be sure you have an application icon and that it meets the recommended <a 137 href="{@docRoot}guide/practices/ui_guidelines/icon_design_launcher.html">icon guidelines</a>. Your 138 application's icon helps users identify your application on a device's Home 139 screen and in the Launcher window. It also appears in Manage Applications, My Downloads, and 140 elsewhere. In addition, publishing services such as Google Play display your icon to users.</p> 141 142 <p class="note"><strong>Note:</strong> If you are releasing your application on Google Play, you 143 need to create a high resolution 144 version of your icon. See <a 145 href="https://www.google.com/support/androidmarket/developer/bin/answer.py?answer=1078870">Graphic 146 Assets for your Application</a> for more information.</p> 147 148 <h4>End-user License Agreement</h4> 149 150 <p>Consider preparing an End User License Agreement (EULA) for your application. A EULA can help 151 protect your person, organization, and intellectual property, and we recommend that you provide one 152 with your application.</p> 153 154 <h4>Miscellaneous Materials</h4> 155 156 <p>You might also have to prepare promotional and marketing materials to publicize your application. 157 For example, if you are releasing your application on Google Play you will need to prepare some 158 promotional text and you will need to create screenshots of your application. For more 159 information, see 160 <a href="https://www.google.com/support/androidmarket/developer/bin/answer.py?answer=1078870"> 161 Graphic Assets for your Application</a></p> 162 163 <h2 id="publishing-configure">Configuring Your Application for Release</h2> 164 165 <p>After you gather all of your supporting materials you can start configuring your application 166 for release. This section provides a summary of the configuration changes we recommend that you make 167 to your source code, resource files, and application manifest prior to releasing your application. 168 Although most of the configuration changes listed in this section are optional, they are 169 considered good coding practices and we encourage you to implement them. In some cases, 170 you may have already made these configuration changes as part of your development process.</p> 171 172 <h4>Choose a good package name</h4> 173 174 <p>Make sure you choose a package name that is suitable over the life of your application. You 175 cannot change the package name after you distribute your application to users. You can set the 176 package name in application's manifest file. For more information, see the <a 177 href="{@docRoot}guide/topics/manifest/manifest-element.html#package">package</a> attribute 178 documentation.</p> 179 180 <h4>Turn off logging and debugging</h4> 181 182 <p>Make sure you deactivate logging and disable the debugging option before you build your 183 application for release. You can deactivate logging by removing calls to 184 {@link android.util.Log} methods in your source files. You can disable debugging by removing the 185 <code>android:debuggable</code> attribute from the <code><application></code> tag in your 186 manifest file, or by setting the <code>android:debuggable</code> attribute to 187 <code>false</code> in your manifest file. Also, remove any log files or static test files that 188 were created in your project.</p> 189 190 <p>Also, you should remove all {@link android.os.Debug} tracing calls that you 191 added to your code, such as {@link android.os.Debug#startMethodTracing()} and 192 {@link android.os.Debug#stopMethodTracing()} method calls.</p> 193 194 <h4>Clean up your project directories</h4> 195 196 <p>Clean up your project and make sure it conforms to the directory structure described in <a 197 href="{@docRoot}tools/projects/index.html#ApplicationProjects">Android Projects</a>. 198 Leaving stray or orphaned files in your project can prevent your application from compiling and 199 cause your application to behave unpredictably. At a minimum you should do the following cleanup 200 tasks:</p> 201 202 <ul> 203 <li>Review the contents of your <code>jni/</code>, <code>lib/</code>, and <code>src/</code> 204 directories. The <code>jni/</code> directory should contain only source files associated with the 205 <a href="{@docRoot}tools/sdk/ndk/index.html">Android NDK</a>, such as 206 <code>.c</code>, <code>.cpp</code>, <code>.h</code>, and <code>.mk</code> files. The 207 <code>lib/</code> directory should contain only third-party library files or private library 208 files, including prebuilt shared and static libraries (for example, <code>.so</code> files). The 209 <code>src/</code> directory should contain only the source files for your application 210 (<code>.java</code> and <code>.aidl</code> files). The <code>src/</code> directory should not 211 contain any <code>.jar</code> files.</li> 212 <li>Check your project for private or proprietary data files that your application does not use 213 and remove them. For example, look in your project's <code>res/</code> directory for old 214 drawable files, layout files, and values files that you are no longer using and delete them.</li> 215 <li>Check your <code>lib/</code> directory for test libraries and remove them if they are no 216 longer being used by your application.</li> 217 <li>Review the contents of your <code>assets/</code> directory and your <code>res/raw/</code> 218 directory for raw asset files and static files that you need to update or remove prior to 219 release.</li> 220 </ul> 221 222 <h4>Review and update your manifest settings</h4> 223 224 <p>Verify that the following manifest items are set correctly:</p> 225 226 <ul> 227 <li><a href="{@docRoot}guide/topics/manifest/uses-permission-element.html"> 228 <uses-permission></a> element 229 <p>You should specify only those permissions that are relevant and required for your application.</p> 230 </li> 231 <li><code>android:icon</code> and <code>android:label</code> attributes 232 <p>You must specify values for these attributes, which are located in the 233 <a href="{@docRoot}guide/topics/manifest/application-element.html"><application></a> 234 element.</p> 235 </li> 236 <li><code>android:versionCode</code> and <code>android:versionName</code> attributes. 237 <p>We recommend that you specify values for these attributes, which are located in the 238 <a href="{@docRoot}guide/topics/manifest/manifest-element.html"><manifest></a> 239 element. For more information see 240 <a href="{@docRoot}tools/publishing/versioning.html">Versioning your Application</a>.</p> 241 </li> 242 </ul> 243 244 <p>There are several additional manifest elements that you can set if you are releasing your 245 application on Google Play. For example, the <code>android:minSdkVersion</code> and 246 <code>android:targetSdkVersion</code> attributes, which are located in the <a 247 href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"> <uses-sdk></a> element. For more 248 information about these and other Google Play settings, see <a 249 href="{@docRoot}google/play/filters.html">Filters on Google Play</a>.</p> 250 251 <h4>Address compatibility issues</h4> 252 253 <p>Android provides several tools and techniques to make your application compatible with a wide 254 range of devices. To make your application available to the largest number of users, consider 255 doing the following:</p> 256 257 <ul> 258 <li><strong>Add support for multiple screen configurations</strong> 259 <p>Make sure you meet the 260 <a href="{@docRoot}guide/practices/screens_support.html#screen-independence"> 261 best practices for supporting multiple screens</a>. By supporting multiple screen configurations 262 you can create an application that functions properly and looks good on any of the screen sizes 263 supported by Android.</p> 264 </li> 265 <li><strong>Optimize your application for Android tablet devices.</strong> 266 <p>If your application is designed for devices older than Android 3.0, make it compatible 267 with Android 3.0 devices by following the guidelines and best practices described in 268 <a href="{@docRoot}guide/practices/optimizing-for-3.0.html">Optimizing Apps for Android 3.0 269 </a>.</p> 270 </li> 271 <li><strong>Consider using the Support Library</strong> 272 <p>If your application is designed for devices running Android 3.x, make your application 273 compatible with older versions of Android by adding the 274 <a href="{@docRoot}tools/extras/support-library.html">Support Library</a> to your 275 application project. The Support Library provides static support libraries that you can add to 276 your Android application, which enables you to use APIs that are either not available on 277 older platform versions or use utility APIs that are not part of the framework APIs.</p> 278 </li> 279 </ul> 280 281 <h4>Update URLs for servers and services</h4> 282 283 <p>If your application accesses remote servers or services, make sure you are using the production 284 URL or path for the server or service and not a test URL or path.</p> 285 286 <h4>Implement Licensing (if you are releasing on Google Play)</h4> 287 288 <p>If you are releasing a paid application through Google Play, consider adding support for 289 Google Play Licensing. Licensing lets you control access to your application based on whether the 290 current user has purchased it. Using Google Play Licensing is optional even if you are 291 releasing your app through Google Play.</p> 292 293 <p>For more information about Google Play Licensing Service and how to use it in your 294 application, see <a href="{@docRoot}google/play/licensing/index.html">Application Licensing</a>.</p> 295 296 <h2 id="publishing-build">Building Your Application for Release</h2> 297 298 <p>After you finish configuring your application you can build it into a release-ready 299 <code>.apk</code> fle that is signed and optimized. The JDK includes the tools for signing the 300 <code>.apk</code> file (Keytool and Jarsigner); the Android SDK includes the tools for compiling and 301 optimizing the <code>.apk</code> file. If you are using Eclipse with the ADT plugin or you are using 302 the Ant build script from the command line, you can automate the entire build process.</p> 303 304 <h3>Building with Eclipse</h3> 305 306 <p>You can use the Eclipse Export Wizard to build a release-ready <code>.apk</code> file that is 307 signed with your private key and optimized. To learn how to run the Export Wizard, see 308 <a href="{@docRoot}tools/publishing/app-signing.html#ExportWizard">Compile and sign with Eclipse 309 ADT</a>. The Export Wizard compiles your application for release, signs your application with your 310 private key, and optimizes your application with the zipalign tool. The Export Wizard should run 311 successfully if you have run or debugged your application from Eclipse and you have no errors in 312 your application (see <a href="{@docRoot}tools/building/building-eclipse.html">Building 313 and Running from Eclipse with ADT</a> for more information.</p> 314 315 <p>The Export Wizard assumes that you have a <a href="#billing-keys">certificate and private key</a> 316 suitable for signing your application. If you do not have a suitable certificate and private key, 317 the Export Wizard will help you generate one (see 318 <a href="{@docRoot}tools/publishing/app-signing.html">Signing Your Applications</a> for more 319 information about the signing process and signing guidelines.</p> 320 321 <h3>Building with Ant</h3> 322 323 <p>You can use the Ant build script (included in the Android SDK) to build a release-ready 324 <code>.apk</code> file that is signed with your private key and optimized. To learn how to do this, 325 see <a href="{@docRoot}tools/building/building-cmdline.html#ReleaseMode">Building in 326 Release Mode</a>. This build method assumes you have a <a href="#billing-keys">certificate and 327 private key</a> suitable for signing your application. If you do not have a suitable certificate and 328 private key, the Export Wizard will help you generate one (see 329 <a href="{@docRoot}tools/publishing/app-signing.html">Signing Your Applications</a> for more 330 information about the signing process and signing guidelines.</p> 331 332 <h2 id="publishing-resources">Preparing External Servers and Resources</h2> 333 334 <p>If your application relies on a remote server, make sure the server is secure and that it is 335 configured for production use. This is particularly important if you are implementing <a 336 href="{@docRoot}google/play/billing/index.html">in-app billing</a> in your application and you are 337 performing the signature verification step on a remote server.</p> 338 339 <p>Also, if your application fetches content from a remote server or a real-time service (such as a 340 content feed), be sure the content you are providing is up to date and production-ready.</p> 341 342 <h2 id="publishing-test">Testing Your Application for Release</h2> 343 344 <p>Testing the release version of your application helps ensure that your application runs properly 345 under realistic device and network conditions. Ideally, you should test your application on at least 346 one handset-sized device and one tablet-sized device to verify that your user interface elements are 347 sized correctly and that your application's performance and battery efficiency are acceptable.</p> 348 349 <p>As a starting point for testing, see 350 <a href="{@docRoot}tools/testing/what_to_test.html">What to Test</a>. This article provides 351 a summary of common Android situations that you should consider when you are testing. When you are 352 done testing and you are satisfied that the release version of your application 353 behaves correctly, you can release your application to users. For more information, see 354 <a href="{@docRoot}tools/publishing/publishing_overview.html#publishing-release">Releasing Your 355 Application to Users</a>. If you are publishing your application on Google Play, see 356 <a href="{@docRoot}distribute/googleplay/publish/preparing.html">Launch Checklist 357 for Google Play</a>.</p> 358 359 360