I have a small problem:
I'm adding geofences on my first app start with the LocationServices.GeofencingApi. After that I tell the app that it should not call this at the next app start anymore.
Now when I close the app and it starts again (from a service) it crashes (as I am not adding any Geofences in the request).
But I want them to stay alive forever, so that I don't have to call addGeofence anymore (like in iOS).
Now my question: Is that possible? And shouldn't they be stored somewhere on the Google Cloud or the services?
Thank you for any kind of help!
It was my mistake.
For everyone in the future: Use the GeofencingClient instead of the GoogleApiClient. Don't know why, but now it works ¯_(ツ)_/¯
Related
I'm using Work-manager for some background task, as per the documentation Work will be stopped when app is killed/force-stopped until the user reopens the app next time.
Is there any way I can restart the work even after the app is killed?
I'm using onetime work request
val uploadOneTimeWorkRequest = OneTimeWorkRequest.Builder(UploadWorker::class.java)
.setConstraints(constraints)
.addTag(TAG_UPLOAD_STATUS)
.build()
Unfortunately, no. Force stop stops the application as a whole, all of your services, processes and everything permanently. When you force stop an app, it cannot even receive notifications, so, I'm pretty sure user needs to restart the app to get the job done.
By the way, getting an exception or swiping the app from recents is different, they allow work manager to process its jobs. My answer is only for explicit force stop.
In my application I am using service to run background services continuously even the app removes from recent apps list. But the service stopped if I remove the app from recent apps list. Can any one gives me the solution?
Thanks,
Sekhar
you have to make and show a notification until your service is running, use below code :
startForeground(id, notify.build());
for more information check example project in here .
or maybe your problem is like that .
good luck.
Start service by returning START_REDELIVER_INTENT onStartCommand of service to continuously run your service see my answer here.
And if you never have worked on service before then i suggest you to read Service documentation first so you will get more idea and clarification : refer this doc
Hello im triying to run a service in background that it doesn't stop when app is destroyed by task manager. The idea of the service is verify every "x" min if there a new insert in a database that i got in a server.
The service is running great even if i close the app but when i use the task manager to destroy my app all the threads are closed too.
So i want to know if its possible to run a thread that ask in background forever unless user cancel it in the app itself, that ignore the destroy caused by task manager so in the future i can use notification bar to tell the user that a new insert happened in the database.
Tryed:
public int onStartCommand(Intent intent, int flags, int startId) {
// TODO Auto-generated method stub
askServer(); // i made a timertask that ask every "x" minute
return START_STICKY;
}
As i read START_STICKY should run again the service if it get killed for some reason and i know that this can be done since some app get closed by taskmanager and still get notifications from it as whatsapp,bbms and others. Please tell me if im wrong in anything and thank you for reading!.
UPDATE: Im not trying to break any law or security rule from Android and im not trying to ignore the stoping services option from an app in settings. I want that the service that listen for new incoming "events " inserts in my case keep running after user used the interface that appear when you press home for a while :
UPDATE : sorry for talking to much about this app but is the one that i can use as an example. In whatsapp when i close the app by the interface that i showed above the process and services are killed but after a couple of second they relaunch, this is exactly what i want to do to keep user informed about database events. From setting you still can stop the service without problem or even i can put the option in the app itself to stop notifiying.
Is a bad implementation call in OnDestroy() method an instance of the service so it relaunch after destroy?
UPDATE : welp looks like my service is still running on background after i close the app. I will just have to work on my service design to not waste battery life and resources. Also i was using the log.i() to check if service was running, looks like when main process closes i can't use log or toast just notifications ( still not implemented) because the service is there running just won't show in log .
UPDATE : now is working using using startForeground(0, null). In future i will send a notification to show when a event on database happen building it and calling startForeground(1, notification).
For services, look at Settings -> Applications -> Services. and see if it is running.
However, poorly designed services may run more often or perform syncing operations. So yes it is possible.
I had a problem similar to this when developing my first android game; force-stop was the only way to kill it.
START_NOT_STICKY will kill the background service when you swipe the app away from the task manager. START_STICKY is, as the name implies, "sticky", Meaning it sticks to the android system even when the app is gone.
That's from my experience, anyway.
I have seen apps like Lookout, JuiceDefender, and MagicJack run in the background indefinitely, unless force closed by a user directly through the task manager. (And even then, in Gingerbread, it wouldn't close unless you browsed to the application that was running under "Downloaded Apps" in the settings and force closed it once you were at the menu where you have options to manage the app like "Clear Memory" and "Force Close".
I am wondering how this is accomplished? I need to do something similar for an app of mine but I don't know how to avoid the Android OS's automatic task killing.. And don't say it's not possible because if that were true, JuiceDefender, MagicJack, and Lookout would not work.
What you can have is a service that stays alive indefinitely. You achieve that returning Service.START_STICKY on your Service's onStartCommand method.
Whenever the os needs resources and chooses to kill your app, your service will be respawned as soon as the resources are available again.
Bear in mind that having an application that is continuously alive will result in consuming the phone's battery. You should (at least) notify the user with a notification that your app is still alive in the background.
On top of that, you can register a broadcast receiver for the BOOT_COMPLETED event in order to restart your service while the device gets restarted. Yet, bear in mind that this could result in eating the phone's battery and so be careful on what you are doing in the service.
I believe these apps are launching a Service when their Activity get started (i.e when onCreate() is called).
A Service keeps running when the application get paused. When the Service is launched, you may return START_STICKY in your onStartCommand.
Also, to prevent a Service from being killed by Android's memory killer, you can specify that your Service is important to the user by calling startForeground(). Android Developers website states that :
A foreground service is a service that's considered to be something
the user is actively aware of and thus not a candidate for the system
to kill when low on memory.
I am creating an app and I have to use one or more of the following super functions inside OnCreate():
onDestroy()
onPause()
onResume()
onSaveInstanceState()
to close an app completely from the memory. And also do not use Activity.finish() method. Usually Android does a pretty good job in closing the app when memory is needed, called pop out of stack and not recommended to forcefully stay in memory, unless there is a very very good reason to. Hope it helps.
You can also check the Android DOC website for more information and examples to your request.
You need to start a service. Services runs in background and is useful to push alerts.
This some links about it:
http://developer.android.com/guide/components/services.html
http://www.vogella.com/articles/AndroidServices/article.html
In the service onStartCommand method return "START_STICKY".
http://developer.android.com/guide/components/services.html
/Thomas
I am currently writing an app that allows a parent to log the events that occurs from their childs phone. The logging takes place in a service which runs in the background. However, the service keeps dying after around a minute..
I dont know what other information you need to help, but any information is useful!
Thanks!
If you are just binding to the service, then that's why your service is killed when the activity unbinds (Read that in the Docs). If you are using .startService() and then bind make sure in the onStartCommand() you return START_STICKY. You can read why and how here
http://developer.android.com/reference/android/app/Service.html#START_STICKY
And yes, use .startForground() as well if you are doing something that user is aware of and shouldn't be killed in extreme cases.
try starting the Service as foreground.
Reasons why a Service gets killed are here