Fwd: Power button functionality (sleep/resume/wakeup)

by Ashwin Bihari » Fri, 26 Feb 2010 21:41:37 GMT


Sponsored Links
 To list

-- Ashwin




---------- Forwarded message ----------
From: Ashwin Bihari <abih...@gmail.com>
Date: Fri, Feb 26, 2010 at 8:38 AM
Subject: Re: [android-porting] Re: Power button functionality
(sleep/resume/wakeup)
To: w.sreeka...@gmail.com


Sreekanth,

Yes, the hardware supports it and the Kernel does as well. My question
is more towards the Android side of things since I know Linux and the
HW are fine.

Regards
-- Ashwin







-- 



Fwd: Power button functionality (sleep/resume/wakeup)

by Ashwin Bihari » Fri, 26 Feb 2010 21:41:51 GMT


 To list

-- Ashwin




---------- Forwarded message ----------
From: Ashwin Bihari <abih...@gmail.com>
Date: Fri, Feb 26, 2010 at 8:41 AM
Subject: Re: [android-porting] Power button functionality (sleep/resume/wakeup)
To: girish <neo.driz...@gmail.com>


Girish,

No, I don't want the power button to turn the device off, I've already
implemented that at the Kernel level through a different scheme. I
want to invoke the Linux Power Manage suspend and resume functionality
with the power button through Android. If you take any Android phone
right now, there's usually a single button (the top button on the
Motorola Droid for example) that when pressed will put the device to
sleep if it was awake or wake it up if it was asleep. In the sleep
mode the LCD is turned off and the touchscreen doesn't respond to
anything.

It's basically what happens when you let the screen timeout and the
device goes to sleep. The power button allows you to put the device to
sleep faster, and that's the functionality I'm trying to implement.

I have the power button mapped to KeyEvent.KEYCODE_POWER in my Android
build, but that doesn't do anything..

Regards
-- Ashwin







-- 


Sponsored Links


Other Threads

1. ambiguous column name: _id when querying the contacts list

Ouch, there isn't a good solution in the current SDK.  In Eclair we're
restructuring this code, which would break the "people._id" solution
you mentioned.  :(  And you're right, there otherwise isn't a good way
of selecting multiple "_id"s.

Ironically, the same change that breaks the "people._id" approach also
fixes the "_id "ambiguity problem, lol.

I'm afraid the answer is to use "people._id" for now, and update it
when the Eclair SDK is released.

j






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

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

2. Updating Views in a ListView when they may have been recycled

One way of doing this would be to convertView.setTag() to a well-known
value when binding each child item.

Then, when a progress event occurs, use ListView.findViewWithTag() to
find the target View, or fail silently if it doesn't exist.  Each time
a view is recycled, your bind step above would be updating the tag to
match the content.

j






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

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

3. problems purchasing my own app

4. receiver enabled=false , problems after instantiation to set to listen

5. How to build full source for MIPS(e.g:HMP10)

6. About Custom Views

7. Android build fail issue after reverting back to JDK 5.0