... I think I don't really understand your stance, so I'll explain my reservations with an example. The motivation for this example is XMPP - the IM I'm using every day with my best friends but I do a little simplification, so as to make the analysis easier. The scenario An applications opens a TCP connection to a server. After the three-way-handshake, in an infinite loop it 1) makes a blocking read() on the socket, waiting for the data sent by the server 2) prints the message sent by the server to stdout The messages are sent by the server in random intervals between 0 and 120 minutes. The problem There are two scenarios available: 1. The application acquires a wakelock. This means that all subsystems are running 24/7, even the touchscreen or the microphone. This means that the applications drains more battery that it would do on a normal computer, as far as I understand 2. The application doesn't acquire a wakelock. This means that it won't work correctly - after some time it will simply stop receiving the messages.
Different problems: Besides, if the whole system is suspended, how can it receive calls in real time? If the whole system is suspended, then the applications handling the calls are suspended too and the GSM radios are suspended as well. And the kernel needs some CPU and RAM to run, and these are suspended as well. Besides, if only the whole system can be suspended, how may be that we can turn the GPS on and off? Disclaimer: this post may be a result of severe misunderstanding on my side, in particular: how is the behavior of the device with `-sdisabled` different from the behavior of a laptop running mainline Linux.