Android App Submission Process

Create an Android Publish account:

To publish app we need to sign the app and need an android developer account.

            Use below link to register as an Android Market Developer. The developer name as it has to appear in the market can be changed at any time once the account has been created.

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

Signing for Public Release

When your application is ready for release to other users, you must:

1.    Obtain a suitable private key

2.    Get Google Maps keys for the private key and integrate the same with application.

3.    Compile the application in release mode

4.    Sign your application with your private key

5.    Align the final APK package

1. Obtain a suitable private key

For signing certificate we need the below information from client

Name of publisher:

Organizational Unit:

Organization:

Location of Organization:

State:

City:

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:

ñ Is in your possession

ñ Represents the personal, corporate, or organizational entity to be identified with the application

ñ Has a validity period that exceeds the expected lifespan of the application or application suite. A validity period of more than 25 years is recommended.

If you plan to publish your application(s) on Android Market, note that a 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.

ñ Is not the debug key generated by the Android SDK tools.

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 Basic Setup.

To generate a self-signed key with Keytool, use the keytool command and pass any of the options listed below (and any others, as needed).

Warning: Keep your private key secure. Before you run Keytool, make sure to read Securing Your Private Key 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.

Keytool Option	Description
-genkey	Generate a key pair (public and private keys)
-v	Enable verbose output.
-alias <alias_name>	An alias for the key. Only the first 8 characters of the alias are used.
-keyalg <alg>	The encryption algorithm to use when generating the key. Both DSA and RSA are supported.
-keysize <size>	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.
-dname <name>	A Distinguished Name that describes who created the key. The value is used as the issuer and subject fields in the self-signed certificate. 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).
-keypass <password>	The password for the key. 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.
-validity <valdays>	The validity period for the key, in days. Note: A value of 10000 or greater is recommended.
-keystore <keystore-name>.keystore	A name for the keystore containing the private key.
-storepass <password>	A password for the keystore. 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.

Here's an example of a Keytool command that generates a private key:

$ keytool -genkey -v -keystore my-release-key.keystore

-alias alias_name -keyalg RSA -keysize 2048 -validity 10000

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 my-release-key.keystore. 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.

For more information about Keytool, see the documentation at http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security

2.     Integrating Google Maps with private key

2.1 Getting the MD5 Fingerprint of Your Signing Certificate

For more information about using Keytool and Jarsigner to sign your application, see Signing Your Applications on the Android Developers site.

To register for a Maps API Key, you need to provide an MD5 fingerprint of the certificate that you will use to sign your application. Before you visit the registration page, use Keytool to generate the fingerprint of the appropriate certificate.

First, determine which key you will use to sign your application at release and make sure of the path to the keystore that contains it.

Next, run Keytool with the -list option, against the target keystore and key alias. The table below lists the options you should use.

Keytool Option	Description
-list	Print an MD5 fingerprint of a certificate.
-keystore <keystore-name>.keystore	The name of the keystore containing the target key.
-storepass <password>	A password for the keystore. As a security precaution, do not include this option in your command line unless you are working at a secure computer. If not supplied, Keytool prompts you to enter the password. In this way, your password is not stored in your shell history.
-alias <alias_name>	The alias for the key for which to generate the MD5 certificate fingerprint.
-keypass <password>	The password for the key. As a security precaution, do not include this option in your command line unless you are working at a secure computer. If not supplied, Keytool prompts you to enter the password. In this way, your password is not stored in your shell history.

Here's an example of a Keytool command that generates an MD5 certificate fingerprint for the key alias_name in the keystore my-release-key.keystore:

$ keytool -list -alias alias_name -keystore my-release-key.keystore

Keytool will prompt you to enter passwords for the keystore and key. As output of the command, Keytool prints the fingerprint to the shell. For example:

Certificate fingerprint (MD5): 94:1E:43:49:87:73:BB:E6:A6:88:D7:20:F1:8E:B5:98

Once you have the fingerprint, you can go to the Maps API registration site, described next.

2.2 Registering the Certificate Fingerprint with the Google Maps Service

When you are ready to register for a Maps API Key, load this page in a browser:

http://code.google. com/android/maps-api-signup.html

To register for a Maps API Key, follow these steps:

1.    If you don't have a Google account, use the link on the page to set one up.

2.    Read the Android Maps API Terms of Service carefully. If you agree to the terms, indicate so using the checkbox on the screen.

3.    Paste the MD5 certificate fingerprint of the certificate that you are registering into the appropriate form field.

4.    Click "Generate API Key"

The server will handle your request, associating the fingerprint with your developer identity and generating a unique Maps API Key, and then will return a results page that gives you your Key string.

To use the Maps API Key string, copy and paste it into your code as described in the next section.

Note: If you happen to forget your Maps API Key, you can generate a fingerprint for your certificate and register it again. The registration server will give you the same Maps API Key for the specified certificate fingerprint.

2.3            Integrating the Map key with application

In all map widgets residing in the application, open the “google map key” property in android section of properties and set the value obtained from the above step there.

3. Compile application

3.1 Compile the application in release mode

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.

3.2 Setting application permissions

By default Application will seek permissions for various phone features that the application uses.

