Multiple APK Support（多种apk的支持）

本文是http://wiki.eoeandroid.com/EoeAndroid%E7%A4%BE%E5%8C%BAAndroid_API_Guides%E4%BB%BB%E5%8A%A1

的56号任务！

原文链接http://developer.android.com/intl/zh-CN/guide/google/play/publishing/multiple-apks.html

Multiple APK Support(相同的应用程序有多个APKs支持)

多种apk的支持是一个特点在Google Play，它允许你发布不同的APKs为你的应用匹配不同尺寸的设备。每个APK是您的应用程序的完整和独立的版本，但它们共享同一应用程序在Google Play上市，必须共享相同的包的名称，并签署具有相同的release key。此功能用在您的应用不能通过单一的APK来兼容所有设备的情况。
Android提供了许多的方式，您提供给尽可能多的设备。Android应用程序通常最兼容的设备上运行，用一个单一的APK，通过提供不同的配置替代资源（例如，不同的布局，为不同的屏幕尺寸）和Android系统的设备在运行时选择适当的资源。然而，在少数情况下，一个单一的APK是不能支持所有设备的配置，因为替代资源的APK文件太大（大于50MB）或其他技术的挑战，阻止了一个APK在所有设备上工作。
虽然我们鼓励您开发和发布一个单一的APK，支持尽可能多的设备配置，但是这样做有时是不可能。为了让您的apk尽可能多的支持不同的设备，Google Play允许你发布多种的应用，在相同的应用列表下面。Google Play 然后根据你在每个APK的manifest文件中声明的版本信息，适配出相对应的apk。
通过发布多个您的版本的apks应用，您可以：

*不同的OpenGL纹理压缩格式，支持每个的APK。
*支持APK的每个不同的屏幕配置。
*每个的APK支持不同的平台版本。
目前，这是唯一的设备的特点，Google Play 支持 发布相同的应用程序有多个APKs支持。

注意：只有当你的APK是太大（大于50MB），你应当使用多个APKs支持不同的设备配置。使用单一的APK，以支持不同的配置的设备始终是最好的做法，因为它使简单的应用程序更新的应用的途径和让用户很明白该怎样操作（也让你的开发变的简单，避免开发和发布的复杂性）Read the section below about Using a Single APK Instead to consider your options before publishing multiple APKs.

在发布前注意的内容
在你发布多个apks为同一个应用在Google Play，你必须理解一些关于怎样发布在Google Play上面的工作。
Active APKs
在你发布你的应用（无论是发布的一个或多个APKs）时，你必须“激活”从你的APK（S）apk文件选项卡上面。当你激活的APK，它将会移动一个激活的 APKs列表。这个名单可以让你预览的你即将发布的APK（s）。
如果没有任何错误，任何“active”APK将公布到Google Play，当您单击“Publish”按钮（如果应用程序是未发布的），或当您单击“ 保存 “按钮（如果应用程序已经发布）。

简单模式和高级模式
在Google Play上面提供了两种方式管理你的应用：简单模式和高级模式。你可以通过在Apk上面的选项卡，切换他们。简单的模式是传统的方式发布应用程序，使用一个apk在一次。

在简单模式，只有一个的APK可以激活一次。如果你上传一个新的APK（升级你的应用程序），要想激活升级的应用必须的取消当前的应用（您必须然后单击“ 保存“发布新的APK）。
高级模式允许你激活并发布多个APKs（每个apk都针对不同设备的配置）。然而，有些在清单中声明的规则的要求，是否你将要被允许激活apk。当您激活APK和违反规则之一，你会收到一条错误或警告消息。如果消息是一个错误，你可以不发布，直到你解决这个问题，如果它是一个警告，你可以发布ActiveAPKs，但您的应用程序是否适用于不同的设备可能有意想不到的后果。这些规则更下面的讨论。

怎样让多个APKS工作

Multiple APKs如何工作

使用Google Paly Multiple APKs的概念是，你必须为您的应用程序只是一个entry在Google Play上面，但针对不同的设备可能会下载到一个不同的APK。这意味着：

·你保持产品细节只有一组（应用程序的描述，图标，截图等）。这也意味着你不能收取不同的价格对不同APKs。

·所有的用户只能看到您的应用程序的一个合适它设备的版本，所以它们不会混淆，你可能已经出版的“tablets（平板)”或“手机”。

·所有用户评论是相同的应用程序列表，即使在不同的设备上的是Multiple APKs。

