diff options
| author | Scott Main <smain@google.com> | 2012-06-21 17:14:39 -0700 |
|---|---|---|
| committer | Scott Main <smain@google.com> | 2012-06-21 21:27:30 -0700 |
| commit | 50e990c64fa23ce94efa76b9e72df7f8ec3cee6a (patch) | |
| tree | 52605cd25e01763596477956963fabcd087054b0 /docs/html/guide/publishing | |
| parent | a2860267cad115659018d636bf9203a644c680a7 (diff) | |
| download | frameworks_base-50e990c64fa23ce94efa76b9e72df7f8ec3cee6a.zip frameworks_base-50e990c64fa23ce94efa76b9e72df7f8ec3cee6a.tar.gz frameworks_base-50e990c64fa23ce94efa76b9e72df7f8ec3cee6a.tar.bz2 | |
Massive clobber of all HTML files in developer docs for new site design
Change-Id: Idc55a0b368c1d2c1e7d4999601b739dd57f08eb3
Diffstat (limited to 'docs/html/guide/publishing')
| -rw-r--r-- | docs/html/guide/publishing/app-signing.jd | 618 | ||||
| -rw-r--r-- | docs/html/guide/publishing/licensing.html | 11 | ||||
| -rw-r--r-- | docs/html/guide/publishing/preparing.jd | 358 | ||||
| -rw-r--r-- | docs/html/guide/publishing/publishing.jd | 703 | ||||
| -rwxr-xr-x | docs/html/guide/publishing/publishing_overview.jd | 231 | ||||
| -rw-r--r-- | docs/html/guide/publishing/versioning.jd | 174 |
6 files changed, 0 insertions, 2095 deletions
diff --git a/docs/html/guide/publishing/app-signing.jd b/docs/html/guide/publishing/app-signing.jd deleted file mode 100644 index 5bd9be55..0000000 --- a/docs/html/guide/publishing/app-signing.jd +++ /dev/null @@ -1,618 +0,0 @@ -page.title=Signing Your Applications -@jd:body - -<div id="qv-wrapper"> -<div id="qv"> - -<h2>Quickview</h2> - -<ul> -<li>All Android apps <em>must</em> be signed</li> -<li>You can sign with a self-signed key</li> -<li>How you sign your apps is critical — read this document carefully</li> -<li>Determine your signing strategy early in the development process</li> -</ul> - -<h2>In this document</h2> - -<ol> -<li><a href="#signing">Signing Process</a></li> -<li><a href="#strategies">Signing Strategies</a></li> -<li><a href="#setup">Basic Setup for Signing</a></li> -<li><a href="#debugmode">Signing in Debug Mode</a></li> -<li><a href="#releasemode">Signing Release Mode</a> - <ol> - <li><a href="#cert">Obtain a suitable private key</a></li> - <li><a href="#releasecompile">Compile the application in release mode</a></li> - <li><a href="#signapp">Sign your application with your private key</a></li> - <li><a href="#align">Align the final APK package</a></li> - <li><a href="#ExportWizard">Compile and sign with Eclipse ADT</a></li> - </ol> -</li> -<li><a href="#secure-key">Securing Your Private Key</a></li> - -</ol> - -<h2>See also</h2> - -<ol> -<li><a href="{@docRoot}guide/publishing/versioning.html">Versioning Your Applications</a></li> -<li><a href="{@docRoot}guide/publishing/preparing.html">Preparing to Publish</a></li> -</ol> - -</div> -</div> - -<p>The Android system requires that all installed applications be digitally signed with a -certificate whose private key is held by the application's developer. The Android system uses the -certificate as a means of identifying the author of an application and establishing trust -relationships between applications. The certificate is not used to control which applications the -user can install. The certificate does not need to be signed by a certificate authority: it is -perfectly allowable, and typical, for Android applications to use self-signed certificates.</p> - -<p>The important points to understand about signing Android applications are:</p> - -<ul> - <li>All applications <em>must</em> be signed. The system will not install an application -on an emulator or a device if it is not signed.</li> - <li>To test and debug your application, the build tools sign your application with a special debug - key that is created by the Android SDK build tools.</li> - <li>When you are ready to release your application for end-users, you must sign it with a suitable - private key. You cannot publish an application that is signed with the debug key generated - by the SDK tools.</li> - <li>You can use self-signed certificates to sign your applications. No certificate authority is - needed.</li> - <li>The system tests a signer certificate's expiration date only at install time. If an -application's signer certificate expires after the application is installed, the application -will continue to function normally.</li> - <li>You can use standard tools — Keytool and Jarsigner — to generate keys and -sign your application {@code .apk} files.</li> - <li>After you sign your application for release, we recommend that you use the - <code>zipalign</code> tool to optimize the final APK package.</li> -</ul> - -<p>The Android system will not install or run an application that is not signed appropriately. This -applies wherever the Android system is run, whether on an actual device or on the emulator. -For this reason, you must <a href="#setup">set up signing</a> for your application before you can -run it or debug it on an emulator or device.</p> - -<h2 id="signing">Signing Process</h3> - -<p>The Android build process signs your application differently depending on which build mode you -use to build your application. There are two build modes: <em>debug mode</em> and <em>release -mode</em>. 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 Google Play.</p> - -<p>When you build in <em>debug mode</em> 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, -they know the debug key's alias and password. Each time you compile your application in debug mode, -the build tools use the debug key along with the Jarsigner utility (also included in the JDK) to -sign your application's <code>.apk</code> file. Because the alias and password are known to the SDK -build tools, the tools don't need to prompt you for the debug key's alias and password each time -you compile.</p> - -<p>When you build in <em>release mode</em> you use your own private key to sign your application. If -you don't have a private key, you can use the Keytool utility to create one for you. When you -compile your application in release mode, the build tools use your private key along with the -Jarsigner utility to sign your application's <code>.apk</code> file. Because the certificate and -private key you use are your own, you will have to provide the password for the keystore and key -alias.</p> - -<p>The debug signing process happens automatically when you run or debug your application using -Eclipse with the ADT plugin. Debug signing also happens automatically when you use the Ant build -script with the <code>debug</code> option. You can automate the release signing process by using the -Eclipse Export Wizard or by modifying the Ant build script and building with the -<code>release</code> option.</p> - -<h2 id="strategies">Signing Strategies</h2> - -<p>Some aspects of application signing may affect how you approach the development -of your application, especially if you are planning to release multiple -applications. </p> - -<p>In general, the recommended strategy for all developers is to sign -all of your applications with the same certificate, throughout the expected -lifespan of your applications. There are several reasons why you should do so: </p> - -<ul> -<li>Application upgrade – As you release updates to your application, you -will want to continue to sign the updates with the same certificate or set of -certificates, if you want users to upgrade seamlessly to the new version. When -the system is installing an update to an application, it compares the -certificate(s) in the new version with those in the existing version. If the -certificates match exactly, including both the certificate data and order, then -the system allows the update. If you sign the new version without using matching -certificates, you will also need to assign a different package name to the -application — in this case, the user installs the new version as a -completely new application. </li> - -<li>Application modularity – The Android system allows applications that -are signed by the same certificate to run in the same process, if the -applications so requests, so that the system treats them as a single application. -In this way you can deploy your application in modules, and users can update -each of the modules independently if needed.</li> - -<li>Code/data sharing through permissions – The Android system provides -signature-based permissions enforcement, so that an application can expose -functionality to another application that is signed with a specified -certificate. By signing multiple applications with the same certificate and -using signature-based permissions checks, your applications can share code and -data in a secure manner. </li> - -</ul> - -<p>Another important consideration in determining your signing strategy is -how to set the validity period of the key that you will use to sign your -applications.</p> - -<ul> -<li>If you plan to support upgrades for a single application, you should ensure -that your key has a validity period that exceeds the expected lifespan of -that application. A validity period of 25 years or more is recommended. -When your key's validity period expires, users will no longer be -able to seamlessly upgrade to new versions of your application.</li> - -<li>If you will sign multiple distinct applications with the same key, -you should ensure that your key's validity period exceeds the expected -lifespan of <em>all versions of all of the applications</em>, including -dependent applications that may be added to the suite in the future. </li> - -<li>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. Google Play enforces this requirement -to ensure that users can seamlessly upgrade applications when -new versions are available. </li> -</ul> - -<p>As you design your application, keep these points in mind and make sure to -use a <a href="#cert">suitable certificate</a> to sign your applications. </p> - -<h2 id="setup">Basic Setup for Signing</h2> - -<p>Before you begin, make sure that the Keytool utility and Jarsigner utility are available to -the SDK build tools. Both of these tools are available in the JDK. In most cases, you can tell -the SDK build tools how to find these utilities by setting your <code>JAVA_HOME</code> environment -variable so it references a suitable JDK. Alternatively, you can add the JDK version of Keytool and -Jarsigner to your <code>PATH</code> variable.</p> - -<p>If you are developing on a version of Linux that originally came with GNU Compiler for -Java, make sure that the system is using the JDK version of Keytool, rather than the gcj -version. If Keytool is already in your <code>PATH</code>, it might be pointing to a symlink at -<code>/usr/bin/keytool</code>. In this case, check the symlink target to be sure it points -to the Keytool in the JDK.</p> - -<h2 id="debugmode">Signing in Debug Mode</h2> - -<p>The Android build tools provide a debug signing mode that makes it easier for you -to develop and debug your application, while still meeting the Android system -requirement for signing your APK. -When using debug mode to build your app, the SDK tools invoke Keytool to automatically create -a debug keystore and key. This debug key is then used to automatically sign the APK, so -you do not need to sign the package with your own key.</p> - -<p>The SDK tools create the debug keystore/key with predetermined names/passwords:</p> -<ul> -<li>Keystore name: "debug.keystore"</li> -<li>Keystore password: "android"</li> -<li>Key alias: "androiddebugkey"</li> -<li>Key password: "android"</li> -<li>CN: "CN=Android Debug,O=Android,C=US"</li> -</ul> - -<p>If necessary, you can change the location/name of the debug keystore/key or -supply a custom debug keystore/key to use. However, any custom debug -keystore/key must use the same keystore/key names and passwords as the default -debug key (as described above). (To do so in Eclipse/ADT, go to -<strong>Windows</strong> > <strong>Preferences</strong> > -<strong>Android</strong> > <strong>Build</strong>.) </p> - -<p class="caution"><strong>Caution:</strong> You <em>cannot</em> release your application -to the public when signed with the debug certificate.</p> - -<h3>Eclipse Users</h3> - -<p>If you are developing in Eclipse/ADT (and have set up Keytool and Jarsigner as described above in -<a href="#setup">Basic Setup for Signing</a>), -signing in debug mode is enabled by default. When you run or debug your -application, ADT signs the {@code .apk} file with the debug certificate, runs {@code zipalign} on -the package, then installs it on -the selected emulator or connected device. No specific action on your part is needed, -provided ADT has access to Keytool.</p> - -<h3>Ant Users</h3> - -<p>If you are using Ant to build your {@code .apk} file, debug signing mode -is enabled by using the <code>debug</code> option with the <code>ant</code> command -(assuming that you are using a <code>build.xml</code> file generated by the -<code>android</code> tool). When you run <code>ant debug</code> to -compile your app, the build script generates a keystore/key and signs the APK for you. -The script then also aligns the APK with the <code>zipalign</code> tool. -No other action on your part is needed. Read -<a href="{@docRoot}guide/developing/building/building-cmdline.html#DebugMode">Building and Running Apps -on the Command Line</a> for more information.</p> - - -<h3 id="debugexpiry">Expiry of the Debug Certificate</h3> - -<p>The self-signed certificate used to sign your application in debug mode (the default on -Eclipse/ADT and Ant builds) will have an expiration date of 365 days from its creation date.</p> - -<p>When the certificate expires, you will get a build error. On Ant builds, the error -looks like this:</p> - -<pre>debug: -[echo] Packaging bin/samples-debug.apk, and signing it with a debug key... -[exec] Debug Certificate expired on 8/4/08 3:43 PM</pre> - -<p>In Eclipse/ADT, you will see a similar error in the Android console.</p> - -<p>To fix this problem, simply delete the <code>debug.keystore</code> file. -The default storage location for AVDs is in <code>~/.android/</code> on OS X and Linux, -in <code>C:\Documents and Settings\<user>\.android\</code> on Windows XP, and in -<code>C:\Users\<user>\.android\</code> on Windows Vista and Windows 7.</p> - - -<p>The next time you build, the build tools will regenerate a new keystore and debug key.</p> - -<p>Note that, if your development machine is using a non-Gregorian locale, the build -tools may erroneously generate an already-expired debug certificate, so that you get an -error when trying to compile your application. For workaround information, see the -troubleshooting topic <a href="{@docRoot}resources/faq/troubleshooting.html#signingcalendar"> -I can't compile my app because the build tools generated an expired debug -certificate</a>. </p> - - -<h2 id="releasemode">Signing in Release Mode</h2> - -<p>When your application is ready for release to other users, you must:</p> -<ol> - <li><a href="#cert">Obtain a suitable private key</a></li> - <li><a href="#releasecompile">Compile the application in release mode</a></li> - <li><a href="#signapp">Sign your application with your private key</a></li> - <li><a href="#align">Align the final APK package</a></li> -</ol> - -<p>If you are developing in Eclipse with the ADT plugin, you can use the Export Wizard -to perform the compile, sign, and align procedures. The Export Wizard even allows you to -generate a new keystore and private key in the process. So if you use Eclipse, you can -skip to <a href="#ExportWizard">Compile and sign with Eclipse ADT</a>.</p> - - - -<h3 id="cert">1. Obtain a suitable private key</h3> - -<p>In preparation for signing your application, you must first ensure that -you have a suitable private key with which to sign. A suitable private -key is one that:</p> - -<ul> -<li>Is in your possession</li> -<li>Represents the personal, corporate, or organizational entity to be identified -with the application</li> -<li>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. -<p>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. -</p></li> -<li>Is not the debug key generated by the Android SDK tools. </li> -</ul> - -<p>The key may be self-signed. If you do not have a suitable key, you must -generate one using Keytool. Make sure that you have Keytool available, as described -in <a href="#setup">Basic Setup</a>.</p> - -<p>To generate a self-signed key with Keytool, use the <code>keytool</code> -command and pass any of the options listed below (and any others, as -needed). </p> - -<p class="warning"><strong>Warning:</strong> Keep your private key secure. -Before you run Keytool, make sure to read -<a href="#secure-key">Securing Your Private Key</a> for a discussion of how to keep -your key secure and why doing so is critically important to you and to users. In -particular, when you are generating your key, you should select strong passwords -for both the keystore and key.</p> - -<table> -<tr> -<th>Keytool Option</th> -<th>Description</th> -</tr> -<tr> -<td><code>-genkey</code></td><td>Generate a key pair (public and private -keys)</td> -</tr> -<tr> -<td><code>-v</code></td><td>Enable verbose output.</td> -</tr> -<tr> -<td><code>-alias <alias_name></code></td><td>An alias for the key. Only -the first 8 characters of the alias are used.</td> -</tr> -<tr> -<td><code>-keyalg <alg></code></td><td>The encryption algorithm to use -when generating the key. Both DSA and RSA are supported.</td> -</tr> -<tr> -<td><code>-keysize <size></code></td><td>The size of each generated key -(bits). If not supplied, Keytool uses a default key size of 1024 bits. In -general, we recommend using a key size of 2048 bits or higher. </td> -</tr> -<tr> -<td><code>-dname <name></code></td><td><p>A Distinguished Name that describes -who created the key. The value is used as the issuer and subject fields in the -self-signed certificate. </p><p>Note that you do not need to specify this option -in the command line. If not supplied, Jarsigner prompts you to enter each -of the Distinguished Name fields (CN, OU, and so on).</p></td> -</tr> -<tr> -<td><code>-keypass <password></code></td><td><p>The password for the -key.</p> <p>As a security precaution, do not include this option in your command -line. If not supplied, Keytool prompts you to enter the password. In this way, -your password is not stored in your shell history.</p></td> -</tr> -<tr> -<td><code>-validity <valdays></code></td><td><p>The validity period for the -key, in days. </p><p><strong>Note:</strong> A value of 10000 or greater is recommended.</p></td> -</tr> -<tr> -<td><code>-keystore <keystore-name>.keystore</code></td><td>A name -for the keystore containing the private key.</td> -</tr> -<tr> -<td><code>-storepass <password></code></td><td><p>A password for the -keystore.</p><p>As a security precaution, do not include this option in your -command line. If not supplied, Keytool prompts you to enter the password. In -this way, your password is not stored in your shell history.</p></td> -</tr> -</table> - -<p>Here's an example of a Keytool command that generates a private key:</p> - -<pre>$ keytool -genkey -v -keystore my-release-key.keystore --alias alias_name -keyalg RSA -keysize 2048 -validity 10000</pre> - -<p>Running the example command above, Keytool prompts you to provide -passwords for the keystore and key, and to provide the Distinguished -Name fields for your key. It then generates the keystore as a file called -<code>my-release-key.keystore</code>. The keystore and key are -protected by the passwords you entered. The keystore contains -a single key, valid for 10000 days. The alias is a name that you — -will use later, to refer to this keystore when signing your application. </p> - -<p>For more information about Keytool, see the documentation at -<a -href="http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html"> -http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html</a></p> - - - -<h3 id="releasecompile">2. Compile the application in release mode</h3> - -<p>In order to release your application to users, you must compile it in release mode. -In release mode, the compiled application is not signed by default and you will need -to sign it with your private key.</p> - -<p class="caution"><strong>Caution:</strong> -You can not release your application unsigned, or signed with the debug key.</p> - -<h4>With Eclipse</h4> - -<p>To export an <em>unsigned</em> APK from Eclipse, right-click the project in the Package -Explorer and select <strong>Android Tools</strong> > <strong>Export Unsigned Application -Package</strong>. Then specify the file location for the unsigned APK. -(Alternatively, open your <code>AndroidManifest.xml</code> file in Eclipse, select -the <strong>Manifest</strong> tab, and click <strong>Export an unsigned APK</strong>.)</p> - -<p>Note that you can combine the compiling and signing steps with the Export Wizard. See -<a href="#ExportWizard">Compiling and signing with Eclipse ADT</a>.</p> - -<h4>With Ant</h4> - -<p>If you are using Ant, you can enable release mode by using the <code>release</code> option -with the <code>ant</code> command. For example, if you are running Ant from the -directory containing your {@code build.xml} file, the command would look like this:</p> - -<pre>$ ant release</pre> - -<p>By default, the build script compiles the application APK without signing it. The output file -in your project {@code bin/} will be <code><em><your_project_name></em>-unsigned.apk</code>. -Because the application APK is still unsigned, you must manually sign it with your private -key and then align it using {@code zipalign}.</p> - -<p>However, the Ant build script can also perform the signing -and aligning for you, if you have provided the path to your keystore and the name of -your key alias in the project's {@code ant.properties} file. With this information provided, -the build script will prompt you for your keystore and alias password when you perform -<code>ant release</code>, it will sign the package and then align it. The final output -file in {@code bin/} will instead be -<code><em><your_project_name></em>-release.apk</code>. With these steps -automated for you, you're able to skip the manual procedures below (steps 3 and 4). -To learn how to specify your keystore and alias in the {@code ant.properties} file, -see <a href="{@docRoot}guide/developing/building/building-cmdline.html#ReleaseMode"> -Building and Running Apps on the Command Line</a>.</p> - - - -<h3 id="signapp">3. Sign your application with your private key</h3> - -<p>When you have an application package that is ready to be signed, you can do sign it -using the Jarsigner tool. Make sure that you have Jarsigner available on your -machine, as described in <a href="#setup">Basic Setup</a>. Also, make sure that -the keystore containing your private key is available.</p> - -<p>To sign your application, you run Jarsigner, referencing both the -application's APK and the keystore containing the private key with which to -sign the APK. The table below shows the options you could use. </p> - -<table> -<tr> -<th>Jarsigner Option</th> -<th>Description</th> -</tr> -<tr> -<td><code>-keystore <keystore-name>.keystore</code></td><td>The name of -the keystore containing your private key.</td> -</tr> -<tr> -<td><code>-verbose</code></td><td>Enable verbose output.</td> -</tr> -<tr> -<td><code>-sigalg</code></td><td>The name of the signature algorithim to use in signing the APK. -Use the value {@code MD5withRSA}.</td> -</tr> -<tr> -<td><code>-digestalg</code></td><td>The message digest algorithim to use in processing the entries -of an APK. Use the value {@code SHA1}.</td> -</tr> -<tr> -<td><code>-storepass <password></code></td><td><p>The password for the -keystore. </p><p>As a security precaution, do not include this option -in your command line unless you are working at a secure computer. -If not supplied, Jarsigner prompts you to enter the password. In this -way, your password is not stored in your shell history.</p></td> -</tr> -<tr> -<td><code>-keypass <password></code></td><td><p>The password for the private -key. </p><p>As a security precaution, do not include this option -in your command line unless you are working at a secure computer. -If not supplied, Jarsigner prompts you to enter the password. In this -way, your password is not stored in your shell history.</p></td> -</tr> -</table> - -<p>Here's how you would use Jarsigner to sign an application package called -<code>my_application.apk</code>, using the example keystore created above. -</p> - -<pre>$ jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore my-release-key.keystore -my_application.apk alias_name</pre> - -<p>Running the example command above, Jarsigner prompts you to provide -passwords for the keystore and key. It then modifies the APK -in-place, meaning the APK is now signed. Note that you can sign an -APK multiple times with different keys.</p> - -<p class="caution"><strong>Caution:</strong> As of JDK 7, the default signing algorithim has -changed, requiring you to specify the signature and digest algorithims ({@code -sigalg} and {@code --digestalg}) when you sign an APK.</p> - -<p>To verify that your APK is signed, you can use a command like this:</p> - -<pre>$ jarsigner -verify my_signed.apk</pre> - -<p>If the APK is signed properly, Jarsigner prints "jar verified". -If you want more details, you can try one of these commands:</p> - -<pre>$ jarsigner -verify -verbose my_application.apk</pre> - -<p>or</p> - -<pre>$ jarsigner -verify -verbose -certs my_application.apk</pre> - -<p>The command above, with the <code>-certs</code> option added, will show you the -"CN=" line that describes who created the key.</p> - -<p class="note"><strong>Note:</strong> If you see "CN=Android Debug", this means the APK was -signed with the debug key generated by the Android SDK. If you intend to release -your application, you must sign it with your private key instead of the debug -key.</p> - -<p>For more information about Jarsigner, see the documentation at -<a href="http://docs.oracle.com/javase/6/docs/technotes/tools/windows/jarsigner.html"> -http://docs.oracle.com/javase/6/docs/technotes/tools/windows/jarsigner.html</a></p> - - -<h3 id="align">4. Align the final APK package</h3> - -<p>Once you have signed the APK with your private key, run <code>zipalign</code> on the file. -This tool ensures that all uncompressed data starts with a particular byte alignment, -relative to the start of the file. Ensuring alignment at 4-byte boundaries provides -a performance optimization when installed on a device. When aligned, the Android -system is able to read files with {@code mmap()}, even if -they contain binary data with alignment restrictions, rather than copying all -of the data from the package. The benefit is a reduction in the amount of -RAM consumed by the running application.</p> - -<p>The <code>zipalign</code> tool is provided with the Android SDK, inside the -<code>tools/</code> directory. To align your signed APK, execute:</p> - -<pre>$ zipalign -v 4 <em>your_project_name</em>-unaligned.apk <em>your_project_name</em>.apk</pre> - -<p>The {@code -v} flag turns on verbose output (optional). {@code 4} is the -byte-alignment (don't use anything other than 4). The first file argument is -your signed {@code .apk} file (the input) and the second file is the destination {@code .apk} file -(the output). If you're overriding an existing APK, add the {@code -f} flag.</p> - -<p class="caution"><strong>Caution:</strong> Your input APK must be signed with your -private key <strong>before</strong> you optimize the package with {@code zipalign}. -If you sign it after using {@code zipalign}, it will undo the alignment.</p> - -<p>For more information, read about the -<a href="{@docRoot}guide/developing/tools/zipalign.html">zipalign</a> tool. - - -<h3 id="ExportWizard">Compile and sign with Eclipse ADT</h3> - -<p>If you are using Eclipse with the ADT plugin, you can use the Export Wizard to -export a <em>signed</em> APK (and even create a new keystore, -if necessary). The Export Wizard performs all the interaction with -the Keytool and Jarsigner for you, which allows you to sign the package using a GUI -instead of performing the manual procedures to compile, sign, -and align, as discussed above. Once the wizard has compiled and signed your package, -it will also perfom package alignment with {@code zipalign}. -Because the Export Wizard uses both Keytool and Jarsigner, you should -ensure that they are accessible on your computer, as described above -in the <a href="#setup">Basic Setup for Signing</a>.</p> - -<p>To create a signed and aligned APK in Eclipse:</p> - -<ol> - <li>Select the project in the Package -Explorer and select <strong>File > Export</strong>.</li> - <li>Open the Android folder, select Export Android Application, - and click <strong>Next</strong>. - <p>The Export Android Application wizard now starts, which will - guide you through the process of signing your application, - including steps for selecting the private key with which to sign the APK - (or creating a new keystore and private key).</p> - <li>Complete the Export Wizard and your application will be compiled, - signed, aligned, and ready for distribution.</li> -</ol> - - - -<h2 id="secure-key">Securing Your Private Key</h2> - -<p>Maintaining the security of your private key is of critical importance, both -to you and to the user. If you allow someone to use your key, or if you leave -your keystore and passwords in an unsecured location such that a third-party -could find and use them, your authoring identity and the trust of the user -are compromised. </p> - -<p>If a third party should manage to take your key without your knowledge or -permission, that person could sign and distribute applications that maliciously -replace your authentic applications or corrupt them. Such a person could also -sign and distribute applications under your identity that attack other -applications or the system itself, or corrupt or steal user data. </p> - -<p>Your reputation as a developer entity depends on your securing your private -key properly, at all times, until the key is expired. Here are some tips for -keeping your key secure: </p> - -<ul> -<li>Select strong passwords for the keystore and key.</li> -<li>When you generate your key with Keytool, <em>do not</em> supply the -<code>-storepass</code> and <code>-keypass</code> options at the command line. -If you do so, your passwords will be available in your shell history, -which any user on your computer could access.</li> -<li>Similarly, when signing your applications with Jarsigner, -<em>do not</em> supply the <code>-storepass</code> and <code>-keypass</code> -options at the command line. </li> -<li>Do not give or lend anyone your private key, and do not let unauthorized -persons know your keystore and key passwords.</li> -</ul> - -<p>In general, if you follow common-sense precautions when generating, using, -and storing your key, it will remain secure. </p>
\ No newline at end of file diff --git a/docs/html/guide/publishing/licensing.html b/docs/html/guide/publishing/licensing.html deleted file mode 100644 index 8e97f32..0000000 --- a/docs/html/guide/publishing/licensing.html +++ /dev/null @@ -1,11 +0,0 @@ -<html> -<head> -<meta http-equiv="refresh" -content="0;url=http://developer.android.com/guide/market/licensing/index.html"> -<title>Redirecting...</title> -</head> -<body> -<p>You should have been redirected. Please <a -href="http://developer.android.com/guide/market/licensing/index.html">click here</a>.</p> -</body> -</html>
\ No newline at end of file diff --git a/docs/html/guide/publishing/preparing.jd b/docs/html/guide/publishing/preparing.jd deleted file mode 100644 index 8e75728..0000000 --- a/docs/html/guide/publishing/preparing.jd +++ /dev/null @@ -1,358 +0,0 @@ -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}guide/publishing/publishing_overview.html">Publishing Overview</a></li> - <li><a href="{@docRoot}guide/publishing/app-signing.html">Signing Your Applications</a></li> - <li><a href="{@docRoot}guide/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}guide/developing/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}guide/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}guide/developing/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 — 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}guide/developing/debugging/index.html">Debugging</a> and <a -href="{@docRoot}guide/developing/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}guide/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><application></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}guide/developing/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}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"> - <uses-permission></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"><application></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"><manifest></a> - element. For more information see - <a href="{@docRoot}guide/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"> <uses-sdk></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}sdk/compatibility-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}guide/market/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}guide/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}guide/developing/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}guide/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}guide/developing/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}guide/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}guide/market/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}guide/topics/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}guide/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}guide/publishing/publishing.html">Publishing on Google Play</a>.</p> - - diff --git a/docs/html/guide/publishing/publishing.jd b/docs/html/guide/publishing/publishing.jd deleted file mode 100644 index b9513ab..0000000 --- a/docs/html/guide/publishing/publishing.jd +++ /dev/null @@ -1,703 +0,0 @@ -page.title=Publishing on Google Play -@jd:body - -<div id="qv-wrapper"> -<div id="qv"> - -<h2>Quickview</h2> - -<ul> -<li>Learn how to publish and update apps on Google Play.</li> -<li>Find out how to create links to apps that are published on Google Play.</li> -<li>Learn about Google Play features.</li> -</ul> - - -<h2>In this document</h2> - -<ol> -<li><a href="#overview">About Google Play</a> -<li><A href="#marketpublish">Publishing Apps on Google Play</a></li> -<li><a href="#marketupgrade">Publishing Updates on Google Play</a></li> -<li><a href="#marketLicensing">Using Google Play Licensing Service</a></li> -<li><a href="#marketinappbilling">Using Google Play In-app Billing</a></li> -<li><a href="#marketintent">Linking to Your Apps on Google Play</a> - <ol> - <li><a href="#OpeningDetails">Opening an app's details page</a></li> - <li><a href="#PerformingSearch">Performing a search</a></li> - <li><a href="#BuildaButton">Build a Google Play button</a></li> - <li><a href="#UriSummary">Summary of URI formats</a></li> - </ol> -</li> -</ol> - -<h2>See also</h2> - -<ol> -<li><a href="{@docRoot}guide/publishing/publishing_overview.html">Publishing Overview</a></li> -<li><a href="{@docRoot}guide/publishing/preparing.html">Preparing for Release</a></li> -</ol> - -<div id="qv-extra"> - <img id="rule" src="{@docRoot}assets/images/grad-rule-qv.png"> - <div id="qv-sub-rule"> - <img src="{@docRoot}assets/images/icon_play.png" style="float:left;margin:0;padding:0 5px;"> - <h2 style="color:#669999;">Already know about Google Play and want to get started?</h2> - <p>Go to <a href="http://play.google.com/apps/publish">Google Play</a>, create a developer -account, and upload your application. For more information about required assets, listing details, -and publishing options, see <a -href="http://market.android.com/support/bin/answer.py?answer=113469">Upload -Applications</a>.</p> - </div> -</div> - -</div> -</div> - -<p>One of the most effective ways to get your application into users' hands is to -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 Google Play Android Developer Console -after you register as a Google Play developer.</p> - -<p>To start publishing on Google Play, first read this topic and then go to the <a -href="https://play.google.com/apps/publish">Google Play Android Developer Console</a> and register as -a Google Play developer.</p> - - -<h2 id="overview">About Google Play</h2> - -<p>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 -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 <a -href="{@docRoot}guide/market/billing/index.html">in-app billing</a> and -<a href="{@docRoot}guide/market/licensing/index.html">application licensing</a>.</p> - -<p>Before you can publish applications on Google Play, you need to <a -href="http://play.google.com/apps/publish">register</a> 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 <a href="http://www.android.com/us/developer-distribution-agreement.html">Google Play -Developer Distribution Agreement</a>. 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 <a href="https://support.google.com/androidmarket/developer/bin/answer.py?hl=en&answer=113468"> -Developer Registration</a>.</p> - -<h2 id="marketpublish">Publishing Apps on Google Play</h2> - -<p>Publishing your application on Google Play is a simple process that involves three basic -tasks (see figure 1):</p> - -<ul> - <li>Creating various graphical assets that -accompany your app on Google Play.</li> - <li>Using the Google Play <a -href="http://play.google.com/apps/publish">Developer Console</a> to configure publishing options, -specify listing details, and upload your app and graphical assets to Google Play.</li> - <li>Reviewing your publishing settings and changing the release -status of your app from Unpublished to Published.</li> -</ul> - -<img src="{@docRoot}images/publishing/publishing_android_market.png" - alt="Shows the three steps that are required to publish on Google Play" - height="168" - id="figure1" /> -<p class="img-caption"> - <strong>Figure 1.</strong> To publish apps on Google Play you must first <a -href="{@docRoot}guide/publishing/preparing.html">prepare your app for release</a> and then perform -three simple tasks. -</p> - -<p class="caution"><strong>Important:</strong> You must <a -href="{@docRoot}guide/publishing/preparing.html">prepare your application for release</a> before you -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 Google Play unless it is -signed with your own private release key.</p> - -<h3>Preparing promotional materials</h3> - -<p>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 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 -app. For more information about the graphic assets that accompany your application, see <a -href="http://support.google.com/androidmarket/developer/bin/answer.py?hl=en&answer=1078870">Graphic -Assets for your Application</a>.</p> - -<h3>Configuring options and uploading assets</h3> - -<p>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 <a -href="http://support.google.com/androidmarket/developer/bin/answer.py?hl=en&answer=138294&topic= -2365624&ctx=topic">countries</a> you want to reach, the listing languages you want to use, and the -<a -href="http://support.google.com/androidmarket/developer/bin/answer.py?hl=en&answer=138412&topic= -15867&ctx=topic">price</a> you want to charge in each country. You can also configure listing -details such as the application type, <a -href="https://support.google.com/androidmarket/developer/bin/answer.py?hl=en&answer=113475&topic= -2365760&ctx=topic">category</a>, and <a -href="http://support.google.com/androidmarket/developer/bin/answer.py?hl=en&answer=188189&topic= -2364761&ctx=topic">content rating</a>. In addition, if you want to sell items within your app using -the in-app billing feature, you can use the Developer Console to <a -href="http://grendel.sea.corp.google.com:48014/guide/market/billing/billing_admin.html#billing-list -- setup">create a product list</a> and control which items are available for purchase in your -app.</p> - -<p>When you are finished setting publishing options and listing details, you can upload your assets -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.</p> - -<p>To learn more about Google Play publishing settings, see the following resources:</p> - -<ul> - <li><a -href="http://support.google.com/androidmarket/developer/bin/answer.py?hl=en&answer=113469&topic= -236562&ctx=topic">Upload Applications</a>—provides a summary of the publishing settings -you can configure for an app.</li> - <li><a -href="http://support.google.com/androidmarket/developer/bin/topic.py?hl=en&topic=15867">Selling -Your Apps</a>—provides guidance about pricing, supported currencies, tax rates, and many -other topics related to selling apps.</li> - <li><a -href="https://support.google.com/androidmarket/developer/bin/answer.py?hl=en&answer=1169947&topic= -15867&ctx=topic">Selling Apps in Multiple Currencies</a>—provides a description of how -pricing, payouts, and exchange rates work.</li> -</ul> - -<h3>Publishing your application</h3> - -<p>When you are satisfied that your publishing settings are correctly configured and your uploaded -application is ready to be released to the public, you can simply click <strong>Publish</strong> in -the Developer Console to make your app available for download -around the world. Keep in mind, it can take several hours for your app to appear on Google -Play after you click <strong>Publish</strong> in the Developer Console.</p> - -<h3>Controlling Distribution to Devices</h3> - -<p>If your application targets different device configurations, you can control which Android-powered -devices have access to your application on Google Play by -using Google Play filters. Filtering compares device configurations that you declare in your -app's manifest file to the configuration defined by a device. For example, if you declare the camera -filter in your manifest, only those devices that have a camera will see your app on Google -Play. Filters must be configured in your application's manifest file when you are <a -href="{@docRoot}guide/publishing/preparing.html">preparing your app for release</a> (that is, before -you upload your app to Google Play). For more information, see <a -href="{@docRoot}guide/appendix/market-filters.html">Filters on Google Play</a>.</p> - -<p>You can also use the multiple APK feature to distribute different {@code .apk} files under the same -application listing and the same package name; however, you should use this option only as a last -resort. Android applications usually run on most compatible devices with a single APK, by supplying -alternative resources for different configurations (for example, different layouts for different screen -sizes) and the Android system selects the appropriate resources for the device at runtime. In a -few cases, however, a single APK is unable to support all device configurations, because alternative -resources make the APK file too big (greater than 50MB) or other technical challenges 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, 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. To use this feature, you need to build your separate {@code .apk} files when you are <a -href="{@docRoot}guide/publishing/preparing.html">preparing your app for release</a> (that is, before -you upload your app to Google Play). For more information, see <a -href="{@docRoot}guide/market/publishing/multiple-apks.html">Multiple APK Support</a>.</p> - -<h2 id="marketupgrade">Publishing Updates on Google Play</h2> - -<p>At any time after publishing an application on Google Play, you can upload -and publish an update to the same application package. When you publish an -update to an application, users who have already installed the -application may receive a notification that an update is -available for the application. They can then choose to update the application -to the latest version.</p> - -<p>Before uploading the updated application, be sure that you have incremented -the <code>android:versionCode</code> and <code>android:versionName</code> -attributes in the <a -href="{@docRoot}guide/topics/manifest/manifest-element.html"><code><manifest></code></a> -element of the manifest file. Also, the package name must be the same as the existing version and -the {@code .apk} file must be signed with the same private key. If the package name and signing -certificate do <em>not</em> match those of the existing version, Google Play will -consider it a new application, publish it as such, and will not offer it to existing users as an -update.</p> - -<p>If you plan to publish your application on Google Play, you must make sure - that it meets the requirements listed below, which are enforced by Google Play - when you upload the application.</p> - -<h2 id="marketLicensing">Using Google Play Licensing Service</h2> - -<p>Google Play offers a licensing service that lets you enforce licensing -policies for paid applications that you publish through Google Play. With -Google Play Licensing, your applications can query Google Play at runtime -to obtain the licensing status for the current user, then allow or disallow -further use of the application as appropriate. Using the service, you can apply a flexible -licensing policy on an application-by-application basis—each -application can enforce its licensing status in the way most appropriate -for it. </p> - -<p>Any application that you publish through Google Play can use the Google -Play Licensing Service. The service uses no dedicated framework APIs, so you can -add licensing to any application that uses a minimum API Level of 3 or -higher.</p> - -<p>For complete information about Google Play Licensing Service and how to -use it in your application, read <a -href="{@docRoot}guide/market/licensing/index.html">Application Licensing</a>.</p> - -<h2 id="marketinappbilling">Using Google Play In-app Billing</h2> - -<p><a href="{@docRoot}guide/market/billing/billing_overview.html">Google Play In-app Billing</a> -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.</p> - -<p>When you use Google Play's in-app billing service to sell an item, Google Play handles all -billing details so your application never has to directly process any financial transactions. -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%).</p> - -<p>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 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.</p> - -<p>To help you integrate in-app billing into your application, the Android SDK provides a <a -href="{@docRoot}guide/market/billing/billing_integrate.html#billing-download">sample application</a> -that demonstrates a simple implementation of in-app billing. The sample application contains -examples of billing-related classes you can use to implement in-app billing in your application. It -also contains examples of the database, user interface, and business logic you might use to -implement in-app billing. For more information about the in-app billing feature, see the -<a href="{@docRoot}guide/market/billing/index.html">In-app Billing documentation</a>.</p> - -<h2 id="marketintent">Linking to Your Apps on Google Play</h2> - -<p>To help users discover your published applications, you can use two special Google Play URIs -that direct users to your application's details page or perform a search for all of your published -applications on Google Play. You can use these URIs to create a button in your application or a -link on a web page that:</p> - -<ul> - <li>Opens your application's details page in the Google Play application or web site.</li> - <li>Searches for all your published applications in the Google Play application or web -site.</li> -</ul> - -<p>You can launch the Google Play application or web site in the following ways:</p> -<ul> - <li>Initiate an {@link android.content.Intent} from your application that launches the -Google Play application on the user's device.</li> - <li>Provide a link on a web page that opens the Google Play web site (but will also -open the Google Play application if clicked from a device).</li> -</ul> - -<p>In both cases, whether you want to initiate the action from your application or from a web -page, the URIs are quite similar. The only difference is the URI prefix.</p> - -<p>To open the Google Play application from your application, the prefix for the intent's data -URI is:</p> - -<p style="margin-left:2em"><code>market://</code></p> - -<p>To open Google Play store from your web site, the prefix for the link URI is:</p> - -<p style="margin-left:2em"><code>http://play.google.com/store/</code></p> - -<p>The following sections describe how to create a complete URI for each action.</p> - -<p class="note"><strong>Note:</strong> If you create a link to open Google Play from your web -site and the user selects it from an Android-powered device, the device's Google Play application will -resolve the link so the user can use the Google Play application on the device instead of opening the web -site. As such, you should always use {@code http://play.google.com/store/apps/...} URIs when -creating a link on -a web page. When pointing to your apps from within your Android app, use the -{@code market://} URIs in an intent, so that the Google Play application always opens.</p> - - -<h3 id="OpeningDetails">Opening an app's details page</h3> - -<p>As described above, you can open the details page for a specific application either on the -Google Play application or the Google Play web site. The details page allows the user to see -the application description, screenshots, reviews and more, and choose to install it.</p> - -<p>The format for the URI that opens the details page is:</p> - -<p style="margin-left:2em"><code><URI_prefix><b>apps/details?id=</b><package_name></code></p> - -<p>The <code><package_name></code> is a placeholder for the target application's -fully-qualified package name, as declared in the <a -href="{@docRoot}guide/topics/manifest/manifest-element.html#package">{@code -package}</a> attribute of the <a href="{@docRoot}guide/topics/manifest/manifest-element.html">{@code -<manifest>}</a> element.</p> - -<p>For example: <code>http://play.google.com/store/apps/details?id=com.example.myapp</code></p> - - -<h4>Opening the app details page from your Android app</h4> - -<p>To open the Google Play details page from your application, -create an intent with the {@link android.content.Intent#ACTION_VIEW} action and include a data URI -in this format:</p> - -<p style="margin-left:2em"><code>market://details?id=<package_name></code></p> - -<p>For example, here's how you can create an intent and open an application's details page in -Google Play:</p> - -<pre> -Intent intent = new Intent(Intent.ACTION_VIEW); -intent.setData(Uri.parse("market://details?id=com.example.android")); -startActivity(intent); -</pre> - -<p>This will open the Google Play application on the device to view the {@code -com.example.android} application.</p> - - -<h4>Opening the app details page from a web site</h4> - -<p>To open the details page from your web site, create a link with a URI in this -format:</p> - -<p style="margin-left:2em"> - <code>http://play.google.com/store/apps/details?id=<package_name></code> -</p> - -<p>For example, here's a link that opens an application's details page on Google Play:</p> - -<pre> -<a href="http://play.google.com/store/apps/details?id=com.example.android">App Link</a> -</pre> - -<p>When clicked from a desktop web browser, this opens the Google Play web site to view the -{@code com.example.android} application. When clicked from an Android-powered device, users are -given the option to use either their web browser or the Google Play application to view the -application.</p> - - - -<h3 id="PerformingSearch">Performing a search</h3> - -<p>To initiate a search on Google Play, the format for the URI is:</p> - -<p style="margin-left:2em"> - <code><URI_prefix><b>search?q=</b><query></code> -</p> - -<p>The <code><query></code> is a placeholder for the search query to execute in Google -Play. The query can be a raw text string or you can include a parameter that performs a search -based on the publisher name:</p> - -<ul> - <li>To perform a raw text search, append the query string: - <p><code><URI_prefix><b>search?q=</b><search_query></code></p></li> - - <li>To search based on the publisher name, use the {@code pub:} parameter in the query, followed -by the publisher name: - <p><code><URI_prefix><b>search?q=pub:</b><publisher_name></code></p> - <p>You can use this type of search to show all of your published applications.</p></li> -</ul> - - -<h4>Searching from your Android app</h4> - -<p>To initiate a search on Google Play from your application, create an intent with the -{@link android.content.Intent#ACTION_VIEW} action and include a data URI in this format:</p> - -<p style="margin-left:2em"><code>market://search?q=<query></code></p> - -<p>The query may include the {@code pub:} parameter described above.</p> - -<p>For example, here's how you can initiate a search in the Google Play application, based on the -publisher name:</p> - -<pre> -Intent intent = new Intent(Intent.ACTION_VIEW); -intent.setData(Uri.parse("market://search?q=pub:Your Publisher Name")); -startActivity(intent); -</pre> - -<p>This opens the Google Play application to perform the search. The search result shows all -applications published by the publisher that are compatible with the current device.</p> - - -<h4>Searching from a web site</h4> - -<p>To initiate a search on Google Play from your web site, create a link with a URI in this -format:</p> - -<p style="margin-left:2em"> - <code>http://play.google.com/store/search?q=<query></code> -</p> - -<p>The query may include the {@code pub:} parameter described above.</p> - -<p>For example, here's a link that initiates a search on Google Play, based on the -publisher name:</p> - -<pre> -<a href="http://play.google.com/store/search?q=pub:Your Publisher Name">Search Link</a> -</pre> - -<p>When clicked from a desktop web browser, this opens the Google Play web site and performs the -search. When clicked from an Android-powered device, users are given the option to use either their -web browser or the Google Play application to perform the search.</p> - - - -<h3 id="BuildaButton">Build a Google Play button</h3> - -<p>Use the following form to create a button for your web site that takes users to your application -on Google Play. Input either your application's package name or your 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).</p> - -<p>This form offers two styles of the official brand badge each at recommended sizes. You can pick -between either "Get it on Google Play" or "Android app on Google Play." You should not modify the -badge images in any way. For more usage guidelines, -see the <a href="http://www.android.com/branding.html">Android Brand Guidelines</a>.</p> - -<style type="text/css"> - -form.button-form { - margin-top:2em; -} - -/* the label and input elements are blocks that float left in order to - keep the left edgets of the input aligned, and IE 6/7 do not fully support "inline-block" */ -label.block { - display: block; - float: left; - width: 100px; - padding-right: 10px; -} - -input.text { - display: block; - float: left; - width: 250px; -} - -div.button-row { - white-space:nowrap; - min-height:80px; -} - -div.button-row input { - vertical-align:120%; -} - -#jd-content div.button-row img { - margin: 0; -} - -</style> - -<script type="text/javascript"> - -// variables for creating 'try it out' demo button -var imagePath = "http://www.android.com/images/brand/" -var linkStart = "<a href=\"http://play.google.com/store/"; -var imageStart = "\">\n" - + " <img alt=\""; - // leaves opening for the alt text value -var imageSrc = "\"\n src=\"" + imagePath; - // leaves opening for the image file name -var imageEnd = ".png\" />\n</a>"; - -// variables for creating code snippet -var linkStartCode = "<a href=\"http://play.google.com/store/"; -var imageStartCode = "\">\n" - + " <img alt=\""; - // leaves opening for the alt text value -var imageSrcCode = "\"\n src=\"" + imagePath; - // leaves opening for the image file name -var imageEndCode = ".png\" />\n</a>"; - -/** Generate the HTML snippet and demo based on form values */ -function buildButton(form) { - var selectedValue = $('form input[type=radio]:checked').val(); - var altText = selectedValue.indexOf("get_it") != -1 ? "Get it on Google Play" : "Android app on Google Play"; - - if (form["package"].value != "com.example.android") { - $("#preview").show(); - $("#snippet").show().html(linkStartCode + "apps/details?id=" + form["package"].value - + imageStartCode + altText + imageSrcCode - + selectedValue + imageEndCode); - $("#button-preview").html(linkStart + "apps/details?id=" + form["package"].value - + imageStart + altText + imageSrc - + selectedValue + imageEnd); - } else if (form["publisher"].value != "Example, Inc.") { - $("#preview").show(); - $("#snippet").show().html(linkStartCode + "search?q=pub:" + form["publisher"].value - + imageStartCode + altText + imageSrcCode - + selectedValue + imageEndCode); - $("#button-preview").html(linkStart + "search?q=pub:" + form["publisher"].value - + imageStart + altText + imageSrc - + selectedValue + imageEnd); - } else { - alert("Please enter your package name or publisher name"); - } - return false; -} - -/** Listen for Enter key */ -function onTextEntered(event, form, me) { - // 13 = enter - if (event.keyCode == 13) { - buildButton(form); - } -} - -/** When input is focused, remove example text and disable other input */ -function onInputFocus(object, example) { - if (object.value == example) { - $(object).val('').css({'color' : '#000'}); - } - $('input[type="text"]:not(input[name='+object.name+'])', - object.parentNode).attr('disabled','true'); - $('#'+object.name+'-clear').show(); -} - -/** When input is blured, restore example text if appropriate and enable other input */ -function onInputBlur(object, example) { - if (object.value.length < 1) { - $(object).attr('value',example).css({'color':'#ccc'}); - $('input[type="text"]', object.parentNode).removeAttr('disabled'); - $('#'+object.name+'-clear').hide(); - } -} - -/** Clear the form to start over */ -function clearLabel(id, example) { - $("#preview").hide(); - $('#'+id+'').html('').attr('value',example).css({'color':'#ccc'}); - $('input[type="text"]', $('#'+id+'').parent()).removeAttr('disabled'); - $('#'+id+'-clear').hide(); - return false; -} - -/** When the doc is ready, find the inputs and color the input grey if the value is the example - text. This is necessary to handle back-navigation, which can auto-fill the form with previous - values (and text should not be grey) */ -$(document).ready(function() { - $(".button-form input.text").each(function(index) { - if ($(this).val() == $(this).attr("default")) { - $(this).css("color","#ccc"); - } else { - /* This is necessary to handle back-navigation to the page after form was filled */ - $('input[type="text"]:not(input[name='+this.name+'])', - this.parentNode).attr('disabled','true'); - $('#'+this.name+'-clear').show(); - } - }); -}); - -</script> - -<form class="button-form"> - <label class="block" for="package">Package name:</label> - <input class="text" type="text" id="package" name="package" - value="com.example.android" - default="com.example.android" - onfocus="onInputFocus(this, 'com.example.android')" - onblur="onInputBlur(this, 'com.example.android')" - onkeyup="return onTextEntered(event, this.parentNode, this)"/> - <a id="package-clear" style="display:none" href="#" - onclick="return clearLabel('package','com.example.android');">clear</a> - <p style="clear:both;margin:0"> <em>or</em></p> - <label class="block" style="margin-top:5px" for="publisher">Publisher name:</label> - <input class="text" type="text" id="publisher" name="publisher" - value="Example, Inc." - default="Example, Inc." - onfocus="onInputFocus(this, 'Example, Inc.')" - onblur="onInputBlur(this, 'Example, Inc.')" - onkeyup="return onTextEntered(event, this.parentNode, this)"/> - <a id="publisher-clear" style="display:none" href="#" - onclick="return clearLabel('publisher','Example, Inc.');">clear</a> - <br/><br/> - -<div class="button-row"> - <input type="radio" name="buttonStyle" value="get_it_on_play_logo_small" id="ns" checked="checked" /> - <label for="ns"><img src="http://www.android.com/images/brand/get_it_on_play_logo_small.png" -alt="Get it on Google Play (small)" /></label> - - <input type="radio" name="buttonStyle" value="get_it_on_play_logo_large" id="nm" /> - <label for="nm"><img src="http://www.android.com/images/brand/get_it_on_play_logo_large.png" -alt="Get it on Google Play (large)" /></label> -</div> - -<div class="button-row"> - <input type="radio" name="buttonStyle" value="android_app_on_play_logo_small" id="ws" /> - <label for="ws"><img src="http://www.android.com/images/brand/android_app_on_play_logo_small.png" -alt="Android app on Google Play (small)" /></label> - - <input type="radio" name="buttonStyle" value="android_app_on_play_logo_large" id="wm" /> - <label for="wm"><img src="http://www.android.com/images/brand/android_app_on_play_logo_large.png" -alt="Android app on Google Play (large)" /></label> -</div> - - <input type="button" onclick="return buildButton(this.parentNode)" value="Build my button" -style="padding:5px" /> - <br/> -</form> - -<div id="preview" style="display:none"> - <p>Copy and paste this HTML into your web site:</p> - <textarea id="snippet" cols="100" rows="5" onclick="this.select()" -style="font-family:monospace;background-color:#efefef;padding:5px;display:none;margin-bottom:1em"> - </textarea > - -<p>Try it out:</p> -<div id="button-preview" style="margin-top:1em"></div> -</div> - - - - - - -<h3 id="UriSummary">Summary of URI formats</h3> - -<p>The table below provides a summary of the URIs currently supported by the Google Play (both on -the web and in the Android application), as discussed in the previous sections.</p> - -<table> -<tr> -<th>For this result</th> -<th>Use this URI in a web page link</th> -<th>Or this URI in an {@link android.content.Intent#ACTION_VIEW} intent</th> -</tr> - -<tr> -<td>Display the details screen for a specific application</td> -<td><code>http://play.google.com/store/apps/details?id=<package_name></code> -<td><code>market://details?id=<package_name></code></td> -</tr> - -<tr> -<td>Search for applications using a general string query.</td> -<td><code>http://play.google.com/store/search?q=<query></code></td> -<td><code>market://search?q=<query></code></td> -</tr> - -<tr> -<td>Search for applications by publisher name</td> -<td><nobr><code>http://play.google.com/store/search?q=pub:<publisher_name></code></nobr></td> -<td><nobr><code>market://search?q=pub:<publisher_name></code></nobr></td> -</tr> - -</table> diff --git a/docs/html/guide/publishing/publishing_overview.jd b/docs/html/guide/publishing/publishing_overview.jd deleted file mode 100755 index 6fb77e1..0000000 --- a/docs/html/guide/publishing/publishing_overview.jd +++ /dev/null @@ -1,231 +0,0 @@ -page.title=Publishing Overview -@jd:body - -<div id="qv-wrapper"> -<div id="qv"> - <h2>Quickview</h2> - <ul> - <li>Learn how to publish Android apps.</li> - <li>Find out how to prepare apps for release.</li> - <li>Learn how to release apps to users.</li> - </ul> - <h2>In this document</h2> - <ol> - <li><a href="#publishing-prepare">Preparing Your Application for Release</a></li> - <li><a href="#publishing-release">Releasing Your Application to Users</a> - <ol> - <li><a href="#publishing-market">Releasing on Google Play</a></li> - <li><a href="#publishing-website">Releasing on your own website</a></li> - <li><a href="#publishing-email">Releasing through email</a></li> - </ol> - </ol> - <h2>See also</h2> - <ol> - <li><a href="{@docRoot}guide/publishing/preparing.html">Preparing for - Release</a></li> - <li><a href="{@docRoot}guide/publishing/publishing.html">Publishing on Google Play</a></li> - </ol> -</div> -</div> - -<p>Publishing is the process that makes your Android applications available to users. When you -publish an Android application you perform two main tasks:</p> - -<ul> - <li>You prepare the application for release. - <p>During the preparation step you build a release version of your application, which users can - download and install on their Android-powered devices.</p> - </li> - <li>You release the application to users. - <p>During the release step you publicize, sell, and distribute the release version of your - application to users.</p> - </li> -</ul> - -<p>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.</p> - -<p>Figure 1 shows how the publishing process fits into the overall Android <a -href="{@docRoot}guide/developing/index.html">application development process</a>. -The publishing process is typically performed after you finish testing your application in a debug -environment. Also, as a best practice, your application should meet all of your release criteria for -functionality, performance, and stability before you begin the publishing process.</p> - -<img src="{@docRoot}images/publishing/publishing_overview.png" alt="Shows where the publishing - process fits into the overall development process" height="86" id="figure1" /> -<p class="img-caption"> - <strong>Figure 1.</strong> Publishing is the last phase of the Android <a -href="{@docRoot}guide/developing/index.html">application development process</a>. -</p> - -<h2 id="publishing-prepare">Preparing Your Application for Release</h2> - -<p>Preparing your application for release is a multi-step process that involves the following -tasks:</p> - -<ul> - - <li>Configuring your application for release. - <p>At a minimum you need to remove {@link android.util.Log} calls and remove the - <a href="{@docRoot}guide/topics/manifest/application-element.html#debug">android:debuggable</a> - attribute from your manifest file. You should also provide values for the - <code>android:versionCode</code> and <code>android:versionName</code> attributes, which are - located in the - <a href="{@docRoot}guide/topics/manifest/manifest-element.html"><manifest></a> - 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.</p> - </li> - <li>Building and signing a release version of your application. - <p>The Android Development Tools (ADT) plugin and the Ant build script that are provided - with the Android SDK tools provide everything you need to build and sign a release version of - your application.</p> - </li> - <li>Testing the release version of your application. - <p>Before you distribute your application, you should thoroughly test the release version on at - least one target handset device and one target tablet device.</p> - </li> - <li>Updating application resources for release. - <p>You need to be sure that all application resources such as multimedia files and graphics - are updated and included with your application or staged on the proper production servers.</p> - </li> - <li>Preparing remote servers and services that your application depends on. - <p>If your application depends on external servers or services, you need to be sure they - are secure and production ready.</p> - </li> -</ul> - -<p>You may have to perform several other tasks as part of the preparation process. For example, you -will need to get a private key for signing your application, and you may need to get a Maps API -release key if you are using the <a -href="http://code.google.com/android/add-ons/google-apis/maps-overview.html">Google Maps external -library</a>. You will also need to create an icon for your application, and you may want to prepare -an End User License Agreement (EULA) to protect your person, organization, and intellectual -property.</p> - -<p>When you are finished preparing your application for release you will have a signed -<code>.apk</code> file that you can distribute to users.</p> - -<p>To learn how to prepare your application for release, see <a -href="{@docRoot}guide/publishing/preparing.html">Preparing for Release</a> in the Dev Guide. This -topic provides step-by-step instructions for configuring and building a release version of your -application.</p> - -<h2 id="publishing-release">Releasing Your Application to Users</h2> - -<p>You can release your Android applications several ways. Usually, you release applications -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.</p> - -<h3 id="publishing-market">Releasing Your Applications on Google Play</h3> - -<p>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 -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 <a -href="{@docRoot}guide/market/billing/index.html">in-app billing</a> and <a -href="{@docRoot}guide/market/licensing.html">application licensing</a>. 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.</p> - -<p>Releasing your application on Google Play is a simple process that involves three basic - steps:</p> - -<div class="figure" style="width:275px"> - <img src="{@docRoot}images/publishing/publishing_unknown_sources.png" - alt="Screenshot showing the graphical user interface element that allows unknown sources - to be installed" /> - <p class="img-caption"> - <strong>Figure 2.</strong> The <strong>Unknown sources</strong> setting lets you install - applications that are not published on Google Play . - </p> -</div> - -<ul> - <li>Preparing promotional materials. - <p>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.</p> - </li> - <li>Configuring options and uploading assets. - <p>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 - and your application as a draft (unpublished) application.</p> - </li> - <li>Publishing the release version of your application. - <p>If you are satisfied that your publishing settings are correctly configured and your - uploaded application is ready to be released to the public, you can simply click - <strong>Publish</strong > in the developer console and within minutes your application will be - live and available for download around the world.</p> - </li> -</ul> - -<p>For information about Google Play, see <a -href="{@docRoot}guide/publishing/publishing.html#market">Publishing on Google Play</a>. This -topic provides an introduction to Google Play features and provides a step-by-step guide for -distributing your applications on Google Play.</p> - -<h3 id="publishing-website">Releasing your application on your own website</h3> - -<p>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-Google Play -applications.</p> - -<div class="figure" style="width:275px"> - <img src="{@docRoot}images/publishing/publishing_via_email.png" - alt="Screenshot showing the graphical user interface users see when you send them an app" - height="453" /> - <p class="img-caption"> - <strong>Figure 3.</strong> Users can simply click <strong>Install</strong> when you send them - an application via email. - </p> -</div> - -<p>By default, Android-powered devices allow users to install applications only if the applications -have been downloaded from Google Play. To allow the installation of applications from other -sources, users need to enable the <strong>Unknown sources</strong> setting on their devices, and -they need to make this configuration change before they download your application to their -device (see figure 2).</p> - -<p class="note"><strong>Note:</strong> Some network providers do not allow users to install -applications from unknown sources.</p> - -<p>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 -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.</p> - -<h3 id="publishing-email">Releasing your application through email</h3> - -<p>The easiest and quickest way to release your application is to send it to a user through -email. To do this, you prepare your application for release and then attach it to an email -and send it to a user. When the user opens your email message on their Android-powered device -the Android system will recognize the <code>.apk</code> and display an <strong>Install Now</strong> -button in the email message (see figure 3). Users can install your application by touching the -button.</p> - -<p class="note"><strong>Note:</strong> The <strong>Install Now</strong> button appears only if a -user has configured their device to allow the installation of non-Google Play applications and -they open your email with the native Gmail application.</p> - -<p>Releasing applications through email is convenient if you are sending your application to -only a few trusted users, but it provides few protections from piracy and unauthorized -distribution; that is, anyone you send your application to can simply forward it to someone else. -else. diff --git a/docs/html/guide/publishing/versioning.jd b/docs/html/guide/publishing/versioning.jd deleted file mode 100644 index da57e3e..0000000 --- a/docs/html/guide/publishing/versioning.jd +++ /dev/null @@ -1,174 +0,0 @@ -page.title=Versioning Your Applications -@jd:body - -<div id="qv-wrapper"> -<div id="qv"> - -<h2>Quickview</h2> - -<ul> -<li>Your application <em>must</em> be versioned</a></li> -<li>You set the version in the application's manifest file</li> -<li>How you version your applications affects how users upgrade </li> -<li>Determine your versioning strategy early in the development process, including considerations for future releases.</li> -</ul> - -<h2>In this document</h2> - -<ol> -<li><a href="#appversioning">Setting Application Version</a></li> -<li><a href="#minsdkversion">Specifying Your Application's System API Requirements</a> -</ol> - - -<h2>See also</h2> - -<ol> -<li><a href="{@docRoot}guide/publishing/preparing.html">Preparing to Publish Your Application</a></li> -<li><a href="{@docRoot}guide/publishing/publishing.html#market">Publishing On Google Play</a></li> -<li><a href="{@docRoot}guide/topics/manifest/manifest-intro.html">The AndroidManifest.xml File</a></li> -</ol> - -</div> -</div> - -<p>Versioning is a critical component of your application upgrade and maintenance -strategy. Versioning is important because:</p> - -<ul> -<li>Users need to have specific information about the application version that -is installed on their devices and the upgrade versions available for -installation. </li> -<li>Other applications — including other applications that you publish as -a suite — need to query the system for your application's version, to -determine compatibility and identify dependencies.</li> -<li>Services through which you will publish your application(s) may also need to -query your application for its version, so that they can display the version to -users. A publishing service may also need to check the application version to -determine compatibility and establish upgrade/downgrade relationships.</li> -</ul> - -<p>The Android system does not use app version information to enforce -restrictions on upgrades, downgrades, or compatibility of third-party apps. Instead, you (the -developer) are responsible for enforcing version restrictions within your application or by -informing users of the version restrictions and limitations. The Android system does, however, -enforce system version compatibility as expressed by the <code>minSdkVersion</code> attribute in the -manifest. This attribute allows an application to specify the minimum system API with which it is -compatible. For more information see <a href="#minsdkversion">Specifying Minimum System API -Version</a>.</p> - -<h2 id="appversioning">Setting Application Version</h2> -<p>To define the version information for your application, you set attributes in -the application's manifest file. Two attributes are available, and you should -always define values for both of them: </p> - -<ul> -<li><code>android:versionCode</code> — An integer value that represents -the version of the application code, relative to other versions. - -<p>The value is an integer so that other applications can programmatically -evaluate it, for example to check an upgrade or downgrade relationship. You can -set the value to any integer you want, however you should make sure that each -successive release of your application uses a greater value. The system does not -enforce this behavior, but increasing the value with successive releases is -normative. </p> - -<p>Typically, you would release the first version of your application with -versionCode set to 1, then monotonically increase the value with each release, -regardless whether the release constitutes a major or minor release. This means -that the <code>android:versionCode</code> value does not necessarily have a -strong resemblance to the application release version that is visible to the -user (see <code>android:versionName</code>, below). Applications and publishing -services should not display this version value to users.</p> -</li> -<li><code>android:versionName</code> — A string value that represents the -release version of the application code, as it should be shown to users. -<p>The value is a string so that you can describe the application version as a -<major>.<minor>.<point> string, or as any other type of -absolute or relative version identifier. </p> - -<p>As with <code>android:versionCode</code>, the system does not use this value -for any internal purpose, other than to enable applications to display it to -users. Publishing services may also extract the <code>android:versionName</code> -value for display to users.</p> -</li> -</ul> - -<p>You define both of these version attributes in the -<code><manifest></code> element of the manifest file. </p> - -<p>Here's an example manifest that shows the <code>android:versionCode</code> -and <code>android:versionName</code> attributes in the -<code><manifest></code> element. </p> - -<pre> -<?xml version="1.0" encoding="utf-8"?> -<manifest xmlns:android="http://schemas.android.com/apk/res/android" - package="com.example.package.name" - android:versionCode="2" - android:versionName="1.1"> - <application android:icon="@drawable/icon" android:label="@string/app_name"> - ... - </application> -</manifest> -</pre> - -<p>In this example, note that <code>android:versionCode</code> value indicates -that the current .apk contains the second release of the application code, which -corresponds to a minor follow-on release, as shown by the -<code>android:versionName</code> string. </p> - -<p>The Android framework provides an API to let applications query the system -for version information about your application. To obtain version information, -applications use the -{@link android.content.pm.PackageManager#getPackageInfo(java.lang.String, int)} -method of {@link android.content.pm.PackageManager PackageManager}. </p> - -<h2 id="minsdkversion">Specifying Your Application's System API Requirements</h2> - -<p>If your application requires a specific minimum version of the Android -platform, or is designed only to support a certain range of Android platform -versions, you can specify those version requirements as API Level identifiers -in the application's manifest file. Doing so ensures that your -application can only be installed on devices that -are running a compatible version of the Android system. </p> - -<p>To specify API Level requirements, add a <code><uses-sdk></code> -element in the application's manifest, with one or more of these attributes: </p> - -<ul> -<li><code>android:minSdkVersion</code> — The minimum version -of the Android platform on which the application will run, specified -by the platform's API Level identifier. </li> -<li><code>android:targetSdkVersion</code> — Specifies the API Level -on which the application is designed to run. In some cases, this allows the -application to use manifest elements or behaviors defined in the target -API Level, rather than being restricted to using only those defined -for the minimum API Level.</li> -<li><code>android:maxSdkVersion</code> — The maximum version -of the Android platform on which the application is designed to run, -specified by the platform's API Level identifier. <strong>Important:</strong> Please read the <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><code><uses-sdk></code></a> -documentation before using this attribute. </li> -</ul> - -<p>When preparing to install your application, the system checks the value of this -attribute and compares it to the system version. If the -<code>android:minSdkVersion</code> value is greater than the system version, the -system aborts the installation of the application. Similarly, the system -installs your application only if its <code>android:maxSdkVersion</code> -is compatible with the platform version.</p> - -<p>If you do not specify these attributes in your manifest, the system assumes -that your application is compatible with all platform versions, with no -maximum API Level. </p> - -<p>To specify a minimum platform version for your application, add a -<code><uses-sdk></code> element as a child of -<code><manifest></code>, then define the -<code>android:minSdkVersion</code> as an attribute. </p> - -<p>For more information, see the <a -href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><code><uses-sdk></code></a> -manifest element documentation and the <a -href="{@docRoot}guide/appendix/api-levels.html">API Levels</a> document.</p> |