Fundamentally it only makes sense to use one interface to suspend the system. This is basically how powerd decides which to use:
1) If /sys/power/autosleep exists, use autosleep
2) Else if /sys/power/wake_{lock,unlock} exist, use early suspend (note that autosleep also has these nodes, so we can't simply swap 1 & 2 to prefer early suspend)
3) Else assume the legacy /sys/power/state behavior
Not all Android devices use early suspend (e.g. the Nexus 10 uses autosleep), and I had seen public comments that indicated Android was planning to move to autosleep.
From this description here though I get the impression that some device has /sys/power/autosleep but expects to use early suspend, and that makes no sense to me. I seem to recall that having early suspend and autosleep in the same kernel would be impossible because the implementations would conflict with each other. Possibly someone might have added support for early suspend (thus probably breaking autosleep) but still left CONFIG_PM_AUTOSLEEP enabled and ended up with an ineffective autosleep file. In that case, why not disable CONFIG_PM_AUTOSLEEP?
However, if Android has some different mechanism for detecting which interface to use then it might make sense to make powerd compatible. In that case I'd suggest detailing the detection algorithm Android uses (or even better point to the code).
Fundamentally it only makes sense to use one interface to suspend the system. This is basically how powerd decides which to use:
1) If /sys/power/ autosleep exists, use autosleep wake_{lock, unlock} exist, use early suspend (note that autosleep also has these nodes, so we can't simply swap 1 & 2 to prefer early suspend)
2) Else if /sys/power/
3) Else assume the legacy /sys/power/state behavior
Not all Android devices use early suspend (e.g. the Nexus 10 uses autosleep), and I had seen public comments that indicated Android was planning to move to autosleep.
From this description here though I get the impression that some device has /sys/power/ autosleep but expects to use early suspend, and that makes no sense to me. I seem to recall that having early suspend and autosleep in the same kernel would be impossible because the implementations would conflict with each other. Possibly someone might have added support for early suspend (thus probably breaking autosleep) but still left CONFIG_PM_AUTOSLEEP enabled and ended up with an ineffective autosleep file. In that case, why not disable CONFIG_ PM_AUTOSLEEP?
However, if Android has some different mechanism for detecting which interface to use then it might make sense to make powerd compatible. In that case I'd suggest detailing the detection algorithm Android uses (or even better point to the code).