Understood your concerns completely.

However, are you sure it has to be so foolproof ?
According to Android reference ( 
http://developer.android.com/reference/android/hardware/SensorManager.html
):
"Always make sure to disable sensors you don't need, especially when
your activity is paused. Failing to do so can drain the battery in
just a few hours. Note that the system will not disable sensors
automatically when the screen turns off."

"System will not disable" means your driver (as part of the system) is
not required to take care about a lousy developer who forgot to
unregister sensor listener.

On the other side, the Sensors framework (and its JNI layer) expects
to get control from the application level therefore you shouldn't try
to change anything from the HAL layer. The software stack should stay
the same, all your driver objects should stay alive but you can
disable actual hardware upon early suspend notification.

I didn't care about such case since it is application developer's
responsibility.

On Dec 21, 8:36 pm, Dharam Kumar <dharam.kumar.gu...@gmail.com> wrote:
> Hi,
> As you asked, let me explain my use case:
> Start the device ---> Launch the sensor app(don't close it) --->let the
> device go in suspend mode(early and  complete suspend both; note that the
> app has not been closed)
>
> "The application should disable sensors event listener, Sensor Manager
> will call your data_close() and everything will be ok."
>
> My point is that i'm not closing my application at all.
> Now, for three exit points in Android : onDestroy(), onPause(),onStop() , it
> is quite possible that the app has not implemented all the 3 exit points.
> As per theory, whenever the app is not visible, it should call onStop().What
> I'm not sure is , when the device goes in early suspend , does the onStop()
> is called for the application automatically? If it is so, fault may be on
> the sensor apps I'm using. (as they might not have implemented OnStop() ).
>
> -regards
> Dharam
>
>
>
>
>
>
>
> On Wed, Dec 22, 2010 at 7:05 AM, ip332 <iprile...@gmail.com> wrote:
> > Sorry, it is not clear what what does your driver do in the first case
> > (error).
>
> > BTW: why do you need the early suspend at all? Android is not a pure
> > Linux so you better start from the application level.
> > The application should disable sensors event listener, Sensor Manager
> > will call your data_close() and everything will be ok.
> > I spent quite a lot of time on sensor driver and don't remember any
> > problems with this approach.
>
> > Regards
> > Igor
>
> > On Dec 20, 9:42 pm, Dharam <dharam.kumar.gu...@gmail.com> wrote:
> > > Hi all,
> > > I'm trying to have my sensor hardware drivers to go in suspend and
> > > resume mode(basically, the suspend and resume functions of sensor
> > > driver)  as the device goes in early suspend(and then complete suspend
> > > mode) and then wakes up.
> > > For my use case, if i keep a  "sensor application" say a proximity
> > > sensor app running and tries to let the device  go in suspend
> > > mode(early and complete suspend both)
> > > then I get an error saying :
>
> > > Restarting tasks ... done.
> > > suspend: exit suspend, ret = -16 (2000-01-01 03:36:58.558319086 UTC)
> > > PM: Syncing filesystems ... done.
> > > Freezing user space processes ...
> > > Freezing of user space  aborted.
>
> > > and the device does not go in "complete suspend" mode.
> > > However, If i use the libraries of <linux/earlysuspend.h> in my driver
> > > code  and register an instance of early_suspend and and map my suspend/
> > > resume functions to the structure early_suspend 's  suspend/resume
> > > functions and register it, the device (with a proximity sensor app
> > > running) goes in suspend and resume mode without any hassles.
>
> > > can anyone explain this behavior of sensor drivers?
> > > -
> > > Best Regards
> > > Dharam
>
> > --
> > unsubscribe: 
> > android-kernel+unsubscr...@googlegroups.com<android-kernel%2bunsubscr...@go 
> > oglegroups.com>
> > website:http://groups.google.com/group/android-kernel

-- 
unsubscribe: android-kernel+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-kernel

Reply via email to