Is this on the emulator or on G1?
On Jan 18, 12:40 pm, Pascal Merle wrote:
> I am standing a bit in the dark with the android.hardware.Camera
> class.
>
> What I tried to do is taking a picture without starting preview first:
> Camera mCamera = Camera.open();
> mCamera.ta
On the G1!
On 20 Jan., 18:22, Dave Sparks wrote:
> Is this on the emulator or on G1?
>
> On Jan 18, 12:40 pm, Pascal Merle wrote:
>
> > I am standing a bit in the dark with the android.hardware.Camera
> > class.
>
> > What I tried to do is taking a picture without starting preview first:
> >
Oh wait, I completely missed the part where you wrote: "without
starting preivew first"
You have to start preview first. In theory, you can call takePicture()
from the first preview callback, or from the auto-focus callback. In
practice, due to a bug in the G1 camera driver, you have to wait for
Please also try to address my last question "Can this be done from
within a service (no activity)?". Since a service does not have a UI I
don't see how I can start a preview from there. I want to take the
picture from the service running in the background.
--~--~-~--~~~
Right now, the answer is no. Most cameras require that you go to
preview mode before you can take a picture so that the image processor
can grab some frames for auto-focus, white balance, etc.
I'll see if we can get a change into Cupcake that allows you to start
preview without a surface. That sh
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
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 des
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
bec
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
9 matches
Mail list logo
