我们有一个应用程序（有适量的字符串），我们翻译成27种以上的语言。我们制作了2个应用程序版本。这两个版本仅在包名称上有所不同。所以基本上我们首先使用包名称构建我们的应用程序，然后使用包名称为com.android.sad.app，然后使用包名称com.android.even.sadder.app。
我们有机会在各种各样的Android设备上测试我们的应用程序，我们发现在某些设备上，例如三星ACE ，三星Galaxy S 或 LG Optimus 2x 我们的应用程序无法加载/读取资源，因此即使未显示应用程序图标，应用程序启动时也会崩溃android.content.res.Resources.NotFoundException。在其他设备上一切正常。
我们发现，如果我们减少应用程序资源中的字符串总数，我们的应用程序就可以在上述设备上成功运行。但是，我们认为这不是我们问题的真正解决方案，因为可以在相关设备上运行具有资源中完整字符串的调试版本。
所以我的问题是，有人知道什么可能导致这种非常奇怪的行为吗？
答案 0 :(得分：2)
经过一些试验和错误实验后，我们发现问题出在 apk 包本身。在我们的构建过程中，我们在构建完成后但在签署和对齐 apk 文件之前，立即将文件添加到我们的应用程序 apk 。最初我们使用我们自己的工具（用 Java 编写，因此使用 Zip 的Java实现）来提取和重新打包 apk 。 / p>
我们注意到，在使用我们的工具重新打包 apk 后，我们能够将 apk 的大小缩小为一半由 Android版本创建的原始 apk 。 正如我们发现的那样，重新包装是造成我们问题的原因！
正如我们的实验显示重新包装的 apk 小于 ~1.6 Mb ，所有设备都能够阅读并使用新重新包装 apk 。但是，如果 apk 的大小已超过 ~1.6 Mb ，则此帖中提到的设备（和模拟器）无法正确读取或使用该应用程序 apk 。
我一直在寻找关于 apk文件格式（基本上是jar）的一些规范，但我发现没有什么可以解释这种非常奇怪的行为。那么有人可以澄清为什么这种奇怪的行为发生了，原因是什么？
注意：从现在开始，我们使用Android aapt 工具将我们的文件插入到包中，而不是我们一直使用的工具和所有设备都可以读取最终apk
答案 1 :(得分：0)
我会在这里假设很多，但我会把钱与字符串的数量相关联。您的所有字符串都将消耗内存，并且这些目标设备可能没有足够的可用空间。至于你的包名称差异，当然，较短的字节消耗的字节数比较长的字节数要多。
我建议您减少使用中的字符串数量，看看是否能解决您的问题。