These will be defined  in <workspacelocation>\temp\<appname>\build\luaandroid\dist\<appname>\AndroidManifest.xml

typical permissions will look like

            <uses-permission android:name="android.permission.CALL_PHONE"></uses-permission>
            <uses-permission android:name="android.permission.SEND_SMS"></uses-permission>
            <uses-permission android:name="android.permission.WRITE_SMS"></uses-permission>
            <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"></uses-permission>
            <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"></uses-permission>
            <uses-permission android:name="android.permission.CAMERA"></uses-permission>

1.      Remove permissions that are not relevant to your application and save the file

2.      Download “ant” from the internet or from \\10.10.10.20\swdump\USERS\Suhas\apache-ant-1.8.1-bin.zip and extract it to local machine

3.      open command prompt and cd to below folder <workspacelocation>\temp\<appname>\build\luaandroid\dist\<appname>\

4.       run below command to generate unsigned binary

<ant-extracted-location>\bin\ant release

Note: Application permission setting need not be done, if default permission set is ok to be submitted to end user. While user downloads the application, the user will be notified that the app will use the above permissions. So its a good practice to ensure the permissions are obtained only for features that are used in app.

The location of the unsigned app binary when built from KonyIDE is <workspacelocation>\temp\<appname>\build\luaandroid\dist\<appname>\bin\<appname>-unsigned.apk

The above binary is what needs to be signed with the private key

Caution: You can not release your application unsigned, or signed with the debug key.

 

4. Sign your application with your private key

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 Basic Setup. Also, make sure that the keystore containing your private key is available.

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.

Jarsigner Option	Description
-keystore <keystore-name>.keystore	The name of the keystore containing your private key.
-verbose	Enable verbose output.
-storepass <password>	The password for the keystore. 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.
-keypass <password>	The password for the private key. 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.

Here's how you would use Jarsigner to sign an application package called my_application.apk, using the example keystore created above.

$ jarsigner -verbose -keystore my-release-key.keystore

my_application.apk alias_name

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.

To verify that your .apk is signed, you can use a command like this:

$ jarsigner -verify my_signed.apk

If the .apk is signed properly, Jarsigner prints "jar verified". If you want more details, you can try one of these commands:

$ jarsigner -verify -verbose my_application.apk

or

$ jarsigner -verify -verbose -certs my_application.apk

The command above, with the -certs option added, will show you the "CN=" line that describes who created the key.

Note: 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.

For more information about Jarsigner, see the documentation at http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security

5. Align the final APK package

Once you have signed the .apk with your private key, run zipalign 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 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.

The zipalign tool is provided with the Android SDK, inside the tools/ directory. To align your signed .apk, execute:

zipalign -v 4 your_project_name-unaligned.apk your_project_name.apk

The -v flag turns on verbose output (optional). 4 is the byte-alignment (don't use anything other than 4). The first file argument is your signed .apk (the input) and the second file is the destination .apk file (the output). If you're overriding an existing .apk, add the -f flag.

Caution: Your input .apk must be signed with your private key before you optimize the package with zipalign. If you sign it after using zipalign, it will undo the alignment.

For more information, read about the zipalign tool.

Publishing application to Marketplace:

Other requirements for submission to Android Market place.

ñ   2 Screenshots of the Android app. (320w x 480h or 480w x 854h 24 bit PNG or JPEG (no alpha) Full bleed, no border in art Landscape thumbnails are cropped)

ñ  Promotional graphic (optional) (180w x 120h 24 bit PNG or JPEG (no alpha) Full bleed, no border in art)

ñ  Title (30 chars max)

ñ  Description (325 chars max)

ñ  Promo_Text (80 chars max) (has to be provided if promotional graphic is given)

ñ  Category of app - Category options(Comics, Communication, Demo, Entertainment, Finance, Health, Lifestyle, Multimedia, New & Weather,Productivity, Reference, Shopping, Social, Software libraries, Sports, Themes, Tools, Travel)

ñ  Contact info - website, email, phone

ñ  Marketing Opt-Out – if option is selected it means “Do not promote my application except in Android Market and in any Google-owned online or mobile properties. I understand that any changes to this preference may take sixty days to take effect. “

ñ  High Resolution Application Icon (optional) - 512w x 512h, 24 bit PNG or JPEG (no alpha)

ñ  Feature Graphic (optional) - 1024w x 500h ,24 bit PNG or JPEG (no alpha) ; Will be downsized to mini or micro

ñ  Promotional Video link (optional) -  Enter promotional videos YouTube URL

The screenshots and promotional graphic and video link and promo_text are optional and would be used only if the Geico android app is showcased in their android market. But its better to provide the same if its not considerable extra effort

For more reference please read the below links.

Signing Your applications:
http://developer.android.com/guide/publishing/app-signing.html

Versioning Your applications:
http://developer.android.com/guide/publishing/versioning.html
[NOTE: The version number that is entered in the IDE is automatically taken into the android application for versioning]

Preparing for Publishing: (A Checklist)
http://developer.android.com/guide/publishing/preparing.html

Publishing your Application: (Android market place)
http://developer.android.com/guide/publishing/publishing.html