Re: [android-developers] Multiple applications with WakeLock vs. one WakeLock app

[William Kelley]

My question wasn't about battery life, but I'll address it anyway. Users 
who install apps that use long running services are usually fully aware 
that it will affect battery life. Certainly anyone who wants to record a 
GPS track for a few hours with very fine resolution (points every 5 seconds 
say) knows it will kill the battery quickly. But the point is they know 
this and want these apps regardless. You may not personally have a use for 
such services, but others do. My phone wouldn't be interesting, to me, if 
the only thing I focused on was plugging the phone in no more than once a 
day. I have no problem recharging several times a day (especially all the 
time I am driving) so that I can use my phone as a sensor and logger and 
record interesting information. This requires battery, but it is 
information I want.

The question I was trying to ask in this post was really more partly 
practical and partly conceptual. Practically, are there any issues with 
having multiple apps on your phone each implementing their own WakeLocks? I 
currently have three and they don't seem to interfere with each other. 
Which brings me to the question of whether I should implement a WakeLock in 
my own GPS logger app despite the fact I know my phone will never sleep the 
CPU? Now for any potential users of my apps (if I were to release it), I 
would then tell them they had to get a WakeLock app (there is one on the 
market) in order to keep the CPU awake so that my GPS logger will continue 
to record points as long as they like. That may be too much to require of a 
user and implementing my own WakeLock is the easiest solution. But 
conceptually, it seems redundant that every app that wishes to have a long 
running service would have to have its own WakeLock, when only one is 
required. That's why, at least for me and users like me, one WakeLock app 
to rule them all makes a lot of sense.

As for the user, I don't think it's "crazy" at all for them to want to 
control how their phone works. Again, if the user wants the features of 
long running services, why dissuade them? Letting the user choose to have 
the CPU running at all times (partial wake lock) seems completely 
reasonable.


On Sunday, May 13, 2012 3:49:21 PM UTC-7, Dianne Hackborn wrote:
>
> You need to hold a wake lock for any duration when you need to make sure 
> the CPU doesn't go into deep sleep.  It doesn't matter what other 
> applications are doing, for your code to be correct you need to hold the 
> wake lock when your code relies on the CPU being kept running, so the 
> platform knows about this requirement.
>
> If other apps are sitting around holding wake locks all the time, they are 
> also sitting there and draining your battery.  Personally I wouldn't want 
> to have such apps on my device.
>
>  Also it makes no sense to talk about the user deciding when wake locks 
> should be held.  The user decides when they want the screen to be on... 
>  and yes, implicitly, when the screen is on the CPU is kept awake.  But 
> when the screen is off, it would be crazy to have the user doing something 
> to the device every 5 minutes or however often they think the CPU should 
> wake up in order to do some work.
>
> When the screen is off, the CPU is only kept running as long as someone is 
> holding a wake lock to say it needs to be running.  You should only hold a 
> wake lock for as little time as possible, because all the time you are 
> holding it is time you are allowing the battery to be drained, often 
> significantly more than it would be otherwise.  And your actions here will 
> show up to the user in the battery use UI so they know who to blame for 
> killing their battery.
>
> On Sun, May 13, 2012 at 2:51 PM, William Kelley 
> wrote:
>
>> I am developing a simple GPS logger that runs as a service, getting fixes 
>> in short intervals. As I've read documentation and posts in this forum, I 
>> realize I need a WakeLock to keep the service running and logging points. 
>> Right now, without a WakeLock, my service runs fine for many hours, even 
>> when I am not using the phone that entire period. This is because I have 
>> other apps installed (task automation, etc.) that are using WakeLocks.
>>
>> So, a couple of questions. Are there any issues running multiple apps 
>> that all use WakeLocks? Aren't they all just redundant? Wouldn't it be 
>> smarter to have one WakeLock app installed (at least one exists in the 
>> market) that allows the user to decide how and when to let the CPU/screen 
>> sleep and wake? In that way, WakeLock support doesn't need to be added to 
>> multiple applications.
>>
>> I'm not trying avoid implementing WakeLock, just want to make sure it's 
>>

[android-developers] Multiple applications with WakeLock vs. one WakeLock app

[William Kelley]

I am developing a simple GPS logger that runs as a service, getting fixes 
in short intervals. As I've read documentation and posts in this forum, I 
realize I need a WakeLock to keep the service running and logging points. 
Right now, without a WakeLock, my service runs fine for many hours, even 
when I am not using the phone that entire period. This is because I have 
other apps installed (task automation, etc.) that are using WakeLocks.

So, a couple of questions. Are there any issues running multiple apps that 
all use WakeLocks? Aren't they all just redundant? Wouldn't it be smarter 
to have one WakeLock app installed (at least one exists in the market) that 
allows the user to decide how and when to let the CPU/screen sleep and 
wake? In that way, WakeLock support doesn't need to be added to multiple 
applications.

I'm not trying avoid implementing WakeLock, just want to make sure it's the 
best solution.

-- 
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

