三星 Galaxy Tab 7.0 从相机意图返回后重新启动应用程序
我的代码在较小和较大的设备(Motorola Xoom、Samsung Galaxy Player 4.0、Kyocera Digno)上按预期工作,但对于 Samsung Galaxy Tab 7.0,在启动 ACTION_IMAGE_CAPTURE
意图并拍照后,当应用程序返回 onDestroy()
被调用,然后是 onCreate()
,然后 onActivityResult()
被调用,最后,onDestroy()
和 onCreate()
又被调用,这当然是不可取的——只有 onActivityResult()
应该被调用。
可能的线索:
- Galaxy Tab 7.0 的屏幕尺寸在清单文件中明确不受支持(这是我测试过的唯一一款屏幕尺寸不受支持的设备),因此用户可以选择 Scretch-to-Fit 或 Zoom-适合。两个 UI 都有相同(不良)的行为。
- 预览图片时,相机活动似乎会切换方向。我的应用程序仅支持纵向模式(编辑:在较小的屏幕上 - 在非超大屏幕上,它支持方向更改)。也许方向的改变正在以某种方式破坏我的活动。
- 我尝试过从不同的意图(电子邮件意图)启动和返回,并且在这种情况下我的应用程序不会被破坏并重新创建。
如果需要更多信息或代码示例,请告诉我。
编辑:问题已缩小到方向变化。根据 Karthik 的回答,设置 android:configChanges="orientation"
可以解决该问题。唯一的问题是,我的应用程序支持在超大屏幕上更改方向。此设置会破坏这些设备上的此功能。我尝试使用 android:configChanges="@string/config_changes"
并根据屏幕尺寸提供不同的字符串,但现在我收到“安装错误:INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION”。据此,Android Activity,如何覆盖manifest的android :configChanges 用Java代码?,没有办法以编程方式设置它。我唯一的选择是手动处理应用程序中的所有方向更改吗?
My code works as expected on smaller and bigger devices (Motorola Xoom, Samsung Galaxy Player 4.0, Kyocera Digno), but for the Samsung Galaxy Tab 7.0, after launching an ACTION_IMAGE_CAPTURE
intent and taking a picture, when the app returns onDestroy()
is called, followed by onCreate()
, then onActivityResult()
is called, and finally, onDestroy()
and onCreate()
are called again, which is of course undesireable - only onActivityResult()
should be called.
Possibles clues:
- The Galaxy Tab 7.0 has a screen size that is explicity not supported in the manifest file (and this is the only device I have tested with an unsupported screen size), so the user may choose scretch-to-fit or zoom-to-fit. Both UIs have the same (bad) behavior.
- The camera activity seems to switch orientation when previewing a picture. My app only supports portrait mode (edit: on smaller screens - on non-xlarge screens, it supports orientation changes). Maybe the orientation change is destroying my activity, somehow.
- I have tried launching and returning from a different intent (email intent), and my app is not destroyed and re-created in that case.
Let me know if more information or a code sample is needed.
Edit: the issue has been narrowed down to the orientation change. As per Karthik's answer, setting android:configChanges="orientation"
fixes the issue. The only problem is, my app supports orientation changes on xlarge screens. This setting breaks this functionality on those devices. I've tried using android:configChanges="@string/config_changes"
and providing a different string depending on the screen size, but now I'm getting an "Installation error: INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION". According to this, Android Activity, how to override manifest's android:configChanges with Java code?, there is no way to set it programmatically. Is my only option left to handle all orientation changes in my app manually?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
你说得对,这是由于方向改变造成的。相机在 Galaxy Tab 中以横向模式工作。
因此,您可以将
android:configChanges="orientation"
添加到清单文件中的
标记中。这可以解决你的问题。从相机返回时不会调用
onDestroy()
和onCreate()
。You are right, it is due to the orientation change. Camera works in Landscape mode in Galaxy Tab.
So you can add
android:configChanges="orientation"
to your<activity>
tag in manifiest file.This would solve your problem.
onDestroy()
andonCreate()
will not be called upon return from camera.我发现我的应用程序重新启动的原因是因为启动相机应用程序时设备内存不足并且操作系统回收了我的主要活动。这不会是一个问题,除非我有一个基于片段的布局,并且一些片段初始化是在
onCreate()
中完成的,无论保存的实例状态如何。这导致自动片段恢复被丢弃,并使应用程序看起来像是从头开始重新启动,而实际上它只是在尝试恢复。例如:
为了解决这个问题,我在 savingInstanceState 不为 null 时跳过了 Fragment 初始化,并确保状态在
onSaveInstanceState()
中正确保存并在onCreate()
中恢复,并实现了onActivityResult()
的正常处理。前任:
I discovered that the reason my app restarts is because the device runs out of memory when starting the camera app and the OS recycled my main Activity. That wouldn't be a problem, except I had a Fragment-based layout and some Fragment initialization was being done in
onCreate()
, regardless of the savedInstanceState. This caused the automatic Fragment restoration to be discarded and made the app look like it was restarting from the beginning when in fact it was just trying to be restored.Ex:
To fix it, I skipped the Fragment initialization when savedInstanceState was not null and made sure that the state was being saved correctly in
onSaveInstanceState()
and restored inonCreate()
, and implemented the normal handling foronActivityResult()
.Ex: