How to find out screen status: active/dark?

by JP » Fri, 29 May 2009 10:28:32 GMT


Sponsored Links
 I've dug through the documentation but couldn't find a call that would
fit: Is there a way to find out the screen status (Active/dark)?

Thanks in advance!

P.S.
Here's the situation: I've got an app that implements the relevant
data processing and backend server connectivity through a Service that
I keep running on a reduced activity level when the user puts the
device to sleep (using end button), or when the screen timeout hits.
In the app code, I can follow this status change, because it triggers
calls to overloaded onStop() and onPause() methods of the app's
subclassed Activity. This way, I control active/reduced ("sleep")
activity levels of that Service. Everything's cool and dandy in this
scenario.

Enter an AppWidget that's using this Service in a similar fashion,
with functionality implemented in a subclass of AppWidgetProvider.

This changes the game - I have found no way to determine when to set
the Service to the reduced ("sleep") activity level from that point.
The app's Activity has long paused, and I keep the Service at active
level, as the widget needs updates from the Service similar to what
the Activity needs when in front. With the AppWidget on the home
screen, I want, and should (re: battery life), drop the Service's
activity level when the device enters sleep mode. The most elegant way
to handle this would be to detect whether the screen is dark, right
inside the Service. Any way to do this?

JP


--~--~---------~--~----~------------~-------~--~----~



How to find out screen status: active/dark?

by Jeff Sharkey » Sat, 30 May 2009 02:38:27 GMT


 > I've dug through the documentation but couldn't find a call that would

You can listen for Intent.ACTION_SCREEN_OFF and ACTION_SCREEN_ON
broadcasts.  However, I would strongly recommend registering for these
dynamically at runtime using Context.registerReceiver().  This ensures
that you'll only receive the broadcasts if your Service is already
awake, which is what you want.  :)


-- 
Jeff Sharkey
jshar...@android.com

--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


How to find out screen status: active/dark?

by clemsongrad » Sat, 30 May 2009 04:37:51 GMT


 Jeff,

What would the behavior be if you registered the broadcast receiver
and listed these intents in the manifest?

Would the run time start the service to invoke the onReceive()
method?   If so this is a great tip for optimization.

Thanks



--~--~---------~--~----~------------~-------~--~----~



How to find out screen status: active/dark?

by JP » Sun, 31 May 2009 09:54:19 GMT


 Got it, thank you; works perfectly.




--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. There is a typo in system/core/rootdir/etc/init.goldfish.sh

Hello Google developers,

There is a TYPO in system/core/rootdir/etc/init.goldfish.sh:

qemud=`getprop.ro.kernel.android.qemud`
if test -z "$qemud"; then
    radio_ril=`getprop ro.kernel.android.ril`
    if test -z "$radio_ril"; then
        # no need for the radio interface daemon
        # telephony is entirely emulated in Java
        setprop ro.radio.noril yes
        stop ril-daemon
    fi
fi

Please change the line qemud=`getprop.ro.kernel.android.qemud` to
qemud=`getprop ro.kernel.android.qemud`.





--~--~---------~--~----~------------~-------~--~----~

2. Camera Object in Video Capture Case

Hi,

In the cupcake baseline and beyond, the potential exists for an
application to create and configure a Camera object and then pass that
object to the media recorder to be used to deliver preview frames to
be encoded into a video file.  This is fine except for the fact that
the media recorder does a "reconnect" to the Camera object, thus
seemingly disconnecting the application from the camera object.

Does this "reconnect" prevent the application from any further
interaction with the camera device?

I'm pretty sure, but please correct me if I'm wrong, that at a minimum
the "reconnect" will prevent the application from being able to
receive any callbacks that may be of interest.  For instance, say an
implementation adds a new capability to the camera interface which
includes a callback to denote completion of a requested task.  When
the camera object is passed off to the media recorder the Application
seems to be losing access to these expanded features that maybe
desired during the capture of the video.  We have such an enhancement
planned, but I don't feel comfortable disclosing the details in a
public forum.

It would seem more appropriate, at least in my case, that the media
recorder "reconnect" be changed to a very specific "request frames"
call which would not take over all of the potential callbacks that
could occur, but simply tell Camera Services that the video engine
requests the preview frames.  With this Camera Services could continue
to service the application as it does when no video record use case is
running.  The addition would be that Camera Services would also have
an additional client to pass frames to, the video engine.  When Camera
Services receives a preview frame from HAL it would pass it to the
Surface Flinger, potentially pass it to the application (when
requested), and potentially send it to the video engine (also, when
requested).

In the case where the application does not provide a Camera object the
media recorder would still have to create it's own camera object.
That's a hook that seems very clean and clearly needed.

Comments?

Thanks,

Steve.

--~--~---------~--~----~------------~-------~--~----~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: 

3. Video record frame rate

4. can i add a click listener to a drawable?

5. how to make multiple .so files from one Android.mk

6. Crash of my application on startup

7. Can some one tell me how to make music player recognize the AAC file?