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. Memory overcommit

Hello,

I was rather startled recently to notice that the standard Android
kernel appears to have the memory overcommit setting set to 1. This is
--- as far as I can tell, the numbering got changed not long ago and not
all the documentation has been updated --- these means 'allow all memory
allocations even if no RAM+swap is available'.

The knock on effect of this is that running out of memory will cause
either a memory trap in the application or else the OOM killer will nuke
your entire process without warning.

Can anyone comment on this? I know, for example, that the Android patch
has modified the OOM killer. I would have thought that memory overcommit
should be disabled on this kind of embedded device?

-- 
€€  €€€€€ http://www.cowlark.com €€€€€
"They laughed at Newton. They laughed at Einstein. Of course, they
also laughed at Bozo the Clown." --- Carl Sagan


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

2. detachViewFromParent / attachViewToParent /removeViewAt --- ViewGroup

Thanks Romian for a quick reply. As I already mentioned in my previous mail
I have to swap the child to be deleted with the last child for my
pagination. In fact I am fixing the positions for each child in the layout.
 As I want to add the last child in place of the child to be deleted I dont
think I can call addView before removing the child first. But once I
call removeView the entire tree structure is changed.











-- 
G . chandra mouli

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

3. detachViewFromParent / attachViewToParent /removeViewAt --- ViewGroup

4. detachViewFromParent / attachViewToParent /removeViewAt --- ViewGroup

5. EditText Focus Color-How to set ColorStateList

6. Write text in horizontal

7. download and parse large zipped XML - too slow!