Creating multiple apks for different GL textures create multiple APK for different GL Structures

When developing your Android Application to take advantage of multiple apks on Google Play, it's important to adopt some good practices from the get-go, and prevent unnecessary headaches further into the development process. this lesson shows you how
Create multiple apks of your app, each supporting a different subset of OpenGL texture formats. You will also gain some tools necessary to make maintaining a multiple APK codebase as painless as possible. http://blog.csdn.net/sergeycao

Confirm you need multiple apks

When trying to create an application that works with SS all available Android-powered devices, naturally you want your application look its best on each individual device, regardless of the fact they don't all support the same set of GL textures. it may seem
At the outset as though multiple APK support is the best solution, but this often isn' t the case.
Using Single APK instead section of the multiple APK developer guide Using DES some useful information on how to accomplish this with a single APK, including how
Detect supported texture formats at runtime. Depending on your situation, it might be easier to bundle all formats with your application, and simply pick which one to use at runtime.

If you can manage it, confining your application to a single APK has several advantages, including:

• Publishing and testing are easier
• There's only one codebase to maintain
• Your application can adapt to device configuration changes
• APP restore internal SS devices just works
• You don't have to worry about market preference, behavior from "upgrades" from one APK to the next, or which APK goes with which class of devices

The rest of this lesson assumes that you 've researched the topic, studiously absorbed the material in the resources linked, and determined that multiple apks are the right path for your application.

Chart your requirements

The android developer Guide provides a handy reference of some of common supported textures on
Supports-Gl-texture page. this page also contains some hints as to which phones (or families of phones) Support particle texture formats. note that it's generally a good idea for one of your apks to support etc1, as that texture format is supported
By all Android-powered devices that support the OpenGL ES 2.0 spec.

Since most Android-powered devices support more than one texture format, you need to establish an order of preference. create a chart including all the formats that your application is going to support. the left-most cell is going to be the lowest priority
(It will probably be etc1, a really solid default in terms of performance and compatibility). Then color in the chart such that each cell represents an APK.

Etc1

ATI

Powervr

Coloring in the chart does more than just make this guide less monochromatic-it also has a way of making intra-team communication easier-you can now simply refer to each APK as "blue ", "green", or "red", instead of "The one that supports etc1 texture
Formats ", etc.

Put all common code and resources in a library project

Whether you're modifying an existing Android Application or starting one from scratch, this is the first thing that you should do to the codebase, and by the far the most important. everything that goes into the library project only needs to be updated once
(Think language-localized strings, color themes, bugs fixed in shared code), which improves your development time and CES the likelihood of mistakes that cocould have easily avoided.

Note:While the implementation details of how to create and include library projects are beyond the scope of this lesson, you can get up to speed quickly on their creation at the following links:

• Setting up a library project (eclipse)
• Setting up a library project (command line)

If you're converting an existing application to use multiple APK support, scour your codebase for every localized string file, list of values, theme colors, menu icons and layout That isn' t going to change your SS apks, and put it all in the library project.
Code that isn't going to change much shocould also go in the library project. You'll likely find yourself extending these classes to add a method or two from APK to APK.

If, on the other hand, you're creating the application from scratch, try as much as possible to write code in the Library Project
First, Then only move it down to an individual APK if necessary. this is much easier to manage in the long run than adding it to one, then another, then another, then months later trying to figure out whether this blob can be moved up to the library
Section without screwing anything up.

Create new APK Projects

There shoshould be a separate Android project for each APK you're going to release. for easy organization, place the library project and all related APK projects under the same parent folder. also remember that each APK needs to have the same package name,
Although they don't necessarily need to share the package name with the library. If you were to have 3 apks following the scheme described earlier, your root directory might look like this:

alexlucas:~/code/multi-apks-root$ lsfoo-bluefoo-greenfoo-libfoo-red

Once the projects are created, add the library project as a reference to each APK project. if possible, define your starting activity in the library project, and extend that activity in your APK project. having a starting activity defined in the library
Project gives you a chance to put all your application initialization in one place, so that each individual APK doesn't have to re-implement "universal" tasks like initializing analytics, running licensing checks, and any other initialization procedures that
Don't change much from APK to APK.

Adjust the manifests

When a user downloads an application which uses multiple apks through Google Play, the correct APK to use is chosen using some simple rules:

• The manifest has to show that participant APK is eligible
• Of the eligible apks, highest version number wins
• IfAnyOf the texture formats listed in your APK are supported by the device on market, that device is considered eligible

With regards to GL textures, that last rule is important. It means that you should, for instance, be
VeryCareful about using different GL formats in the same application. if you were to use powervr 99% of the time, but use etc1 for, say, your splash screen... then your manifest wowould necessarily indicate support for both formats. A device that
OnlySupported etc1 wocould be deemed compatible, your app wocould download, and the user wocould see some thrilling crash messages. the common case is going to be that if you're using multiple apks specifically to target different devices based on Gl texture
Support, it's going to be one texture format per APK.

This actually makes texture support a little bit different than the other two multiple APK dimensions, API level and screen size. any given device only has one API level, and one screen size, and it's up to the APK to support a range of them. with textures,
The APK will generally support one texture, and the device will support authentication. There will often be overlap in terms of one device supporting paiapks, but the solution is the same: Version codes.

By way of example, take a few devices, and see how to define the apks defined earlier fit each device.

Foophone	Nexus S	Evo
Etc1	Etc1	Etc1
	Powervr	ATI TC

Assuming that powervr and ATI formats are both preferred over etc1 when available, than according to the "highest version number wins" rule, if we set the versioncode attribute in each APK such that red ≥green ≥blue, then both red and green will always
Be Chosen over Blue On devices which support them, and shocould a device ever come along which supports both red and green, red will be chosen.

In order to keep all your apks on separate "tracks," It's important to have a good version code scheme. the recommended one can be found on the version codes area of our developer guide. since the example set of apks is only dealing with one of 3 Possible
Dimensions, it wocould be sufficient to separate each APK by 1000 and increment from there. This might look like:

Blue: 1001,100 2, 1003,100 4...
Green: 2001,200 2, 2003,200 4...
RED: 3001,300 2, 3003,300 4...

Putting this all together, your android manifests wowould likely look something like the following:

Blue:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"    android:versionCode="1001" android:versionName="1.0" package="com.example.foo">    <supports-gl-texture android:name="GL_OES_compressed_ETC1_RGB8_texture" />    ...

Green:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"    android:versionCode="2001" android:versionName="1.0" package="com.example.foo">    <supports-gl-texture android:name="GL_AMD_compressed_ATC_texture" />    ...

Red:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"    android:versionCode="3001" android:versionName="1.0" package="com.example.foo">    <supports-gl-texture android:name="GL_IMG_texture_compression_pvrtc" />    ...

Go over pre-launch Checklist

Before uploading to Google Play, double-check the following items. Remember that these are specifically relevant to multiple apks, and in no way represent a complete checklist for all applications being uploaded to Google Play.

• All apks must have the same package name
• All apks must be signed with the same certificate
• Double check your manifest filters for conflicting information (an APK that only supports cupcake on xlarge screens isn't going to be seen by anybody)
• Each APK's manifest must be unique guest ss at least one of supported screen, OpenGL texture, or platform version
• Try to test each APK on at least one device. barring that, you have one of the most customizable device emulators in the business sitting on your development machine. Go nuts!

It's also worth inspecting the compiled APK before pushing to market, to make sure there aren't any surprises that cocould hide your application on Google Play. this is actually quite simple using the "aapt" tool. aapt (the android asset packaging tool) is
Part of the build process for creating and packaging your android applications, and is also a very handy tool for inspecting them.

>aapt dump badgingpackage: name='com.example.hello' versionCode='1' versionName='1.0'sdkVersion:'11'uses-permission:'android.permission.SEND_SMS'application-label:'Hello'application-icon-120:'res/drawable-ldpi/icon.png'application-icon-160:'res/drawable-mdpi/icon.png'application-icon-240:'res/drawable-hdpi/icon.png'application: label='Hello' icon='res/drawable-mdpi/icon.png'launchable-activity: name='com.example.hello.HelloActivity'  label='Hello' icon=''uses-feature:'android.hardware.telephony'uses-feature:'android.hardware.touchscreen'mainsupports-screens: 'xlarge'supports-any-density: 'true'locales: '--_--'densities: '120' '160' '240'

When you examine aapt output, be sure to check that you don't have conflicting values for supports-screens and compatible-screens, and that you don't have unintended "uses-feature" values that were added as a result of permissions you set in the manifest.
In the example above, the APK will be invisible to most, if not all devices.

Why? By adding the required permission send_sms, the feature requirement of Android. hardware. telephony was implicitly added. since most (if not all) xlarge devices are tablets without telephony hardware in them, Google Play will filter out this APK in these
Cases, until future devices come along which are both large enough to report as xlarge screen size, and possess telephony hardware.

Fortunately this is easily fixed by adding the following to your manifest:

<uses-feature android:name="android.hardware.telephony" android:required="false" />

Theandroid.hardware.touchscreenRequirement is also implicitly added. If you want your APK to be visible on TVs which are non-touchscreen devices you shoshould Add the following to your manifest:

<uses-feature android:name="android.hardware.touchscreen" android:required="false" />

Once you 've completed the pre-launch checklist, upload your apks to Google Play. it may take a bit for the application to show up when browsing Google Play, but when it does, perform one last check.