我们有一个应用程序(有适量的字符串),我们将其翻译成27+语言。我们对应用程序进行了2次构建。这两个构建只是包的名称不同。因此,基本上,我们首先用包名(比如com.android.sad.app )构建应用程序,然后再用包名com.android.even.sadder.app构建另一个应用程序。我们有机会在多种安卓设备上测试我们的应用程序,我们发现在一些设备上,如三星ACE、三星Galaxy 或LG Optimus 2 x,我们的应用程序无法加载/读取资源,因此即使应用程序图标也不会显示,当应用程序启动时,应用程序会与android.content.res.Resources.NotFoundException崩溃。在其他设备上,一切都很正常。
我们发现,如果我们减少应用程序资源中的字符串总量,我们的应用程序就可以成功地在上述设备上运行。但是,我们并不认为这是解决问题的真正解决方案,因为资源中包含完整字符串的调试构建可以在所讨论的设备上运行。
所以我的问题是,有人知道什么可能会导致这种非常奇怪的行为吗?
发布于 2011-10-08 07:57:38
经过一些尝试和错误的实验,我们发现问题在于apk包本身。在我们的构建过程中,我们在构建完成之后,但在对apk文件进行签名和对齐之前,向应用程序apk添加了一些文件。最初,我们使用自己的工具提取和重新打包apk (该工具是用Zip编写的,因此使用Zip的Java实现)。
我们已经注意到,在用我们的工具重新打包apk之后,我们能够将apk的大小缩小到由Android构建的原始apk的一半大小。正如我们所发现的,这个重新包装是我们的问题的原因!
我们的实验表明,如果重新包装的apk比~1.6Mb小,那么所有设备都能够读取和使用新重新包装的apk。但是,如果apk的大小超过了~1.6Mb,那么本文中提到的设备(和模拟器)无法正确读取应用程序apk或使用它。
我一直在寻找关于apk文件格式(本质上是jar)的一些规范,但是我没有发现任何可以解释这种非常奇怪的行为的东西。那么,请有人解释一下为什么会发生这种奇怪的行为,确切的原因是什么?
注意:从现在开始,我们将使用Android aapt工具将我们的文件插入到包中,而不是我们一直使用的工具,所有设备都可以读取最终的apk。
发布于 2011-10-04 17:25:05
我会在这里假设很多,但是我会把钱放在它上,因为它与字符串的数量有关。所有的字符串都会消耗内存,也许这些目标设备对您的应用程序没有足够的可用。至于您的包名差异,当然,较短的包所消耗的字节要比较长的字节要少。
我建议您减少使用中的字符串数量,并查看这是否解决了您的问题。
https://stackoverflow.com/questions/7619945
复制相似问题