By contract, apps are supposed to release the camera in onPause(). Failing to do so could result in the battery draining quickly because we have the DSP and sensor hardware spun up.
The problem that the current design choice introduces is that the camera can be in the middle of any operation when another app "steals" it away. There is no mechanism for returning the camera to a known state or even querying the state so that appropriate steps can be taken to get it to the right state. On Jan 23, 9:39 am, Dianne Hackborn <[email protected]> wrote: > The locking is done that way because as you move through the UI the next > activity receiving focus should be the one to get the camera, as soon as it > comes up. Otherwise if you switch from one activity using the camera > directly to another using the camera, the new one won't be able to access it > because the previous one has not yet had a chance to close it. > > On Fri, Jan 23, 2009 at 9:08 AM, Dave Sparks <[email protected]>wrote: > > > > > > > The camera service has no concept of foreground activity. It simply > > gives the camera to the app that requests it. If another app currently > > owns the camera, it is notified when the camera is stolen. > > > I don't know all the rationale for that design decision. It's probably > > not the way I would have designed it, but I'm not sure that it's > > wrong, either. However, we do need a way to reset the camera to a > > known state when the new owner takes over. > > > Also, there is a new mechanism in Cupcake for sharing a camera between > > two processes. The remote can be passed around and the owner can > > unlock the camera to allow a cooperative use of the camera. This is > > used to switch quickly between still camera mode and video record mode > > (the codecs live in another process and need direct access to the > > camera to get frame buffers). > > > On Jan 23, 6:08 am, Pascal Merle <[email protected]> wrote: > > > Yes, that would be great. > > > > I have been able to test my app running in foreground. In background > > > will be much better. It sometimes just needs to take a snapshot so > > > there is no problem with the battery. > > > > When implementing you have to take care about the locking mechanism. > > > As you know the camera can only be used by the activity shown on > > > screen now (implicitly locked by the preview). I found out however, > > > that this concept is not 100% clean. If your surface got created and > > > you start the preview immediately, without any delay, you can conflict > > > with another app still stopping its preview. So work has to be done on > > > proper locking of the camera anyway. > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
