5

I'm working on an android app where I need to get location updates in the background for an extended period of time using the GPS provider, so I need the location udates to occur when the user is no longer interacting with it. I did some testing of my own comparing LocationManager's requestSingleUpdate (the provider, pendingIntent version) and requestLocationUpdates (the provider, minTime, minDistance, intent version). After taking a good bit of data on my Droid Razr HD, it looks like using requestLocationUpdates is significantly more reliable than requestSingleUpdate (for both methods I actually compared the GPS location reported to where I actually was, i.e. not using the reported accuracy, and requestLocationUpdates was not only significantly more accurate as to my actual location, but it returned a location fix time that was the same as the current time far more often then using the requestSingleUpdate option). I know how to use AlarmManager with a repeating alarm and call requestSingleUpdate so that I only need to hold a wakelock each time the the alarm goes off, but because of the increased accuracy of using requestLocationUpdates (at least in my tests on my phone) I would like to use that method instead. My problem is that if I use the requestLocationUpdates method, I am really unclear as to what I have to do in terms of holding a wakelock to keep the updates occuring when the user isn't interacting with the phone. I am calling requestLocationUpdates from a separate thread that is launched from a service (I read that that is the standard pattern). My question is, do I have to hold a wakelock for the entire time that I want location updates to keep coming? If I don't get my own wakelock do the location updates keep coming, waking the phone up for each new update? If this is true, do these updates create their own wakelock, and if so, when do they release the wakelock? I can't seem to find a clear answer on this. Any help is greatly appreciated.

user1057118
  • 51
  • 1
  • 5

2 Answers2

3

No you don't need a wakelock because the OS takes the wakelock for you (code). The wakelock is released when onLocationChange() ends or when your broadcast receiver receives the intent (for the intent version of the interface). You need your own wakelock if you start some async work in onLocationChange() for example with an other thread.

greywolf82
  • 21,813
  • 18
  • 54
  • 108
0

I wrote a flight logging app which also needs update every few seconds to recognize take-oofs and landings. The received data is evaluated in a service. To keep the service alive you will need a WakeLock. I get the lock when the detector (automatically recognizing the relevant events) is started and I release the lock when the user turns the detector off; this is also the life time of the service, so the lock is aquired in onCreate and it is released in onDestroy. I use a SCREEN_DIM_WAKE_LOCK to save some power.

Stefan
  • 4,645
  • 1
  • 19
  • 35
  • Thanks for the tip. I think I might also need to start the service in the foreground because it could run for some time and I need it to stay up. I know that this can potentially be a big battery drain, but I'll just have to test it out because I might have some ways to mitigate the drain with other design decisions. If not, I'll go back to the AlarmManager route using requestSingleUpdates. I wish the android documentation was a little better on this. Seems like you have to piece a lot of information together from may disparate places to see the whole picture. – user1057118 Nov 11 '13 at 01:03
  • Using the Smasung Galaxy Tab 10.1N using the above strategy worked for continuous 6 hours of logging time with about 40% of battery power left. – Stefan Nov 14 '13 at 14:51