I believe it's because of some power saving option or whatever but I cant debug it since it only fails when it's on battery
I have a service that checks on a webpage every 60 seconds
I use an asyncTask in the service to do this
and I make it Thread.thisThread.sleep(60000); before checking
am I doing something wrong? could the sleep function cause the server to be stopped by android?
I have a service that checks on a webpage every 60 seconds I use an asyncTask in the service to do this and I make it Thread.thisThread.sleep(60000); before checking
Please don't do that.
First, make the period configurable, including a "don't do this, ever" option. Users really do not like it when developers write apps whose primary purpose appears to be to use up a ton of battery life. Keeping the device awake and polling a Web server every minute is going to use up a ton of battery life. It is behavior like this that is causing users to run to every task killer they can find.
Second, particularly for periods greater than a minute or so, please use AlarmManager and a [WakefulIntentService][1]. Schedule the AlarmManager to invoke your application at the user-chosen period (ideally via setInexactRepeating()). Have the WakefulIntentService poll your Web page. If you follow the documented WakefulIntentService recipe, the device will stay awake long enough for you to get your data, then will fall back asleep. Your service will not remain in memory all of the time. You get your functionality, and the user gets better device performance.
Related
I'm trying to develop an Android app that among other things, uses location services to get user location and sends it to a remote server. The user can turn this feature on and off according to his own will, but as long as it's turned on, it will get user location periodically (maybe each 30 seconds, don't know it for sure yet). Also, while it is turned on, it must keep tracking the user even if the application is closed.
So far I've considered 2 options:
Option 1 - Use Service, call startForeground to make sure Android don't kill it (the sticky notification is not an issue to me) and use a LocationListener with the said interval, but this seems rather inefficient as the service would be doing nothing most of the time, I mean, the listener would be called each 30 seconds, send the location to the server and the service itself would spend the next 29.9 seconds or whatever just waiting for the next location.
Option 2 - Doing some research, I've seen some approaches using AlarmManager to trigger some background service (like seen in this post), but I'm concerned that using alarms that often (every 30 seconds) might not be good for the battery and system general performance (in a code snippet in this page of Android's Developer guide there's a comment saying that "hopefully your alarm will have a frequency lower than 30 MINUTES").
Maybe there's another option that I still haven't thought about, or maybe there's a way to put the service from option 1 to sleep for some time or something like that. Bottom line, I'm looking for the approach that doesn't impacts on performance, consumes the minimum amount of battery and has the least chance of being killed by Android.
Any help and/or suggestions are welcome.
My question is rather simple but might come with a complex answer.
I'm making an App that checks on an online mysql db (via a php script on the website) for new updates. Sometimes this updates will tell the App it has to download form a FTP server.
The App should start on boot and check for updates every 15 minutes.
I've read in the web I should either use a service or a AlarmManager but I don't know which one is better.
Also, I've read a lot of pages that say that AlarmManager will "Wake Up" the device but I've failed to understand what this really means and why it's different in a service. Does this means that if the Phone is turned off it will turn it on or that it will turn on the screen?
I only need the phone to do the task in the background when it's on, I don't need it to turn the screen on or power up the device.
I've read in the web I should either use a service or a AlarmManager but I don't know which one is better.
It's not an "or". It's an "and". You will need to use AlarmManager to trigger the work to be done by a Service.
I've read a lot of pages that say that AlarmManager will "Wake Up" the device but I've failed to understand what this really means
An AlarmManager _WAKEUP event type (e.g., ELAPSED_REALTIME_WAKEUP) will wake up the device out of sleep mode. That, in conjunction with something like WakefulBroadcastReceiver and an IntentService, can arrange for you to do your work periodically even though the device would ordinarily be asleep (screen and CPU in a sleep state).
I only need the phone to do the task in the background when it's on, I don't need it to turn the screen on or power up the device.
Then you can use AlarmManager with a non-_WAKEUP alarm type (e.g., ELAPSED_REALTIME). I would still recommend using WakefulBroadcastReceiver and an IntentService, to make sure that the device does not fall asleep in the middle of what you are doing, as that may cause problems for your work.
I wrote an app recently and, well I'm quite disappointed about how much battery the service consumes. I go to make a call yesterday to find my battery is at 9%; I check the android system statics for the battery and find that my app is responsible for 60% of the battery drainage
My question is, what can one do to reduce the battery usage on an app that runs and then sleeps for 60 seconds? The service is reading from a SQLite database; I could cache the data, but would that really account for that much battery usage? What are some standard ways to reduce battery drainage in a service?
You should look into using AlarmManager to schedule your app or service to be called when necessary. This has a big advantage over your current wake lock method, because even a partial wake lock will keep the CPU running. An AlarmManager alarm can wake the phone even from CPU sleep.
Basically, get rid of your existing wake lock and schedule an AlarmManager alarm—which can repeat once a minute, if that's what you need—to wake up the device, if necessary, and send you a message.
The AlarmManager itself will take out a wake lock while calling an onReceive() method to notify you of the alarm, and relinquish it when onReceive() finishes, letting the phone go back into deep sleep if it wants to.
Note that this means that if you want to do extended work—e.g. firing something off on a background thread—you'll probably want to take your own wake lock out in onReceive() and relinquish it when your work is done, otherwise the phone may go to sleep while you're in the middle of the work.
This is all pretty well-explained in the AlarmManager docs, but the best explanation I've seen is in Mark Murphy's The Busy Coder's Guide to Android Development; he also provides a library for exactly this pattern on Github. Definitely worth a look.
I have application which for every 10 seconds do some request to server (http client). I read a lot about application life cycle. My application has service with foreground flag and it's work well (application work all time) when android is "active". I don't have phone with real android, so I am testing on emulator, but my friend testing it on smartphone and he notice that when he leave his phone, request are post for 10, 30 minutes, even hour. If he turn on screen, then request time is back to 10 seconds (he have access to server so he see logs). Is this known behavior? Because he installed gmail notifier from google, and this same problem (big delay). Any solution for this? My service have timer task (so request is sent in async task)
Regards
First of all, if you're polling every 10 seconds, that's gonna drain a lot of battery and network bandwidth.
I recommend using a lower frequency or server push.
For the polling issue, how do you implemented the polling ?
Do you use timers ? if so, what options do you pass in ? Or do you use a thread that sleeps for 10 seconds ?
Depending on the version, Android may turn off all processes, or delay network requests to run every 30 minutes to preserver battery power and bandwidth. (Starting up the network components drain a lot of battery than keeping them running. So If your app turns ON network, do a poll, then simply turn it off, Android may schedule it to align with all other requests on the system.)
Can you provide us more info about how you do the polling ?
UPDATE
You might have to schedule a 'WakeLock' so android knows when to wake up for your service. I think, by default, android doesn't wake up for timer requests that are scheduled very frequently and it schedules them as I explained. WakeLocks on the other hand can force android to wake up.
See this question and WakeLock Documentation
Make sure you pass the correct parameters, so you don't turn the screen ON. (Would be really annoying.)
UPDATE
I still recommend using server push for this, which will save battery and bandwidth while keeping the updates real time.
I am coding an android application that gets the user position every 5 minutes, stores it in the database and sends it to a server.
I have read many ways of doing it, I was going to do the following:
User starts the application
The main UI activity starts a service.
The service runs in background and keeps turning on and off the gps, and creating new
threads that will save to database,and send the data to the server.
But I have seen that it can be done with a "Remote service" (http://developer.android.com/resources/samples/ApiDemos/src/com/example/android/apis/app/RemoteService.html) or with an AlarmManager that schedules starting this service every 5 minutes.
The service will need to be running always: it is important that after every interval (5 minutes), it is executed.
I think I need some clarity here.
Thank you for your help,
I am coding an android application that gets the user position every 5 minutes, stores it in the database and sends it to a server.
Please allow the user to choose the location provider. Not everybody has GPS on their device. Not everybody has GPS enabled. And, not everybody will want the power hit of GPS being turned on every five minutes.
Please allow the user to choose the polling period, including "never poll -- I'll refresh the information manually from the activity". Also, please honor the background data setting (deprecated as of ICS).
I think I need some clarity here.
If the polling is supposed to go on even if the activity is not in the foreground, use AlarmManager. However, most recipes for using AlarmManager will have the real work (in your case, GPS fix and network I/O) be handled by an IntentService. This will not work in your case, because GPS is asynchronous -- you cannot just get a fix whenever you feel like it. It will take a long time, possibly forever, to get a fix, so you have to deal with the delay and eventually timing out the operation. Writing a Service to do this is possible, but tricky, particularly if you are aiming to collect this information even if the device falls asleep.
If, however, the polling is only supposed to go on while the activity is in the foreground and the device is on, I wouldn't bother with a Service at all. Just have the activity use postDelayed() to set up an every-five-minutes scheduled bit of code to run, then have it do the work.