Good to hear of a race condition affecting the Droid's camera http://code.google.com/p/android/issues/detail?id=5090 even though in my code I do not call camera.stopPreview() before camera.takePicture ().
It reminds of an old issue reported with the G1/ADP1 when calling camera.release() right after camera.stopPreview() http://code.google.com/p/android/issues/detail?id=1553 Thanks On Dec 1, 3:29 pm, Jarcikon <jarci...@gmail.com> wrote: > Mark, > > I noticed on the bug report you filed that it was stopPreview that was > causing the problem. Apparently, this should not be called before > takePicture or else it causes a problem. > > I was also having an issue on the Droid with taking a picture, and I > was calling stopPreview before takePicture. I have yet to test my > corrected app on a Droid, but I thought it should be here for anyone > else with this issue that didn't see the bug report. > > Mike > > On Nov 29, 12:28 am, blindfold <seeingwithso...@gmail.com> wrote: > > > > Every line of code in every Android application is inside *some* callback. > > > onCreate() is a callback. onClick() is a callback. And so on. Hence, it is > > > impossible *not* to call camera.startPreview() from a callback, AFAICT. Or > > > am I missing something? > > > You are right, I was too conservative here in keeping stuff outside > > developer-specified callbacks under Android, a habit that grew in part > > from programming under multiple OS's where for instance for Windows > > Mobile one reads for void CALLBACK waveOutProc() "Applications should > > not call any system-defined functions from inside a callback function, > > except for ..."http://msdn.microsoft.com/en-us/library/aa910186.aspx > > > However, apart from what *should* work under Android, there have been > > quite some issues with implementations of the Camera part of Android, > > includinghttp://groups.google.com/group/android-developers/browse_thread/threa...such > > that > > for me that finally made a pragmatic reason to really take only one > > small step at a time wherever I can with any of the camera functions, > > for lack of trust in stability. I'm sure some of my safeguards are > > indeed redundant. > > > Regards > > > On Nov 29, 12:06 am, "Mark Murphy" <mmur...@commonsware.com> wrote: > > > > > I am not familiar with the semantics of some of the constructions that > > > > you use, but your use of AsyncTask() makes me wonder if you have > > > > safeguarded (e.g. copied) the image data[] by the time that > > > > onPictureTaken() returns, because image data[] has no guaranteed > > > > lifetime beyond that. > > > > Now that's an interesting point. I think my crash happens before then, > > > though, but it's something I should take care of. I'll give this a shot in > > > the next day or two. > > > > > I would also not have put the camera.startPreview() preview restart > > > > inside the onPictureTaken() callback, because typically one is not > > > > allowed to put system-related function calls inside callbacks. > > > > Every line of code in every Android application is inside *some* callback. > > > onCreate() is a callback. onClick() is a callback. And so on. Hence, it is > > > impossible *not* to call camera.startPreview() from a callback, AFAICT. Or > > > am I missing something? > > > > Thanks! > > > > -- > > > Mark Murphy (a Commons Guy)http://commonsware.com > > > Android App Developer Books:http://commonsware.com/books.html > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
