Creating Multiple APKs with 2+ Dimensions 创建两种以上屏幕尺寸多apk支持
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 to create multiple APKs of your app, each covering a different class of screen size. 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 across the huge range of available Android devices, naturally you want your application look its best on each individual device. You want to take advantage of the space of large screens but still work on small ones, to use new Android API features or visual textures available on cutting edge devices but not abandon older ones. It may seem at the outset as though multiple APK support is the best solution, but this often isn’t the case. The Using Single APK Instead section of the multiple APK guide includes some useful information on how to accomplish all of this with a single APK, including use of our support library, and links to resources throughout the Android Developer guide.
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 across 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
Start off by creating a 易做图 chart to quickly determine how many APKs you need, and what screen size(s) each APK covers. Fortunately, it’s easy to chart out your requirements quickly, easily, and have an easy reference for later. Let’s say you want to split your APKs across two dimensions, API and screen size. Create a table with a row and column for each possible pair of values, and color in some "blobs", each color representing one APK.
3 4 5 6 7 8 9 10 11 12 +
small
normal
large
xlarge
Above is an example with four APKs. Blue is for all small/normal screen devices, Green is for large screen devices, and Red is for xlarge screen devices, all with an API range of 3-10. Purple is a special case, as it’s for all screen sizes, but only for API 11 and up. More importantly, just by glancing at this chart, you immediately know which APK covers any given API/screen-size combo. To boot, you also have swanky codenames for each one, since "Have we tested red on the ?" is a lot easier to ask your cubie than "Have we tested the 3-to-10 xlarge APK against the Xoom?" Print this chart out and hand it to every person working on your codebase. Life just got a lot easier.
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 reduces the likelihood of mistakes that could have been 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 across APKs, and put it all in the library project. Code that isn’t going to change much should 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 should 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$ ls
foo-blue
foo-green
foo-lib
foo-purple
foo-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 two 易做图 rules:
The manifest has to show that particular APK is eligible
Of the eligible APKs, highest version number wins.
By way of example, let’s take the set of multiple APKs described earlier, and assume that each APK has been set to support all screen sizes larger than its "target" screen size. Let’s look at the sample chart from earlier:
3 4 5 6 7 8 9 10 11 12 +
small
normal
large
xlarge
Since it’s okay for coverage to overlap, we can describe the area covered by each APK like so:
Blue covers all
补充：移动开发 , Android ,
