在某些设备上找不到 Android 资源
我们有一个应用程序（具有适量的字符串），我们将其翻译成 27 种以上语言。我们对该应用程序进行了 2 个构建。这两个版本仅在包名称上有所不同。所以基本上我们首先使用包名称构建我们的应用程序，例如com.android.sad.app，然后使用包名称com.android.even.sadder.app构建另一个应用程序代码>. 我们有机会在各种 Android 设备上测试我们的应用程序，我们发现在 Samsung ACE、Samsung Galaxy S 或 LG 等某些设备上Optimus 2x 我们的应用程序无法加载/读取资源，因此即使应用程序图标也不会显示，并且当应用程序启动时它会崩溃android.content.res.Resources.NotFoundException。在其他设备上一切正常。
我们发现，如果我们减少应用程序资源中的字符串总量，我们的应用程序就可以在上述设备上成功运行。然而，我们认为这不是解决我们问题的真正解决方案，因为资源中包含完整字符串的调试构建可以在有问题的设备上运行。
所以我的问题是有人知道什么可能导致这种非常奇怪的行为吗？
We have an application(with moderate amount of strings) which we translate to 27+ languages. We make 2 builds of the application. These 2 builds only differ in the name of the package. So basically we first do a build of our application with package name lets say com.android.sad.app and then another one with package name com.android.even.sadder.app.
We had the chance to test our application on a great variety of Android devices and we have found out that on some devices like Samsung ACE, Samsung Galaxy S or LG Optimus 2x our application can't load/read the resources so even the application icon isn't shown and when the application is started it crashes with android.content.res.Resources.NotFoundException. On other devices everything is working just fine.
We have found out that if we reduce the overall amount of strings in the resources of the application, our application can successfully run on the above mentioned devices. However we do not think this is the real solution to our problem because the debug build with full strings in resources can be ran on the devices in question.
So my question would be does someone knows what can potentially cause this very strange behavior ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
经过一番反复试验，我们发现问题出在 apk 包本身。在我们的构建过程中，我们会在构建完成后、签署和对齐 apk 文件之前立即向应用程序 apk 添加一些文件。最初，我们使用自己的工具（用 Java 编写，因此使用 Zip 的 Java 实现）提取并重新打包 apk。
我们注意到，使用我们的工具重新打包apk后，我们能够将apk的大小减小到原始apk的一半大小 >apk由Android构建创建。
我们发现这个重新打包是导致我们问题的原因！
正如我们的实验所示，如果重新打包的 apk 小于 ~1.6 Mb，所有设备都能够读取并使用新重新打包的 <强>apk。但是，如果apk的大小超过~1.6 Mb，本文中提到的设备（和模拟器）将无法正确读取或使用该应用程序 >apk 。
我一直在寻找有关 apk 文件格式（本质上是 jar）的一些规范，但我没有发现任何可以解释这种非常奇怪的行为的内容。那么有人可以澄清为什么会发生这种奇怪的行为以及确切的原因是什么？
注意：从现在开始，我们将使用 Android aapt 工具将文件插入到包中，而不是我们一直使用的工具，最终的 apk 可以可以被所有设备读取
After some trial and error experimenting we have found out that the problem was with the apk package itself. In our build process we add some files to our application apk right after the build has finished but before signing and aligning the apk file. Originally we were extracting and repackaging the apk with our own tool (which is written in Java and thus using the Java implementation of Zip).
We have noticed that after repackaging the apk with our tool we were able to reduce the size of the apk to half size of the original apk created by the Android build.
As we have found out this repackaging was the cause of our problem!
As our experiments have shown if the repacked apk was smaller then ~1.6 Mb, all devices were able to read and work with the newly repacked apk. However if the size of the apk have exceeded ~1.6 Mb the devices (and the emulator) mentioned in this post were not able to correctly read or work with the application apk .
I have been looking around for some specification on the apk file format(which is essentially jar), but I have found nothing that would explain this very odd behavior. So could somebody please clarify why is this strange behavior happening and what are the exact reasons?
Note: from now on we are using the Android aapt tool to insert our files to the package, instead of the tool we have been using and the final apk can be read by all devices
我会在这里假设很多，但我会把钱花在与弦的数量有关的事情上。您的所有字符串都会消耗内存，并且这些目标设备可能没有足够的内存供您的应用程序使用。至于包名的差异，当然，较短的包名会比较长的包名消耗更少的字节。
我建议您减少使用的字符串数量，看看是否可以解决您的问题。
I'm going to assume a lot here, but I would put money on it being related to the amount of strings. All of your strings will consume memory and maybe these target devices don't have enough available to your application. As for your package name differences, the shorter one will consume less bytes than the longer one of course.
I suggest that you reduce the amount of strings in use and see if that resolves your issues.