·如果你发布不同版本的Andr​​oid（不同的API级别），then when a user's device receives a system update thatqualifies them for a different APK you've published, Google Play updates the user'sapplication to the APK designed for the higher version of Android。任何系统与应用程序相关的数据将被保留（与正常的使用 single APK应用程序更新是一样的）。

发布多个APKs相同的应用程序，您必须启用高级模式，在您的应用程序的apk文件“选项卡（如在上一节讨论）。一旦在高级模式下，你可以上传，激活，然后发布多个相同的应用程序APKs。以下各节描述更多的是它如何工作的。

支持过滤器

收到每个APK是确定Google PalyAPK的每个舱单文件中的元素指定的过滤器的设备。然而，Google Play允许您发布多个APKs只有当每个的APK使用filter，支持以下的设备特性的variation：

·OpenGL纹理压缩格式

这是基于你的清单文件的<supports-gl-texture>，元素。

例如，开发一个使用OpenGL ES的游戏时，你可以可以提供一个APK为设备支持ATI的纹理压缩和一个独立的APK支持PowerVR的压缩（等等）的设备。

·屏幕尺寸（和可选，屏幕密度）

这是基于你的manifest文件的<supports-screens>或<compatible-screens>元素。你不应该使用这两种元素在同一时刻，你应该在尽可能的情况下只使用<supports-screens>。

例如，您可以提供一个APK的支持小，正常大小的屏幕和其他的APK，支持大型和XLARGE屏幕。

注：Android系统，提供了很强大的支持，为一个APK支持所有的屏幕配置。你应该避免，创建多个APKs到支持不同的屏幕上，除非绝对必要，而遵循的指导，支持多个屏幕，使您的应用程序非常灵活，可以适应所有的屏幕配置的一个单一的APK。

注意：默认情况下，如果你不声明屏幕尺寸属性<supports-screens>元素在默认情况下是“真”。然而，由于android:xlargeScreens属性增加在Android 2.3（API 9级）属性，如果你的应用程序不设置任何android:minSdkVersionorandroid:targetSdkVersionto "9" 或者更高，Google Play将假设它是false。

注意：你不应该把<supports-screens>和<compatible-screens>一起使用。同时使用增加了机会，你会引入一个错误，因为它们之间的冲突。为帮助决定使用哪一个，请阅读Distributing to Specific Screens。如果你不能避免同时使用，be aware that for any conflicts in agreement between agiven size, "false" will win.

·API Level

这是基于您的manifest文件<uses-sdk>元素。你可以使用android：minSdkVersion和android：maxSdkVersion属性来指定不同的API级别的支持。

例如，你可以发布你的应用程序一个APK的支持API level 4 - 7（Android 1.6 - 2.1），使用唯一的API level 4或者更低，如果支持的API level 8及以上（Android 2.2 + ）使用API​的level为8 或者更低。

注意：

oIf you usethis characteristic as the factor to distinguish multiple APKs, then the APKwith a higherandroid:minSdkVersionvalue must have a higherandroid:versionCodevalue. This is also true if two APKs overlap their devicesupport based on a different supported filter. This ensures that when a devicereceives a system update, Google Play can offer the user an update for yourapplication (because updates are based on an increase in the app version code).This requirement is described further in the section below aboutRules for multiple APKs.

o你应该避免使用android：maxSdkVersion在一般情况下，因为只要你正确使用 public API开发您的应用程序，它始终是与未来版本的Android兼容。如果你想发布一个较高的API level不同的APK，你还没有需要到指定的最高版本，假如一个android：minSdkVersion是4，另一个是8，这个设备是8或者更高，那么这个设备将会选择android：minSdkVersion是8的APK。

Othermanifest elements that enableGooglePlay filters—but are not listed above—arestill applied for each APK as usual. However, Google Play does not allow you topublish multiple APKs based on variations of them. Thus, you cannot publishmultiple APKs if the above listed filters are the same for each APK (but theAPKs differ based on other characteristics in the manifest file). For example,you cannot provide different APKs that differ purely on the<uses-configuration>characteristics.

发布multiple APKs的规则
在你发布您的应用程序的multiple APKs之前，你需要了解以下的规则，关于发布multiple APKs如何定义：


相同的应用程序发布的所有APKs你必须有相同的包的名称，并使用相同的证书密钥签署。
每个的APK 必须有一个不同版本的代码，由指定的 android：versionCode属性。
每个的APK 不能完全匹配的配置支持，另外的APK（也就是说，一个apk不能包含支持别的配置的设备）。
That is, each APK must declare slightly different support for at least one of the supported Google Play filters (listed above).