Re: [android-developers] When using LocationManager.requestLocationUpdates, do I need a WakeLock?

[William Kelley]

Just a followup: Tasker and AutomateIt both do have "Prevent device from 
sleeping" (ie WakeLock) as permissions.

-- 
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

Re: [android-developers] When using LocationManager.requestLocationUpdates, do I need a WakeLock?

[William Kelley]

On Friday, May 11, 2012 4:57:35 AM UTC-7, ste1024 wrote:
 

> Sorry for digging up this ancient topic, but an trying to find an answer 
> to the same question.
> In my app so I am able to receive location updates even if I put the 
> device to sleep, without explicitly holding a WakeLock.
> I came across what appears to be the Android 2.2 source of the 
> GpsLocationProvider,
>  
> and assuming I did not misinterpret the code, it looks like it is really 
> able to wake up the device via the AlarmManager.
>
> Can anyone confirm this?
>

I am experiencing the same thing. My GPS app runs for hours and hours 
getting coordinates every 6 seconds, whether it's asleep or not. Either 
WakeLock is not needed for the LocationManager to work non-stop or one of 
the other apps I have installed is using WakeLock. I'm assuming the latter, 
since I have Tasker and AutomateIt running, both off which are time-based 
services. I guess I should check their permissions for WakeLock. Or they 
could just be waking the CPU via the AlarmManager?

It makes me wonder if it's necessary for me to add a WakeLock to my app or 
just rely on the fact that other apps will keep the CPU alive for me.

-- 
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

Re: [android-developers] Re: Long running Android service is getting recreated over and over

[William Kelley]

