I am building one of those SOS apps. Whenever the device is shaken above a threshold value (detected through accelerometer), I am showing a Toast (as of now)
1) App is launched. User gives name, email, etc.. and clicks finish on last screen.
2) Service is started which keeps listening for shake.
3) It detects the shake correctly if the App is running.
4) If I close the app (the activity), the service gets killed along with it.
How do I keep the service running even if app is closed, so that it can listen to shakes from background? (That's the whole purpose of this app)
[1.I am returning START_STICKY in onStartCommand
I also tried using a BroadcasterReciever which will restart service by receiving broadcast from onTaskRemoved
I am testing on ASUS Xenfone Max, Marshmallow OS
]
You have two options:
Start your service as foreground service (with startForeground(int id, Notification notification): docs. But in this case you will have to show Notification in notification tray for as long as your service is running
Use separate process for your service adding in manifest to your process android:process=":nameofyourprocess"
Try starting a service without binding it to the activity (Simple unbound service). Return null on your onBind() function. Sticky services attach itself to a activity and has a lifetime as long as the attachment survives. You might have a constant notification related to your application when you use foreground services.
You can put a Service in foreground, in which case it will always be considered as active (and it will therefore have its own notification, so the user knows that an active Service is running). It won't be stopped until it goes back to background. That is what you want in your case, as you want your Service to stay alive as long as possible. As described in the Android Service documentation:
A started service can use the startForeground(int, Notification) API to put the service in a foreground state, where the system considers it to be something the user is actively aware of and thus not a candidate for killing when low on memory.
The idea is the same for Activities and Services, actually: when Android needs memory, it starts killing processes. The foreground processes (e.g. the Activity that is displayed on the screen, or foreground services) have a higher priority than the ones that are in background (say, a paused Activity), so they will be the last ones to be stopped by the system.
Using START_STICKY just tells the system that if it has to kill your Service, then you'd like it to restart it can. That doesn't say this Service is higher priority than the others.
Related
I've read that I should call
startForegroundService(intent)
if I want to properly start a service that can run as a foreground service. But how should I think if I want it to start without it being a foreground service but potentially becoming one later on? Some info on how we have it right now:
We have an App which uses a service for many tasks. It performs all of these task when the user interacts with the app in the foreground but depending on if the user has enabled a certain feature we want to keep performing these tasks in the background. So when the app is launched (and obviously is in foreground) we start the service using
startService(intent);
When the app transitions into background we check whether the feature is enabled, and if so, run startForeground(id, notificiation); which effectively adds the non-removable notification out in the OS and the service keeps on running. When the app goes back into foreground we call stopForeground(true). If the feature isn't enabled the service will never be set as a foreground service and we won't try to perform these tasks in the background.
So my question is: Is this sufficient to get the "full foreground service performance"? Or am I losing something by not calling startForegroundService(intent)? My impression is that we actually do have a fully working foreground service but I'm getting confused when I read statements that foreground services must be started using startForegroundService(intent) which we're not doing. If we really need to use startForegroundService(intent), the only solution I can think of would be to initially start a normal instance of the service and when the app enters background we start a new one using startForegroundService(intent). But do we need to do this or is running startForegund(id, notification) on a service started using startService(intent) sufficient to achieve a foreground service?
NOTE: One difference I find is that if the application itself is in background when start the service I then need startForegroundService(intent) for API >= 26. In our case we always start the service when the app is in foreground. I do however recall some instances where I've seen the exception thrown when we try to start the service using startService(intent), somehow the app (very very rarely) still think it's in background (perhaps something from the OS comes up just when app is launched). So if I catch when that happens I could run startForegroundService(intent) to start the service. But is it possible to run stopForeground(true) on that service when the app comes back into foreground? Or is it bound to be a foreground service forever since we started it that way?
Seems like you don't have to call startForegroundService and startService is sufficient:
If your service is started (running through Context#startService(Intent)), then also make this service run in the foreground, supplying the ongoing notification to be shown to the user while in this state. By default started services are background, meaning that their process won't be given foreground CPU scheduling (unless something else in that process is foreground) and, if the system needs to kill them to reclaim more memory (such as to display a large page in a web browser), they can be killed without too much harm. You use startForeground(int, Notification) if killing your service would be disruptive to the user, such as if your service is performing background music playback, so the user would notice if their music stopped playing.
From Documentation
I read your question multiple time and I think (hopefully) the answer to your question is :
According to the official document of Android 8.0 Background Execution Limits:
Android 8.0 introduces the new method startForegroundService() to
start a new service in the foreground. After the system has created
the service, the app has five seconds to call the service's
startForeground() method to show the new service's user-visible
notification. If the app does not call startForeground() within the
time limit, the system stops the service and declares the app to be
ANR.
So, make sure you have started ongoing notification by calling startForeground (int id, Notification notification) in the onCreate() method of your service.
Note: Apps targeting API Build.VERSION_CODES.P or later must request the permission Manifest.permission.FOREGROUND_SERVICE in order to use this API.
And there is great medium article posted by Maciej Witowski that help you understand how really new services API works :
https://proandroiddev.com/pitfalls-of-a-foreground-service-lifecycle-59f014c6a125
I'm developing a player app.
For this reason, it uses a foreground service to handle the playback.
Until recently the service was bound to my activities.
This is not the case anymore.
Since then, some specific devices (mostly Pixel 1/2/3) have been killing my app 1 minute after the screen has been turned off
The service is a foreground service not bound to anything.
Why would the device kill it?
As soon as the app is excluded from the device-optimized apps list the issue is solved
I'm not providing code, because I'm just trying to understand if this situation makes sense and if so what should I do to prevent this
BTW the app is using a receiver to act on Screen_ON/OFF messages. That's how I can see in the logs that the player service onDestroy() method gets killed exactly 1 minute after the screen has been turned off
what should I do to prevent this?
The key point here to keep the service alive is as said in official documentation :
While an app is in the foreground, it can create and run both
foreground and background services freely.
so, we can conclude that keeping the work in foreground and visible to the user has very minimal chances of being killed. And to do so we need to know that how android gets the idea that this process is in foreground ?
Here are the criteria's at which a process is said to be in foreground:
It has a visible activity, whether the activity is started or
paused.
It has a foreground service.
Another foreground app is connected to the app, either by binding to
one of its services or by making use of one of its content
providers. For example, the app is in the foreground if another app
binds to its:
-IME Wallpaper service
-Notification listener
-Voice or text service
If none of those conditions is true, the app is considered to be in
the background.
If none of the above criteria is fulfilled by your app process then thats the reason of your service being killed.
You can read more on this topic here :
Foreground service being killed by Android
I am launching a service in my app.Currently I am starting my service in my activity in a simple way:
Intent i=new Intent(this,WindowService.class);
startService(i);
It works fine in most of the devices,But in some devices like lenovo and some devices when I remove my app from recent tasks the service also gets killed with activity.So I found that startForeground() method will solve this issue.Is it true that startForeground() method allows my service run even if the application is removed from recent tasks.
Yes its true, startForeground() started a foregrounded service with notification which show the user that the service still running. This is because a foregrounded service consumes a heavier amount of resources and is subject to different scheduling constraints (i.e., it doesn't get killed as quickly) than background services.
the common used its for playing music, download files and etc.
From Service Docs
A started service can use the startForeground(int, Notification) API
to put the service in a foreground state, where the system considers
it to be something the user is actively aware of and thus not a
candidate for killing when low on memory. (It is still theoretically
possible for the service to be killed under extreme memory pressure
from the current foreground application, but in practice this should
not be a concern.)
so from the docs it seems the system will not kill the foreground service
I am working on an application which need to show notification constantly.
I've a service to show the notification every seconds.
When the resources goes low android is killing my service.
I've given the return START_STICKY from onStartCommand().
So after some time the service is getting restarted.
But in the mean time the notification look stoped.
I red somewhere that it is possible for a service showing notification prevented from getting stoped by android. I dint get any example for it.
Use
startForeground(int,Notification);
in onCreate of service. It requires a notification number and a notification object which it will display in the notification bar.
To remove the notification, use
startForeground(0,Notification);
As written above you need to use startForeground(int,Notification) method to aware user about your service. It also get more privilage for it.
You can read more about it here (example inside).
There is no way to completely stop it from ever being killed. Making it a foreground service helps. Returning start_sticky means it will be restarted if it is stopped (so it should do a startService on itself in its onCreate to make sure it restarts and not just gets recreated). But Android has the right to kill any service at any time due to resources.
Update:
You can use Foreground Service in the scenario. From the docs:
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. A foreground service must provide a notification for the status bar, which is placed under the "Ongoing" heading, which means that the notification cannot be dismissed unless the service is either stopped or removed from the foreground.
In my knowledge there is no bulletproof way of preventing your service from being stopped by the android system. If the device is critical on memory/resources then your service has to be stopped for GC. This is also not recommended because your service will drain the device battery.
I am currently writing my first Android application and I keep running into references to background and foreground services. Since I intend on using a service in my application I was hoping to get a clarification between the two and how they are used.
Perhaps this will answer your question:
A started service can use the startForeground API to put the service
in a foreground state, where the system considers it to be something
the user is actively aware of and thus not a candidate for killing
when low on memory. By default services are background, meaning that
if the system needs to kill them to reclaim more memory (such as to
display a large page in a web browser), they can be killed without too
much harm.
More info can be found here
Foreground: The process relies on onPause() and onResume()...i.e you play music player and pressing pause and play
Background: The process which runs without user interaction i.e receiving a message, incoming call, receiving mails, or setting alarms. The method used here is onStart() and onStop().
For example, check it on your phone. Create an alarm at 6:30am. When the system clock reaches 6:30am it fires. In order to kill the alarm service, just go to menu-->settings-->application-->Running service-->click stop service. It stops the alarm service even when your system reaches the time it won't fire.
Foreground Service is used when User is interaction with application and when Service is doing something visible to user. Background Service is used when even user close application (discard from recents) and when Service is doing something not visible to user like downloading data from server, load data from a ContentProvider etc.. And Foreground Service is less likely to be killed by system on low memory.