通常情况下，你会区分你的APKs基于一个特定的特性（如支持的纹理压缩格式），因此，每个的APK将申明为不同的设备支持。然而，它确定发布他们的支持略有重叠的多个APKs。当两个APKs做重叠（他们支持一些相同的设备配置），将接收设备属于重叠的范围内具有较高的版本代码（通过定义的APK android：versionCode）。
你不能启动一个新的APK取代一个版本的代码较低。例如，假设你有一个active 的屏幕尺寸小的APK - 正常版本代码是0400，然后尝试更换一个版本代码为0300相同屏幕尺寸的APK。这就出现了一个错误，因为这意味着以前的APK的用户将无法更新的应用程序。
需要一个较高的APK level 必须有一个更高的版本的代码。


这是true的，只有当：1、APKs不同，仅仅根据支持的API的levels（没有其他支持的过滤器， 区分彼此的APKs） 2、APKs时使用另一个支持的过滤器为基础，但有该过滤器内的APKs之间的重叠。


这是重要的，因为用户的设备收到来自谷歌的应用程序更新版本的代码只有Google play的APK高于目前在设备上的APK版本。这将确保，如果设备收到一个系统的更新，然后限定它以较高的API级别的APK安装，设备接收应用程序更新，因为该版本代码增加。


注：该版本的代码增加的大小是无关紧要的，它只是需要在更大的版本，支持更高的API levels。
下面是一些例子：
1、If an APK you've uploaded for API levels 4 and above (Android 1.6+) has a version code of 0400, then an APK for API levels 8 and above (Android 2.2+) must be 0401 or greater. In this case, the API level is the only supported filter used, so the version codes must increase in correlation with the API level support for each APK, so that users get an update when they receive a system update.
2、If you have one APK that's for API level 4 (and above) and small - large screens, and another APK for API level 8 (and above) and large - xlarge screens, then the version codes must increase. In this case, the API level filter is used to distinguish each APK, but so is the screen size. Because the screen sizes overlap (both APKs support large screens), the version codes must still be in order. This ensures that a large screen device that receives a system update to API level 8 will receive an update for the second APK.
3、If you have one APK that's for API level 4 (and above) and small - normal screens, and another APK for API level 8 (and above) and large - xlarge screens, then the version codes do not need to increase in correlation with the API levels. Because there is no overlap within the screen size filter, there are no devices that could potentially move between these two APKs, so there's no need for the version codes to increase from the lower API level to the higher API level.


如果，未能遵守上述规则将会在Google Play上出现错误，要想激活您APKs，直到你解决这个错误，否者您将无法发布您的应用程序。


还有其他您激活您的APKs时可能发生的冲突，但是这将导致警告，而不是错误。警告，可以由以下原因引起：


1、当你修改的APK设备的特点，并没有其他APKs支持的??设备，然后属于支持的范围以外的“缩水”的支持。例如，如果目前的APK支持small和normal大小的屏幕，你改变它仅支持small屏幕，那么你已经减少了对设备的支持 ，在Google Play一些设备将再也看不到你的应用程序。您可以通过增加另外的APK，支持正常大小的屏幕 ，这样所有设备便支持了，这个问题便得到了解决。
2、当有两个或更多APKs之间的“重叠”。例如，如果支持的APKsizes small, normal, and large，而另外的APK支持large和XLARGE，有重叠，因为两个APKs支持large。如果不解决这个问题，那么large 设备都将收到的z这两个APK具有最高的version code。
当发生这种冲突时，你会看到一条警告消息，但仍然可以发布您的应用程序。

创建 Multiple APKs

一旦你决定发布 Multiple APKs，你可能需为每个发布的应用，要创建单独的Andr??oid项目，可以适当分开开发的APK。你可以通过简单的复制现有的项目，并给它一个新名称。（另外，你可能会使用 build系统，可以输出为不同的资源 -如textures --根据不同build的配置。）
提示：一种方式，以避免重复您的应用程序代码的大部分是使用 library project。 library project.持有共享代码和资源，其中可以包括在您的实际应用项目。
相同的应用程序创建多个项目，这是一个好的做法，以确定每个人的名字，表示设备上的APK限制，所以你可以很容易地识别它们。例如“HelloWorld_8”可能是API 8级及以上的设计了一个应用程序的一个好名字。
注：相同的应用程序发布的所有APKs 必须具有相同的包的名称，并使用相同的证书密钥签署。可以肯定你也了解每个多APKs规则。
指定版本的代码
每个相同的应用程序的APK，必须有一个独特的 version code,，通过指定的android:versionCode属性。当你发布multiple APKs ，一定要小心的指定version code,，因为他们每个人都必须是不同的，但在某些情况下，必须或应该被定义在一个特定的顺序，根据配置每个APK的支持。
定制version code
通常需要较高的API级别的APK必须有一个更高的版本代码。例如，如果您创建两个APKs以支持不同的API级别，较高的API级别的APK必须有更高版本的代码。这将确保，如果设备receiver系统的更新，然后限定它以较高的API级别安装的APK，用户接收到一个更新的应用程序的通知。如何为更多的信息关于怎样要求apples，请参阅上面有关节多个APKs规则。
你也应该考虑版本代码的顺序如何，可能会影响它的APK用户收到任何因重叠覆盖的不同APKs或未来的变化，你可能使你的APKs。
例如，如果你有不同APKs根据屏幕上 size, such as one for small - normal and one for large - xlarge，但预见到的时候，你会改变的APKs是一个为小型和一个normal - XLARGE，然后你应该做的大版本的代码 - XLARGE的APK是较高的。这样，一个正常大小的设备将得到相应的更新，当你做出改变，因为版本的代码增加从现有的APK新的APK，支持现在的设备。
此外，创建多个不同根据不同的OpenGLtexture compression formats的支持AmultiplePKs时，要知道，许多设备支持多种格式。由于设备接收到的APK时有重叠覆盖两APKs的最高版本的代码，你应该之间的APKs order版本的代码，以便，首选的压缩格式的APK具有最高的版本代码。例如，您可能要执行单独的版本，您的应用程序使用的PVRTC，ATITC，和ETC1压缩格式。如果你喜欢这些格式，在这个确切的顺序，然后PVRTC应当是高版本的代码，接着ETC1应该是最低版本的代码。因此，如果设备支持PVRTC和ETC1，它接收PVRTC的APK，因为它具有最高的版本代码。
使用一个版本的代码scheme
为了让不同APKs以更新其版本他人的独立代码（例如，当你修复了一个bug仅为一个apk，并不需要更新所有APKs），你应该使用scheme 为您的版本的代码，它提供的计划足够的空间，使彼此之间的APK可以增加一个代码，而不需要增加在其他。你还应该包括你的代码的实际版本的名称（就是，用户可见的分配机android：versionName），所以很容易为您关联的版本代码和版本名称。
注意：当您增加的APK版本的代码，Google Play 会提示用户以前的版本更新程序。因此，为了避免不必要的更新，你不应该增加为APKs版本代码，。
我们建议用至少7位数的版本代码：interger表示支持的配置，是在更高的序位，the lower order bits的名称（从android：versionName）。例如，当应用程序版本的名称是3.1.0版本的代码，API level 4的APK和API level 11的APK ，分别为0400310和1100310类似。前两个数字是该API的等级（4和11，分别）保留的中间2位是无论屏幕大小或的GL纹理格式（在这些例子中不使用），个数字为应用程序的版本名称（3.1.0）。图1显示了两个例子，基于两个平台版本（API level），屏幕尺寸size。




图1 一个版本代码的建议方案，使用API级别的前两个数字，第二和第三位的最大和最小的屏幕尺寸（1 - 4表示四个zizes）或者表示 the texture formats ，应用程序版本的最后三个数字。

这个版本的代码的计划仅仅是一个建议，你应该如何建立一个模式，它是可变化的， 为你你的应用程序的evolves。特别是，这个计划并没有提出解决、确定不同的纹理压缩格式的方案。可One option might be to define your own table that specifies a different integer to each of the different compression formats your application supports (for example, 1 might correspond to ETC1 and 2 is ATITC, and so on).
您可以使用任何你想要的方案，但您应该谨慎考虑您的应用程序的未来版本将需要增加他们的版本代码，并可以接收设备如何更新设备配置更改（例如，由于系统更新）时，或当修改配置为了 一个或几个APKs的支持。
Using a Single APK Instead
创建多个APKs发布在Google Play上面是个不正常的步骤。在大多数情况下，你应该大多数发布您的应用程序，是一个单一的APK，我们鼓励你这样做。当你遇到一个情况，在一个单一的APK变得很困难，你应该仔细考虑所有的选择，然后才决定发布多multiple APKs。
首先，只发布 一个single APK，遍支持所有设备的几个关键的好处：
发布和管理您的应用程序更容易。
只有一个APK的担心在任何特定时间，你不太可能成为混淆APK是什么。你也没有保持跟踪多个版本的代码，每个机构APK-只使用一个APK的，你可以简单地增加与每个发行版本的代码完成。

