Wednesday 30 July 2014

Multiple APK Upload into Same Application in Google play



Quickview

    Simultaneously publish different APKs for different device configurations
    You should publish multiple APKs only when it's not possible to support all desired devices with a single APK


Multiple APK support is a feature on Google Play that allows you to publish different APKs for your application that are each targeted to different device configurations.
Each APK is a complete and independent version of your application, but they share the same application listing on Google Play and must share the same package name and be
signed with the same release key. This feature is useful for cases in which your application cannot reach all desired devices with a single APK.

Android-powered devices may differ in several ways and it's important to the success of your application that you make it available to as many devices as possible.
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.

By publishing your application with multiple APKs, you can:

    Support different OpenGL texture compression formats with each APK.
    Support different screen sizes and densities with each APK.
    Support different device feature sets with each APK.
    Support different platform versions with each APK.
    Support different CPU architectures with each APK (such as for ARM, x86, and MIPS, when your app uses the Android NDK).


Active APKs:

Before you can publish your application (whether publishing one or multiple APKs), you must "activate" your APK(s) from the APK files tab.
When you activate an APK, it moves into the list of Active APKs. This list allows you to preview which APK(s) you're about to publish.

If there are no errors, any "active" APK will be published to Google Play when you click the Publish button
(if the application is unpublished) or when you click the Save button (if the application is already published).


Simple mode and advanced mode


The Google Play Developer Console provides two modes for managing the APKs associated with your application:
simple mode and advanced mode. You can switch between these by clicking the link at the top-right corner of the APK files tab.

Simple mode is the traditional way to publish an application, using one APK at a time. In simple mode,
only one APK can be activated at a time. If you upload a new APK to update the application,
 clicking "Activate" on the new APK deactivates the currently active APK (you must then click Save to publish the new APK).

Advanced mode allows you to activate and publish multiple APKs that are each designed for
a specific set of device configurations. However, there are several rules based on the manifest declarations in each APK that determine
whether you're allowed to activate each APK along with others. When you activate an APK and it violates one of the rules,
you will receive an error or warning message. If it's an error, you cannot publish until you resolve the problem;
if it's a warning, you can publish the activated APKs, but there might be unintended consequences as to whether
your application is available for different devices. These rules are discussed more below.


Rules for multiple APKs


All APKs you publish for the same application must have the same package name and be signed with the same certificate key.
Each APK must have a different version code, specified by the android:versionCode attribute.
Each APK must not exactly match the configuration support of another APK.

That is, each APK must declare slightly different support for at least one of the supported Google Play filters (listed above).

Usually, you will differentiate your APKs based on a specific characteristic
(such as the supported texture compression formats), and thus, each APK will declare support for different devices. However, it's OK to publish multiple APKs that
overlap their support slightly. When two APKs do overlap (they support some of the same device configurations), a device that falls within that overlap range will
receive the APK with a higher version code (defined by android:versionCode).
You cannot activate a new APK that has a version code lower than that of the APK it's replacing. For example, say you have an active APK for
screen sizes small - normal with version code 0400, then try to replace it with an APK for the same screen sizes with version code 0300.
This raises an error, because it means users of the previous APK will not be able to update the application.
An APK that requires a higher API level must have a higher version code.

Using a version code scheme

This diagram is most important to understand first two digits are API Levels and next is screen size and last is App version please Look at the diagram.





 compatible screens: for manifest file include for different APK files one for Tab other for mobile
This is for tablet
 <compatible-screens>
        <screen android:screenSize="large" android:screenDensity="ldpi"/>
        <screen android:screenSize="large" android:screenDensity="mdpi"  />
        <screen android:screenSize="large" android:screenDensity="hdpi"/>
        <screen android:screenSize="large" android:screenDensity="xhdpi"  />
      
        <screen android:screenSize="xlarge" android:screenDensity="ldpi"/>
        <screen android:screenSize="xlarge" android:screenDensity="mdpi"  />
        <screen android:screenSize="xlarge" android:screenDensity="hdpi"/>
        <screen android:screenSize="xlarge" android:screenDensity="xhdpi"  />      
    </compatible-screens>


This is for Mobile

 <compatible-screens>
        <screen android:screenSize="small" android:screenDensity="ldpi"/>
        <screen android:screenSize="small" android:screenDensity="mdpi"  />
        <screen android:screenSize="small" android:screenDensity="hdpi"/>
        <screen android:screenSize="small" android:screenDensity="xhdpi"  />
       
        <screen android:screenSize="normal" android:screenDensity="ldpi"/>
        <screen android:screenSize="normal" android:screenDensity="mdpi"  />
        <screen android:screenSize="normal" android:screenDensity="hdpi"/>
        <screen android:screenSize="normal" android:screenDensity="xhdpi"  />
       
      
    </compatible-screens>

Android: startActivity and startActivityForResult

Here are some differences between startActivity and startActivityForResult

1. startActvity will start the activity you want to start without worrying about getting any result from new child activity started by startActivity to parent activity.

2. startAcitvityForResult() starts another activity from your activity and it expect to get some data from newly started child activity  by startAcitvityForResult()  and return that to parent activity.