Thanks for the answers, Mark. You do some good work to educate the Android developers here (including me) :)
Everything else sounds pretty clear, but the incoming network data wakeup is still a bit fuzzy. Consider for example doing a synchronous HTTP request with HttpClient or some other library. Probably you would have to acquire the wakelock for the whole duration of the HTTP request? This makes implementing Comet-style HTTP push tricky. Because the request may take a long time, you don't want to hold the lock for the whole request. But if you don't hold the wakelock, the device could go to sleep even before the request has been sent. I checked the Android EAS implementation that uses Comet-style push, the code can be seen for example here: http://www.google.com/codesearch/p?hl=en#SS2by_AKaLs/src/com/android/exchange/EasSyncService.java&l=1198 The solution there is to release the wakelock just before sending the request, and re-acquire it after the HttpResponse has been received. This apparently works in practice, but I'd really like to understand why it wouldn't fall asleep right after releasing the wakelock. Is there a reason, or is it just relying on good luck? -Heikki On Jun 8, 2:26 pm, Mark Murphy <mmur...@commonsware.com> wrote: > On Mon, Jun 6, 2011 at 4:47 PM,Heikki<heikki.vuolteen...@gmail.com> wrote: > > In general, I've understood that the device can go to sleep at any > > time when the screen is off and no application is holding a wakelock. > > But based on the behaviour I've seen, I believe there are a few cases > > when the platform will hold a wakelock for the application: > > > * When running Activity.onCreate() > > * When running BroadcastReceiver.onReceive() > > > Are my assumptions correct? > > I am not aware of the onCreate() scenario you list above, though it is > plausible, to support incoming phone calls. The onReceive() scenario > is only for AlarmManager and incoming SMS, AFAIK. > > > Are there other places where the platform > > holds a wakelock for the app? > > For incoming data packets over wireless data (not WiFi). I am not > aware of other patterns here. > > > Maybe when executing UI callbacks > > originating from user interaction? > > There would be no need here, as the device will not fall asleep, > because the user interacted with the device. > > > The second thing I'd like to clear up is related to network I/O. I > > understand that incoming data can wake up the CPU from sleep. > > On wireless data. > > > And if you don't acquire a wakelock soon after > > reading the received data, the CPU may go to sleep before your code > > has processed the data. > > Correct. > > > Is the platform holding a wakelock when it reads data from network? > > On wireless data. > > > If yes, when will it release this wakelock? > > Your application should neither know nor care. > > > Is there a grace period after > > data has been received, or how does the platform guarantee the > > application receiving the data has gotten the chance to acquire it's > > own wakelock? > > Ask for a WakeLock right away. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > Android 3.0 Programming Books:http://commonsware.com/books -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
