I'd argue that io operations wake the phone. There are hardware wake up gpios that can wake up the phone if there's a signal on one of those and there are wakelocks that are causing wake ups (via power regulator hardware wake up gpio). I'll agree though that every extra operation extends battery usage (including io operations). Unfortunately HDMI message is internal part of our hwcomposer lib and we can't do much about it. Library is looking for ipc service, unfortunatelly this service uses blur framework. It's not related to direct hdmi connection, you could disable hdmi gpio and you would still get this message. It has to be implemented, there's no other way to get rid of that. But if you get it constantly it means that your device is not in real deepsleep mode. In real deepsleep mode all voltage are down, especially CPU and core voltage. So either something is wrong with deepsleep mode settings or there are wakelocks that wake your phone every 2s.
Edit:
From my experience battery drain is resultant of two variables. First one is frequency of wakeups, second one is proper hardware gpio/pinmux/clock/regulators configuration. It's very easy to leave open gpio that drains battery (like sdcard detection gpio). In April/May we were dealing with camera regulator being enabled even though camera wasn't used. Modem can also drain a lot of battery if it's poorly handled. But our worst enemy is wakelock mechanism. There are tons of wakelocks, it's like apps totally ignore system sync option being turned on or off. Even google apps (hangout) sync when syncing is off. I managed to narrow it down a bit using wakelock detector combined with greenify but it's still far from optimal. On GB we had 3-4 wakelocks per hour and on ICS and above we usually have 20 per hour.
Last edited:
