In my app I listen for bootup receiver and once I receive it, I do some stuff
The problem I see is even when my broadcast receiver is done, app stays in the running processes.
This happens every time when the phone is started and I have customer complaining why my app stays in background even when they have not started it.
What is the best way to make sure my app does not keep running in background once I am done with rec
Do whatever needs to be done after bootup in a service and call stopSelf() once it is done.
But even when your app is listed in the running processes tab doesn't mean that its hurting anyone. The resources used by it will be made available by the managed runtime when needed either way.
Related
I am working on an Android application that most it logic is done in background and basically analyzing the user activities (walking, running, in_vehicle etc)..
The ui has only 2 screens for basic setup and for giving permissions.
In the Application class onCreate (not Activity) the app register to ActivityRecognition api and gets the ActivityDetected events in a broadcast receiver which process the DetectedActivity and so on.
The app has also a boot complete receiver, after device boot, the receiver onReceive invoked.. This, causing the Application class to start, onCreate is invoke, the ActivityRecognition begins as described. This works perfectly!
So actually, the process starts in boot complete and nothing stops it..
Additionally, in the Application onCreate I send a firebase analytics Event (like AppStarted)
Also, when ActivityRecognition registration done I send another event (like ActivityDetectSuccsesfullySrarted)
Now here is the thing, in firebase I see that these events are sent about 20 times a day!!
Is there explanation for this?
This means that something, kills and recreate the process? Why?
Android terminates unused processes to free up system memory.
If you want a process to run for a long time on an off-the-shelf Android device, you will need to use a foreground service. If you are working with your own custom firmware, you could take other steps to try to keep your process around.
This is similar to another question I asked where I was wondering how other apps like drupe dialer keep their service running forever when it is not in foreground. Because I've used job services, alarm manager, START_STICKY and everything else to try to keep my service alive but it always gets stopped by the OS.
You can run the service as "Foreground" and it will be not candidate to be killed by the system under low memory conditions. The gotcha is that you will need to show that behavior to the user with a notification. This is the way that music players uses to go background and alive when you start another apps.
Foreground Services
The app you mentioned (Drupe Dialer) is a Dialer. It might be listening to broadcasts and turning the service up every time by checking whether its up.
To answer your question, you need to keep the service started as START_STICKY to make it restart after the OS kills it. But AlarmManager does not work at device sleep states, and doze will stop it from running in the background nevertheless.
The real question is; WHY you want to keep it running? That might answer your question on HOW you want to do that.
If its a communication type app, you will need to use something like
GCM.
If its running background work based on some event, you might
want to start the service inside the BroadcastReceiver.
etc.
it depends on what app you're writing.
I have been trying to get an Android service to take pictures in the background using the action.USER_PRESENT trigger. Suprisingly enough, it works.
I am confused about the mechanisms involved however. Going to list some points below, please correct where I am wrong.
When an intent filter is registered in the BroadCastRecevier via manifest, it will be triggerred even if the app is closed, correct?
The created service runs its methods on a newly created thread, and will execute until end, no matter what.
What are the mechanistic differences in how the service behaves when the app is open, in the background (or stopped in some devices), or destroyed?
action.USER_PRESENT triggers when the user passes his lockscreen?
In addition, I would invite suggestions to alternative triggers to USER_PRESENT, when my condition is that the service be triggered whenever the user is using his device.
When an intent filter is registered in the BroadCastRecevier via manifest, it will be triggerred even if the app is closed, correct?
Android developers do not use "app is closed", as that is not a specific description. Many things might qualify as "app is closed". In this particular case, your receiver will work even if your process is terminated, which is my guess for what you mean by "app is closed".
The created service runs its methods on a newly created thread, and will execute until end, no matter what.
No.
First, in Java, objects do not run on threads. Methods run on threads.
Second, there is no requirement that any work done by a service "will execute until end".
All a service means is that you are telling the OS that you are doing work that is not tied to the foreground UI, and that will hint to the OS to try to keep your process around a little bit longer. How long "a little bit longer" is depends on Android OS version, system RAM, what the other apps on the device are doing, etc.
What are the mechanistic differences in how the service behaves when the app is open, in the background (or stopped in some devices), or destroyed?
Apps are not "destroyed". An app's process being terminated is the closest thing that I can think of to what you might mean.
Once an app's process is terminated, all running code is gone, including any running service code.
There is no difference in the behavior of the service itself whether the app has foreground UI or not. Having foreground UI means that the app's process is very unlikely to be terminated, assuming that your code does not crash.
action.USER_PRESENT triggers when the user passes his lockscreen?
Yes, IIRC.
I've been looking through many questions about services, but I couldn't find one that suited me.
I need a service that both starts on BOOT_COMPLETED (not bound to an Activity) and runs ALL the time (therefore I can't user AlarmReceiver). I know it might drain my battery but so far I don't care. It is just for research purposes.
I have a service that monitors sensor's data. What I managed to do so far was: either start the service as a regular Activity, but it runs only for +-20s and it is stopped (I think the SO cuts it down to release its memory); or start a service that runs in foreground. It worked to keep the process running, however the class that actually runs the service somehow was not started, besides an annoying notification which is required.
The code I refered as the one that runs the service in foreground was taken from here:
Implement startForeground method in Android
I mean, how does an app like WhatsApp run constantly? Is it running in foreground? Because looking at Settings it seems the service is very stable, and it does not show any permanent notification, since it is not possible for a foreground service run without one.
( How to startForeground() without showing notification? )
Any advice?
You can use a WakeLock. But please remember, with great power comes great responsibility (to release them again and not over-use them).
But for now, just acquire a hefty WakeLock and only release it until you are done. This should keep your device's screen and CPU awake and allow you to do whatever it is you want to do.
I have registered a broadcast receiver for every minute from my app's main Activity using Intent.ACTION_TIME_TICK. Its works fine when i exit from the app using back key or home key.
But after exiting from my app and starting any other random app...the broadcast receiver stop receiving minute ticks.
PLz help me on this cant find any solution for hours. I want to keep receiving the minute broadcast even when other apps are in foreground.
Thanks
When your app is in the background, Android may terminate it anytime it sees fit. Usually this happens when there is a need for memory, i.e. when other programs are started.
To keep Android from automatically terminating your app you need a service. Using a services makes it a lot less likely (but not impossible) for Android to kill your process when it needs the memory.