Thanks. OK, that and your interpretation makes sense. Let's go with that.
(In reply to Justin Lebar [:jlebar] from comment #63)
> We haven't really thought about a CPU wake-lock, but at least the screen
> wake lock acts like I was describing here.
CPU power-state locks are part of the motivation for the generic requestWakeLock() API. But maybe I misunderstand your meaning.
> It doesn't look like there's any
> concept of radio wake-locks?
There's a wifi lock [1]. I'm not sure if there's an cellular antenna lock but the same concept applies. IMHO having a uniform interface around power-state locks is preferable to than sticking them on particular sub-APIs (navigator.wifi.requestWakeLock, e.g.).
Thanks. OK, that and your interpretation makes sense. Let's go with that.
(In reply to Justin Lebar [:jlebar] from comment #63)
> We haven't really thought about a CPU wake-lock, but at least the screen
> wake lock acts like I was describing here.
CPU power-state locks are part of the motivation for the generic requestWakeLock() API. But maybe I misunderstand your meaning.
> It doesn't look like there's any
> concept of radio wake-locks?
There's a wifi lock [1]. I'm not sure if there's an cellular antenna lock but the same concept applies. IMHO having a uniform interface around power-state locks is preferable to than sticking them on particular sub-APIs (navigator. wifi.requestWak eLock, e.g.).
[1] http:// developer. android. com/reference/ android/ net/wifi/ WifiManager. WifiLock. html