7

I'm developing a small utility app that scans 2D barcodes, and then submits each barcode to an IntentService where a longer task is performed.

When the activity is shown, it should prevent the device from sleeping, until the barcode is processed in the service. If the service finishes the processing, it stops itself, but the activity should still be visible.

I'd like to hold a SCREEN_DIM_WAKE_LOCK WakeLock during the activity lifecycle, but as this type doesn't prevent the CPU from sleeping, I'd also need to acquire a PARTIAL_WAKE_LOCK in the activity when a new 2D code is scanned, and release it in the intent service after it has been processed.

The SCREEN_DIM_WAKE_LOCK purpose is to avoid the user the inconvenience of pushing the power button each few seconds to wake up the device and be able to read a new barcode. The user will have to read a great number of codes one after another and the activity should be around even for the short intervals where there's no user interaction.

I know in Android there's no 100% guarantee of the app being on top, not closed, or foregrounded due to several conditions my app can't control, but I'd like to go as far as I can.

So it is possible to hold multiple WakeLocks? Where could they be declared to be accesed both by the activity and the service? (Singleton, extending Application?)

Mister Smith
  • 27,417
  • 21
  • 110
  • 193

1 Answers1

10

It is possible to hold multiple WakeLocks. In fact it's done all the time when multiple applications sync at the same time when the screen is off. (Imagine your GMail and Facebook apps sync at the same time when the screen is locked. They don't know about each other will have different WakeLocks. May or may not be different types of WakeLocks)

Android will make sure everyone's expectations are met (maximum battery drain in other words.)

In my opinion, I think you're over-thinking the fact that you need a SCREEN_DIM_WAKE_LOCK as this can accidentally drain a LOT of battery, but I may be wrong depending on your use case.

So the short answer is YES. You can hold multiple WakeLocks and Android will (should) act as expected. Only thing to keep in mind is that you release both Wakelocks properly.

In the issue of getting on top of the screen, I think you should release the WakeLock of your activity when it goes to Paused state (when somehow another activity is on top, or use intentionally press the power button). Because at this point, user is interacting with another app, and you should respect it and let it control its own behaviour. You don't have to give up the partial wake lock from your service until you're done.

Hope This Helps.

Madushan
  • 6,977
  • 31
  • 79
  • +1. But I'm releasing screen WakeLock in `onStop`, because I don't want it to sleep when I push a dialog. – Mister Smith Sep 18 '12 at 12:02
  • I assumed that when a dialog is in front, you're not scanning bar codes any more, because user has to respond to the dialog, Isn't it OK to let the system sleep, if the use doesn't respond to the dialog in time ? – Madushan Sep 18 '12 at 12:07
  • Yes, well it all depends on how long does the sleep timer take. If it takes 3 secs, it is annoying to push the power button. If it takes longer, I'm fine with it. Depending on the work load, I might even dump the screen dim lock. – Mister Smith Sep 18 '12 at 12:38
  • And about the partial wake lock, I'm following commonsguy's `WakefulIntentService` approach, but I don't like the idea of releasing after each `onHandleIntent` call. Shouldn't I release the lock only when the service is about to wait? – Mister Smith Sep 18 '12 at 12:40
  • I'm not familiar with the approach you mentioned. My recommendation is that you should release the WakeLock as soon as your work is done and no pending requests to your service. This allows the phone to go to sleep as early as possible, saving battery. Although keep in mind that releasing a wakelock and going to sleep, then waking up very soon and trying to connect to the network can cost a lot of battery compared to keeping the phone awake and connected. This is because waking up the communication hardware from sleep is more battery expensive than keeping it ON. – Madushan Sep 19 '12 at 03:54