Im not sure what was intended in this situation, but the way I
interpreted it was that this is as expected.
If you are resumed because of an RTC alarm (e.g. something wants to
check for updates at a given time), then it will want to go back in to
suspend asap after checking its updates. If you are woken through a
power button press, then your input driver handling the power button
should pass the button press in to the kernel input system. This is how
I handle this. In my keyboard driver's resume handler, if it detects
that we woke up due to power button press, it reports a KEY_POWER press
and release. Android then notices this key press and the power manager
holds its wake lock as usual after a key press.
It would be interesting to hear if this is the intended behaviour.
Regards.
Bob
On 19/04/11 09:13, Ben Dooks wrote:
Using kernel 2.6.37 and android 2.3.2, we are seeing issues
with the first suspend going into an infinite suspend loop
which we now think is due to the init process failing to
echo "on" to /sys/power/state to ensure the main wakelock
is being held.
Is this a bug in kernel, android or a mis-configuration of
the system?
--
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting
