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
-~----------~----~----~----~------~----~------~--~---

Reply via email to