iOS 应用程序被拒绝 - 私有符号 mach_init_routine
最近,我们的一款应用程序的更新被拒绝,因为我们可能使用私有 API。有趣的是:该应用程序仅包含一个简单的 uiwebview,它加载 sencha touch javascript 应用程序(本地),并且更新仅更改了一些 javascript,根本没有本机代码。
根据要求,苹果透露该应用程序可能使用以下私有符号:
- __keymgr_dwarf2_register_sections
- _cthread_init_routine
- mach_init_routine
因为该应用程序唯一的“手写”代码长约 5 行(获取 html 代码和 baseurl + 将其传递给 uiwebview),我们不知道在哪里这是来自。
任何帮助/提示将不胜感激。
更新:完全不是苹果的错 - 这是 sencha jsbuilder mac 应用程序被意外添加到项目资源中
recently the update to one of our apps was rejected because we possibly use private apis. the funny thing is: the app only consists of a simple uiwebview that loads a sencha touch javascript application (local) and the update only changed some javascript, no native code at all.
upon request apple disclosed that this app possibly uses the following private symbols:
- __keymgr_dwarf2_register_sections
- _cthread_init_routine
- mach_init_routine
as the only 'handwritten' code of this application is ~5 lines long (get html code and baseurl + pass it to the uiwebview) we have no idea where this is coming from.
any help / hints would be greatly appreciated.
UPDATE: Not at all apples fault - it was the sencha jsbuilder mac app that was accidentially added to the projects resources
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
对我来说,这看起来像是低级流程管理的东西。
__keymgr_dwarf2_register_sections
可能与调试有关,尽管一些谷歌搜索表明它可能涉及异常处理。我猜你的新旧版本在编译的一些细节上有所不同:仔细检查你的构建配置和编译器标志,以及编译器和 glibc 版本,特别是调试和异常处理。
您可以尝试使用当前设置将源代码编译为旧版本,然后使用
strings | grep
查看它是否包含任何有问题的符号。如果确实如此,那就是确凿的证据表明构建过程发生了变化。That looks like low-level process-management stuff to me.
__keymgr_dwarf2_register_sections
might be something to do with debugging, although a bit of googling suggests it may be involved in exception handling.I would guess that your old and new versions differ in some detail of the compilation: check your build configuration and compiler flags, and compiler and glibc versions carefully, with particular reference to debugging and exception handling.
You could try compiling the source to the old version with your current setup, and then using
strings | grep
to see if it contains any of the offending symbols. If it does, that's a smoking gun pointing to a change in the build process.