Got it. That's a new requirement. Write up a bug and we'll try to include it in a future release.
On Feb 10, 11:45 am, steve2641 <steve2...@gmail.com> wrote: > Dave, > > I think you are slightly missing my point. This query is not related > to continuous auto focus. Let me try to explain again. > > Say for instance you have a hardware platform with an auto focus > module that requires power to hold the lens in position (except for > the infinity position). When autoFocus() called, the power to the AF > module is enabled and the auto focus algorithm runs moving the lens > until focus is achieved. Assume the lens position is now not in the > infinity position, so in order to maintain the lens position you must > keep the auto focus module powered up. The AF process is complete and > a callback is made to the application to denote the focus status. If > the user now simply releases the half pressed capture key, not > performing a capture, how is the CameraHardwareInterface layer to know > that it should now turn power off to the AF module and let the lens > move back to the infinity position? > > The auto focus module power is not the only thing that gets locked > during the camera key half press. Other algorithms run and lock and > need to be released when the user simply releases the key. > > Steve. > > On Feb 10, 11:30 am, Dave Sparks <davidspa...@android.com> wrote: > > > When you call autoFocus(), you get a callback after focus is completed > > with a success or fail indicator. This is where you would display your > > in-focus indicator in the view finder. If the user releases the > > shutter button, then the app does nothing. If the user presses the > > shutter button, you call takePicture(). > > > We don't have an API that supports continuous auto-focus. This is > > where the user holds the shutter half-down and the lens is > > continuously. This is an enhancement that will probably come in the > > Donuts release. > > > On Feb 10, 8:24 am, steve2641 <steve2...@gmail.com> wrote: > > > > Hi, > > > > I'm trying to understand how to implement a solution for a two stage > > > camera key. There is an "autoFocus()" call in the Java world which > > > translates down to an "autoFocus()" call CameraHardwareInterface. > > > This seems to be the proper place to direct the camera key half press > > > event, but how is the release event of camera key half press > > > communicated down to the CameraHardwareInterface? > > > > A typical scenario for the camera key half press is that a number of > > > algorithms are kicked off and at the completion the results are locked > > > in until either a capture occurs or the user releases the camera key. > > > The case of a capture occuring is handled by the APIs, but again the > > > case where the user releases the camera key does not seems to be > > > considered, or I'm totally missing it :) > > > > One of the more common, and obvious, examples of the use of a camera > > > key half press release event/call is the focus indication. On many > > > cameras, and some mobile devices, when the user half presses the > > > camera key an indication of the focus state is shown in preview > > > window. This indication will often be a small box in the center of > > > the window. While the user continues to hold the camera key in the > > > half pressed state, this indication will stay on the screen. When the > > > user releases the camera key, this indication will disappear. In > > > order to allow this indication to be drawn within the > > > CameraHardwareInterface implementation, as well as to unlock the other > > > less obvious half press features, a half press release event/call is > > > needed. > > > > Thoughts? > > > > Steve.- Hide quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
