Events not executing until lock/unlock performed

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a rule that sets the screen brightness to 100 when the power is 
connected. 
2. Create another rule that has a notification of "Screen brightness set to 
100". 
3. Save rule
4. Plug in power cable. 

What is the expected output? What do you see instead?
The expected output is that the screen brightness it updated to 100 per the 
rule set in omnidriod. I see the notification pop up in my notification bar. 
The brightness is not adjusted until i depress hte lock button and then depress 
it again to activate the screen and unlock the phone with the slider. 

What version of the product are you using? On what operating system?
using version 7

Please provide any additional information below.

Ive tried switching the order of the rules but it makes no difference. I can 
reproduce this using a different rule that when the power is disconnected set 
to 10 but it also does to execute until after lock/unlock has occurred. 

Original issue reported on code.google.com by Jonathan...@gmail.com on 6 Oct 2010 at 4:36

[GoogleCodeExporter]

so you're saying when you plugged in the charger, screen was NOT locked but 
brightness still wasn't set. does this happen if you have only one rule? 

Original comment by sv767%ny...@gtempaccount.com on 6 Oct 2010 at 4:54

[GoogleCodeExporter]

yes. I start the test with the screen unlocked. Plug in the charger. The screen 
brightness is not changed until after i click the lock button on the phone. 
When i do this the screen is turned of, by design, then i click the button on 
the phone again to unlock and the unlock screen comes up at the correct 
brightness. Currently i only have this rule and the reduce brightness rule 
running. 

Original comment by Jonathan...@gmail.com on 6 Oct 2010 at 5:00

[GoogleCodeExporter]

Confirmed defect using "Power connected"->"Change Screen Brightness".  
Omnidroid said it did it in the logs, but no brightness actually changed.  Once 
I locked the screen though and then went to unlock it, the screen was dimmed.

It looks like we're changing the brightness by changing the system settings 
(from 
http://code.google.com/p/omnidroid/source/browse/trunk/omnidroid/src/edu/nyu/cs/
omnidroid/app/controller/external/actions/OmniActionService.java):

    int brightness = intent.getIntExtra(SetScreenBrightnessAction.PARAM_BRIGHTNESS, 200);
    Settings.System.putInt(getContentResolver(), Settings.System.SCREEN_BRIGHTNESS, brightness);
    ResultProcessor.process(this, intent, ResultProcessor.RESULT_SUCCESS, null);

Which is good, we're specifying it in the settings, but I'm assuming this isn't 
activated immediately, just only once you go to unlock does it check this.

I found an example on the web that might help us do it immediately 
(http://www.tutorialforandroid.com/2009/01/changing-screen-brightness.html):
    try {
      IHardwareService hardware = IHardwareService.Stub.asInterface(
ServiceManager.getService("hardware"));
      if (hardware != null) {
        hardware.setScreenBacklight(brightness);
      }
    } catch (RemoteException doe) {
    } 

Original comment by case.and...@gmail.com on 20 Oct 2010 at 7:52

• Changed state: Accepted

[GoogleCodeExporter]

Salome points out this thread about it not being an API call and may change at 
Google's whim:

http://markmail.org/message/zpsh67wetmgims5b#query:+page:1+mid:42x4boeiboyoiyfg+
state:results

If it works though, it seems like the way to do it until a proper API call is 
available.

Original comment by case.and...@gmail.com on 22 Oct 2010 at 2:33

[GoogleCodeExporter]

I don't quite understand the context here. I was just wondering, is it because 
one rule killed another. For example, the conditions of two rules are both met, 
then the adaptation is undeterministic.

Original comment by andrew...@gmail.com on 31 May 2011 at 9:42

[GoogleCodeExporter]

No.  It has to do with when android updates the screen brightness based on the 
data stored in the system settings.  It doesn't update the hardware 
immediately.  We're setting the system settings (see my first code block), but 
since it doesn't go into effect immediately the result isn't actually visible 
until android decides to update the hardware (after a lock sequeence).  If we 
use the IHardwareService we can issue the hardware to update immediately.

Original comment by case.and...@gmail.com on 11 Jun 2011 at 1:20

[GoogleCodeExporter]

why are you talking to yourself publicly? do you need a hug?

Original comment by salome...@google.com on 11 Jun 2011 at 11:50

[GoogleCodeExporter]

Sure who couldn't use a hug now and then, but "andrew...@gmail.com" isn't 
actually me. :-)

Original comment by case.and...@gmail.com on 13 Jun 2011 at 3:10

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

you guys are funny. I am your group member, just interested in this great 
project :-)

Original comment by andrew...@gmail.com on 13 Jun 2011 at 3:16

[GoogleCodeExporter]

:D:D yeah I see now. Actually I was saying the other day that andrew is the 
most comsci name.

Original comment by salomeju...@gmail.com on 13 Jun 2011 at 6:12

[GoogleCodeExporter]

Oh, it's a different person, I also thought that Andrew was talking to himself!

Original comment by rct...@nyu.edu on 13 Jun 2011 at 2:56