I don't know, I haven't experienced any problems with that yet. I have set 
my GPS fix interval to as low as 4 seconds and as high as a few minutes 
(haven't tried anything over that yet) and my device hits those marks just 
fine. Of course, if I am outside, the fix is usually instantaneous, whereas 
if I am inside, it can take a few more seconds. So if I am inside and 
asking for fixes every 6 seconds, it might be every 15 seconds. Is that 
what you mean?

On Thursday, May 10, 2012 12:09:19 PM UTC-7, Kristopher Micinski wrote:
>
> > 
> > You know that most devices simply disregard that interval right? 
> > 
> > So basically changing it saves you nothing... 
> > 
> > kris 
>
> I should clarify, some devices *will* obey the distance interval, not 
> time, at all. 
>
> I still am kind of weary as to how many devices even obey that... 
>
> kris 
>

-- 
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

Re: [android-developers] Re: Long running Android service is getting recreated over and over

[William Kelley]

lbendlin and gjs, thanks for the confirmation that users do indeed want 
long running services sometimes. And that battery life is acceptable when 
running GPS almost non-stop.

On Thursday, May 10, 2012 8:43:11 AM UTC-7, Kristopher Micinski wrote:
>
>
> What are your smart ways?  No matter what, the GPS has to be on, and 
> even that sees like a fairly large drain. 
>
> To be honest if you're doing this where the user actively knows it and 
> intends on logging at these intervals, then they probably know they 
> are killing their battery and that there's nothing they can do about 
> it. 
>
> kris 
>

Just having GPS on doesn't drain the battery much at all. It's only when 
you get a fix that you take a hit. And as other have pointed out, although 
it does drain the battery, it doesn't really kill it, and you're right, 
users are not only aware of this, but they want it - no the battery drain, 
but the features of GPS.

As for smart ways, I meant knowing when to increase or decrease the GPS fix 
interval.

-- 
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

Re: [android-developers] Re: Long running Android service is getting recreated over and over

[William Kelley]

On Wednesday, May 9, 2012 9:40:20 PM UTC-7, Kristopher Micinski wrote:
>
>
> What you're doing isn't draining the battery only because of the 
> service, but also because of the location updates you'll be getting.. 
>
 
GPS fixing is definitely the main battery killer here, but there are smart 
ways to handle it.


> 30-40 seconds, do you really need that kind of accuracy?  I would say 
> that I'd only want something like 5 minutes, which an AlarmManger 
> certainly could do (I believe, at least..) 
>

Actually, I like to get accuracy of about 5-10 seconds when driving, less 
when walking. But 5 minutes would be basically useless. At 70 miles an 
hour, that's 6 miles between points. Even when hiking, I can make quite a 
few switchbacks and directional changes in 5 minutes. It all really depends 
on what you want out of a GPS tracker. I want a detailed log with great 
accuracy. I know battery life suffers, but when you're in a car, you can be 
plugged in, so that helps. And even when hiking, 10 seconds between fixes 
allows my phone to go for 8 hour hikes, so it's completely reasonable.

I changed my app to run as a foreground service and so far that has made 
all the difference. It hasn't once been restarted in 3 hours. For some 
reason, I thought a background process would be less likely to be killed, 
but now I see that services that let the user know exactly what is going on 
by being in the foreground and being required to show a notification icon 
are more transparent and thereby more "trusted" by the OS. The one thing 
that I don't understand is WakeLock. I am running my service without a 
wakelock, the phone has been off for a few hours, and it is still logging 
GPS points. Should I assume that some other app (I am running Tasker and 
some other automation apps as well as CatLog) are keeping the CPU awake?

Thanks for everyone's help. Little by little, I am getting a better grasp 
of what I am doing.

-- 
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

[android-developers] Re: Long running Android service is getting recreated over and over

[William Kelley]

Thanks for all the insightful comments. Too many to reply to individually 
so I'll just plow through them without quoting.

As to RAM: RAM is a premium and yet when I look at the process running on 
my phone, the smallest is using 15M, while most of the others are 20M+, 
some up to 60M+. I don't know if this is faulty reporting from the task 
manager app I am using, but those numbers seem absurdly high. Why does a 
text only note taking app need 25M of RAM?

As to long running processes: I am new to Android development, so I decided 
to tackle a simple app that would be useful to me. I want to log GPS 
coordinates over a period of time. There are dozens of apps in the market 
that do this, but in most cases, they either have too many features I don't 
want or the process of starting/stopping GPS fixing requires too many steps 
and is slow. So I wanted a simple GPS logger with a start/stop toggle 
button. Just log points to file, no maps, no Dropbox support, no other 
extra features. But all of these apps DO log GPS points fairly well and 
they all run as services indefinitely (I can quit out of the app). And they 
have good reviews with 4+ stars. So from my experience, users are not 
turned off by long running services - they are getting specifically the 
apps for this feature. They also know about the battery issues related to 
GPS.

As I said, these GPS loggers all run indefinitely and don't seem to be 
killed at any time. I've personally run some for 6+ hours on a cross 
country drive, logging points every 10 seconds and they don't have any 
hiccups. How can these apps works if the logging service can be shut down 
at will by the OS and it takes 30-40 seconds to restart a service? And you 
can't do this type of logging with AlarmManager, can you?

As for battery life and cpu: GPS fixing is battery intensive, but I don't 
know the details on how CPU or RAM intensive the LocationManager is. 
Cutting battery consumption is one of the things I am implementing in my 
app, but it will require a bit more computation. Will this trigger the OS 
that my app is being abusive?

-- 
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

Re: [android-developers] Long running Android service is getting recreated over and over

[William Kelley]

Thanks.

I'm not sure why long running services are frowned upon. As long as they 
don't overly consume resources and are done with the user's knowledge, and 
indeed the user *wants* the features of a long running service, then what 
is the harm? If a user wants to log something for a long time, an 
everlasting service is necessary. And if the user doesn't want this 
feature, they simply don't use the app.


On Wednesday, May 9, 2012 12:32:17 PM UTC-7, Kristopher Micinski wrote:
>
> Right. 
>
> And in general everlasting services are an antipattern... 
>
> kris 
>
>

-- 
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

Re: [android-developers] Long running Android service is getting recreated over and over

[William Kelley]

So, if I want a long running process (logging GPS points over several 
hours), I would need to use START_STICKY and then maintain some knowledge 
of state between service restarts. That is, save state to disk (filename 
that I am writing to, specifically). And since onDestroy is not called and 
there is no other warning that the service is about to end, I can't use any 
kind of buffered file writer because I can't guarantee that the buffer is 
written and I can't know to call flush.

Am I understanding this correctly?

And thanks Kostya for the info and very useful link.

Thanks!


On Wednesday, May 9, 2012 11:35:15 AM UTC-7, Dianne Hackborn wrote:
>
> That is the expected behavior.  The longer your service runs, the more 
> likely it is to be killed (and then restarted if you asked for it to be 
> sticky).
>
> -- 
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>
> Note: please don't send private questions to me, as I don't have time to 
> provide private support, and so won't reply to such e-mails.  All such 
> questions should be posted on public forums, where I and others can see and 
> answer them.
>
>

-- 
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

[android-developers] Long running Android service is getting recreated over and over

[William Kelley]

 

I have a simple Android Activity with one button to start and stop a long 
running Android Service (which does some simple logging). As soon as I 
start the service, I close the app (Activity) and the service should then 
run in the background indefinitely.

But it doesn't. At random times, the Application object this Service 
belongs to is recreated by the OS and then my Service is as well. So it's 
not just that the Service is getting onStartCommand called, but first it 
gets onCreate called, creating a new Service. I don't know what happens to 
the old one, it just goes away - onDestroy is not called or anything.

I run the Service as START_STICKY, I am not using the main UI thread in any 
way, so there should be no issues there. I am Logging all activity from the 
Service, logging exceptions, etc. Nothing is out of the ordinary except 
that my Service is getting recreated over and over. I just can't understand 
what the problem is.

The Service is running fine, then boom, my Application gets an onCreate, my 
Service gets an onCreate and onStartCommand and the old Service, which was 
in the middle of logging goes, away without any notice or warning. The new 
Service starts logging. I end up with a bunch of disconnected logs where 
there should be just one.

-- 
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