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 <pmerl...@googlemail.com> 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