你需要管理只有一个的代码库。
虽然你可以使用一个library project 多个Android项目之间共享代码，它仍然有可能在每个项目中，你会重现一些代码，这可能会变得难以管理，尤其是在解决Bug。
您的应用程序能够适应设备配置变化。
通过创建一个单一的APK，其中包含所有的资源为每个设备配置，应用程序可以适应配置在运行时发生的变化。例如，如果用户docks 或其他手机设备连接到一个更大的屏幕，还有一个改变，这将调用系统配置的变化，以支持更大的屏幕。如果你有不同的屏幕配置在相同的APK的所有资源，那么你的应用程序将为新的interface加载替代资源和优化用户体验。
App restore across devices just works.
If a user has enabled data backup on his or her current device and then buys a new device that has a different configuration, then when the user's apps are automatically restored during setup, the user receives your application and it runs using the resources optimized for that device. For example, on a new tablet, the user receives your application and it runs with your tablet-optimized resources. This restore process does not work across different APKs, because each APK can potentially have different permissions that the user has not agreed to, so Google Play may not restore the application at all. (If you use multiple APKs, the user receives either the exact same APK if it's compatible or nothing at all and must manually download your application to get the APK designed for the new device.)
以下各节描述了一些其他的选项，在你决定发布multiple APKs支持不同配置的设备。
支持multiple GL textures
为了一个apk支持multiple GL textures，您的应用程序应该查询设备支持的GL纹理格式，然后使用appropriate（合适）的资源，或从Web服务器上下载。例如，为了保持你的APK体积小，可以查询不同的GLtextures格式的设备的支持，应用程序启动时第一次，然后只下载你需要该设备的textures。
为了获得最大的性能和兼容性，只要不影响视觉质量,应用程序应该使用ETC1 textures。然而，因为ETC1不能色度的急剧变化，如 line art 和 文本（大多数），图像处理，不支持Alpha，它可能不是最好的纹理格式。
单一的APK，你应该尝试使用ETC1 textures和未压缩的textures,只要合理，当使用ETC1不满足使用的需求时，考虑使用的PVRTC，ATITC，或DXTC。
下面是支持纹理压缩格式，从里面例如查询 GLSurfaceView.Renderer的：

public void onSurfaceChanged(GL10 gl, int w, int h) {
    String extensions = gl.glGetString(GL10.GL_EXTENSIONS);
    Log.d("ExampleActivity", extensions);
}

这将返回一个字符串，它列出了每个支持的压缩格式。

支持多个屏幕
除非你的APK文件超过Google Play50MB大小的限制，支持多个屏幕应该始终做一个单一的APK。由于Android 1.6，Android系统的管理大部分各种屏幕尺寸和密度上所需的工作,以支持你的应用在不同设备下运行。
为了进一步优化您的应用程序，在不同屏幕尺寸和密度上运行，你应该提供alternative resources ，在不同的分辨率和不同屏幕尺寸的不同布局设计，如位图的drawable。
欲了解更多有关如何支持多个屏幕上用一个单一的APK信息，请阅读Supporting Multiple Screens.。
此外，你应该考虑使用兼容包支持库，使您可以添加您的活动设计的Framents，以便支持在更大的屏幕上运行 如tablets。

支持多种API的levels

假如你想尽可能多的支持android的不同的平台，你应当使用APIs可以用的最低version。比如，你的应用可能要求APIs的version高于2.1（API level 7），他将要大约支持超过95%的android设备。（。。。。）
通过使用一个支持库兼容性软件包，你也可以使用一些最新的版本（如Android 3.0）的API，同时还支持Android 1.6的低版本。支持库包括APIFragments, Loaders, and more。使用Fragment API是特别有价值的，这样可以优化你的用户界面，为大型设备，如tables。

另外，如果你想使用一些API，只有在新版本的Andr​​oid 有的api（那些你没有仍然支持的功能），那么你应该考虑使用reflection。通过使用reflection，你可以检查当前设备是否支持某些API。如果API是不可用，您的应用程序可以正常 disable and hide 功能。
只有当运行一个版本，支持他们使用新的API的另一种方法是检查当前设备的API级别。也就是说，你可以查询的这个SDK_INT，和创建不同的代码路径，取决于设备所支持的API级别。例如：

if (android.os.Build.VERSION.SDK_INT >= 11) {
    // Use APIs supported by API level 11 (Android 3.0) and up
} else {
    // Do something different to support older versions
}