I would appreciate some guidance on how to deal with OS killing a long run service.
Business scenario:
Application records a BTT track which may last for several hours. It can also show the track on map together with relevant statistics.
The application user interface enables the user to start/stop track recording and view the real time track on a map.
After start track recording user can exit the application and turn screen off (to save power), and only a service will remain running to keep the recording update to database (notification shown), until the user starts again the activity and ask for stop recording, which results in service termination.
Issue:
After a variable time, which runs from 40 minutes to 1 hour and a half, the recording service gets killed without any warning. As BTT outings may take several hours, this result in track recording incomplete.
Some additional information:
Service is started with START_STICKY and acquires a PARTIAL_WAKE_LOCK, and runs in the same process as the main activity.
New locations are acquired (and recorded) at user defined rate from 1 second to several minutes.
I know from the Android documentation that this is the expected OS behavior for long running services.
Question:
What is the best architecture design approach to have a well behaved application that could satisfy the business scenario requirements?
I can think of a couple of options (and I don’t like any of them), but I would like guidance from someone how have already faced and solved similar issue:
Use broadcast receiver (ideally connected to Location Manager if that’s possible) to have the service only running when a new location
is acquired?
Do not enable the user to leave the main activity (resulting in pour user experience)?
Have an alarm broadcast receiver restarting the service if needed?
Thanks to all who could share some wisdom on this subject.
I have an app that does a very similar thing. I make sure the service keeps running by making it a foreground task. When I am ready to start running, I call this function, which also sets up a notification:
void fg() {
Notification notification = new Notification(R.drawable.logstatus,
"Logging On", System.currentTimeMillis());
Intent notificationIntent = new Intent(this, LoggerActivity.class);
PendingIntent pendingIntent = PendingIntent.getActivity(this, 0,
notificationIntent, 0);
notification.setLatestEventInfo(this, "Logger","Logger Running",
pendingIntent);
startForeground(1, notification);
}
and then to leave foreground mode when logging is finished:
stopForeground(true);
Related
Pretty new to android, so forgive me if this is a dumb question...
So, I'm making an app with a countdown timer that will ring periodically, and then again when the countdown hits zero - simple enough. However, I want the app to keep running even when the user closes the application or the phone is asleep, so that whenever the timer rings, the app will wake up and display an activity showing the time until the countdown is finished. To do this, I'll need to use a service, and lo and behold, the google devs made the AlarmManager service just for me! Sweet!
However, I noticed 2 things:
1) the AlarmManager class has no default constructor, so I'm assuming I can't just extend it and tack some logic on so that I can get all this done in one shot. Ok, cool - I'll just make a service that instantiates AlarmManager at the start, and implement my logic there.
2) In the documentation, I don't see any way of getting either the elapsed time or the remaining time from AlarmManager once it is running.
So, my question is: does this mean that I will need two timers that I start at the same time? Say, an AlarmManager to wake the phone up and call the activity, and a CountDownTimer contained in the service to hold the remaining time and call the alarm ringtone?
Thanks for helping out my clueless ass.
You could extend AlarmManager. However the common way is to get an instance of it, which is running as a system service.
Get the instance using Context.getSystemService(Context.ALARM_SERVICE) and you will be able to register your PendingIntent to that system service, which is independent to your own app. The PendingIntent can either start an activity or send broadcast with some Intent. You don't monitor the elapsed time constantly in AlarmManager. Rather, you calculate the time difference between the current time of your method call, and the desired time to fire your event. And then you set an alarm in AlarmManager with a PendingIntent representing the action you wish to take at that interval, or a time point.
On the other hand, if you want maximum flexibility, run your service as foreground service and listen for system broadcast like ACTION_TIME_TICK, which is fired every minute. Alternatively if you don't run service in foreground you could also run your service with START_STICKY, which guarantees that your service will be restarted after the system kills it (due to sleep or closing app). Think this as a background service that is constantly running. This provides you a lot of flexibility in your implementation.
I made a program that creates a Service.
The service connects to a website every 5 minutes, collects one line of data and outputs it to a file.
My problem is that it didn't collect the data every 5 minutes. The data was collected once in around 50-70min. Why? Is there something in android that prevents background services from running properly during nights? What is also strange to me, the 50-70 minute breaks happened only when I was not using my phone.
Times it collected the data:
1:40
1:45
1:50
1:55
2:00
2:05
2:10
2:15
2:20
2:25
2:30 I was awake until this.
3:20
4:15
5:00
6:05
6:55
7:55
8:45
10:20
10:50 Woke up at here.
10:55
Your results are not surprising. Android was designed to swipe out (and back in) processes based overall level of resource as well as other factors.
Modifying your service to become a foreground service will certainly improve your results:
Notification notification = new Notification(R.drawable.icon, getText(R.string.ticker_text),
System.currentTimeMillis());
Intent notificationIntent = new Intent(this, ExampleActivity.class);
PendingIntent pendingIntent = PendingIntent.getActivity(this, 0, notificationIntent, 0);
notification.setLatestEventInfo(this, getText(R.string.notification_title),
getText(R.string.notification_message), pendingIntent);
startForeground(ONGOING_NOTIFICATION_ID, notification);
Foreground services are basically services guaranteed by Android to be less susceptible to swipe out,
which is what you want.
But even a foreground service will halt its processing when the devices goes to sleep. And, if you feel your polling logic is important enough so to keep the device from sleeping, you should also acquire a wakelock.
Note: Long running wakelocks have a huge impact of on battery usage. Handle with care!
Finally, please consider using an alarm for your task. Alarms are usually considered better option for
long running polling tasks.
Depending of an approach you use to schedule your updates, the OS might shift updates to decrease battery drain and overall burden. Delayed tasks might be postponed if the device falls into deep sleep (happens at night mostly as the device is inactive during long periods of time).
It's done this way to prevent your battery to be drained to fast. If you really want to wake your device every 5 minutes, you can check the answer to this post and use the AlarmManager
I am making an app that needs to execute a function each hour even the app is closed.
First of all, I thought to create a service, but during my tests, I realise that android sometimes kills my service. So I was looking for another solution and I found AlarmManager. I have implemented it and it seems to work but I have the doubt if it will happen the same the service or it will run forever? (Until reboot of the mobile...)
Another question, it is necessary to create a new thread to execute the process in alarm manager or it runs directly in other thread?
I have implemented it and it seems to work but I have the doubt if it will happen the same the service or it will run forever? (Until reboot of the mobile...)
It will run until:
the device is rebooted, as you noted, or
the user uninstalls your app, or
you cancel the events yourself, or
the user goes into Settings, finds your app in the list of installed apps, taps on that entry, and clicks the Force Stop button
It's possible that alarms will need to be scheduled again after your app is upgraded (I forget...).
it is necessary to create a new thread to execute the process in alarm manager or it runs directly in other thread??
Unless the work you are going to do will take only a couple of milliseconds, you will want a background thread for it. That leads to two possible patterns:
If you are not using a _WAKEUP-style alarm, use a getService() PendingIntent to send control to an IntentService every hour
If you are using a _WAKEUP-style alarm, you will need to use a getBroadcast() PendingIntent, and have it either invoke your subclass of my WakefulIntentService, or you will need to manage a WakeLock yourself to keep the device awake while you do your bit of work
No, Android won't kill scheduled alarms and they got executed as planned unless app is replaced or device is rebooted. Use broadcast receivers for these events to reschedule Alarms. There's no way to prevent Force Stop as it kills all of your app components and threads totally.
That depends on what Alarm Manager do. If it sends a broadcast, the receiver limit is 10 second.
If it starts an Activity, Service or Intent Service, there is no limit. For Activity and Services you must finish or stop it and for Intent Services until the process is finished. Be aware that you can't have another thread inside Intent Service and you'r limited to code inside the OnHandleIntent.
Also you must consider device state. If it's sleep and you are using Wake Up flag receivers won't need a wake lock, but others do. It won't take long for device to go back to sleep.
Don't waste system resources with a service because Alarm Manager do what you want.
I have an app that traces the location of the phone by using locationlistener to create breadcrumbs. The user can start the app, then start breadcrumb trail recording. The trail shows on a google map in the app live as the trip records. The breadcrumbs are also sent to a clout database where other applications can access the trip being taken.
The user can end the app but choose to keep the breadcrumb recording going so other apps can still follow the trail real time. If the user never comes back to stop recording, the recording will stop 24 hours from the time it started. The user can, however, start the app anytime and stop recording of the trail.
It seems that my app should consist of an activity and a service that the activity binds to. No other app will use this service so it seems the service should not have to be an IPC service. The service does all of the location listening and logging to the cloud database.
My problem is that in the CommonsWare book on page 1226 it says that if my app calls unbindService(), android will shut down the service. I want it to keep going until the activity shuts it down or it shuts itself down after 24 hours.
Does this mean my service must be an IPC service?
How can I end my activity and leave the service running?
Thanks, Gary
First off you want to make your service a foreground service.
Something along the lines of this. (I'd call this code in your services onCreate function.)
Notification notification = new Notification(
R.drawable.ic_dialog_info,
getText(R.string.notification_text),
System.currentTimeMillis());
notification.flags |= Notification.FLAG_AUTO_CANCEL;
Intent activityIntent = new Intent(this, YourMainClass.class);
activityIntent.setAction(Intent.ACTION_MAIN);
activityIntent.addCategory(Intent.CATEGORY_LAUNCHER);
activityIntent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP
| Intent.FLAG_ACTIVITY_SINGLE_TOP);
PendingIntent pendingIntent = PendingIntent.getActivity(this, 0,
activityIntent, 0);
notification.setLatestEventInfo(this,
getText(R.string.notification_title),
getText(R.string.notification_text), pendingIntent);
startForeground(123, notification);
Another thing is to not bind your service to your activity. If your activity get's killed you don't want your service to die as well. And if your device get's low on memory, if your activity isn't in the foreground it is a candidate for getting killed. Of course, when memory frees up Android will try to recreate it. But you will have a poor user experience. If your service is not bound to your activity and is foreground, it should be the last thing that gets killed by the OS during garbage collection.
You can start a service without binding it to your activity by using this simple piece of code: This code can be called in your activities onCreate.
Intent service = new Intent(YourContext, YourService.class);
startService(service);
Hopefully this helps you!
Cheers
It seems that my app should consist of an activity and a service that the activity binds to.
Not necessarily. You can use the command pattern for this.
Does this mean my service must be an IPC service?
Not necessarily. You can use the command pattern for this.
How can I end my activity and leave the service running?
Start the service using startService(). Whether it will live for 24 hours is not under your control (see Dyarish's answer for making it be a foreground service, which increases the odds that it will live that long).
I have build a service to broadcast a timer data to various activities. Usually it runs ok without problems, but there are ocassions when android restarting it does not work as expected.
It has also three Broadcast receivers:
1 - Screen off event: in order to stop broadcasting timer data and setting an alarm in alarmanager for when the service ends, so I will be able to play end notifications for the users to attend.
2 - Screen on event: in order to continue broadcasting the timer data. I also cancel any preiously alarm pending.
3 - A receiver for alarms. This usually fires when screen is off, as explained in 1.
My service is started with startForeground and return START_REDELIVER_INTENT. AS the start intent has inicial timer date, I can recreate service status without problem. Broadcast alarm receiver and onStartCommand share the same handle intent routine to start or continue the service.
All this works perfect. For short timer ( < 30 min ) I dont find any problem. The screen can be on, off, change same times from on to off and from off to on. Also the activity can be in front or in back. I have toying with those all possible states. In all cases, my service and activity runs ok.
My problems comes when some timer are longer ( > 30 min , usually I set up for 35 min). There are sometimes that maybe due to memory reason Android kill me service. That is ok, as I understand Android does this in order to improve user experience. The problem is that when I goes to 'settings/application/services' I can see my service in 'restarting' state. I suspect this mean Android has not launched it yet and it is been sheduled. It show that state for long time (I have not had patient to say if it changes for more that other half hour....)
The problem is that when in that state, that can long for ever (I have been looking into it and the service is never started), the timer (in my watch) reach the timeout, the alarmmanager launch my intent, but as my service is not started yet and the broadcast not registered, I cann't do staff for time outs (playing notifications). So the user does not known the service timer has ended and it is a heavy problem.
It is very courious. As the service is killed in almost any run passed 30 min, while other services are not killed.
My question is: what exactly is it happening? How can I correctly handle this situation in order to detect alarms been fired correctly, or more to the point: how can I force my service to be restarted correctly?
For adding some help data:
My service does have very little memory compare to others, and also does not run long operations, it only uses handler.postdelayed("sendUpdatesToUI",250) when screen is on, and nothing when screen is off, only waiting for alarmmanager to send time out intent.
When time is reached, and user opens the activity, it received the timer data broadcast intent from service and as it see time is reached, then it stops the service.
I understand and accept user can kill the service when he wants, and I accept that. The problem here is not the user, but Android restarting the service.
When service killed, onDestroy is not invoked.
Using 2.3.4 version.
After lot of investigation I found the solution to my problem. It is all about startForeGround function. I was using:
startForeground(0,not);
while this looks good and it found in lot of examples around the web, the correct way to do it is not using 0, but any other random value:
startForeground(2765, not),
This solve the problem.