Develop Reference

Are scheduled threads runnable after app termination on Android?

In our Android Application - during app start we schedule threads to run every 8 hours for transmitting files. I have been observing inconsistent transmission behavior when the app is terminated after app start (i.e. the user kills the app). I am suspecting that the scheduled threads are somehow cancelled/destroyed/terminated with the app gets terminated. Does anyone know whether this is the case on Android?
Sample Code of how I am deploying scheduled background threads.
scheduledExecutor = new ScheduledThreadPoolExecutor(1, <this param is a class that Creates threads with the default priority set to background.>);
scheduledExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.DiscardPolicy());
scheduledExecutor.schedule(new Handler(), 28800000, TimeUnit.MILLISECONDS);

during app start we schedule threads to run every 8 hours for transmitting files
That will not work very well.
I have been observing inconsistent transmission behavior when the app is terminated after app start (i.e. the user kills the app)
You will have inconsistent transmission behavior if the app is in the background as well. The only scenario in which what you describe would work is some sort of kiosk mode app or other situation where your app UI is always in the foreground.
I am suspecting that the scheduled threads are somehow cancelled/destroyed/terminated with the app gets terminated
Android will terminate your app's process after a period of time, to free up system RAM for other apps. At that point, your threads and other CPU/RAM structures all go away. This is covered in the documentation, as well as many books and courses on Android app development.
And, for the purposes of transmitting files, your app's ability to use the Internet will be affected by Doze mode, app standby, and manufacturer-specific battery-conservation approaches. Doze mode is covered in the documentation.
The standard recommendation today is to use WorkManager, where you schedule the work with instructions that you need network access when the work is performed.

I want to run a thread in my application that will run for the entire time while the user is online. I cant choose variant

I want to prevent the thread from stopping during the transition between activities and call this thread during the start of my application. I have one option and I would like to share it. So far, I have stopped at writing an android service in which to include the beginning of the stream that, I need to perform. And then call it in the class inherited from the application class. It is important to note that my thread will send certain data to the database every minute. Perhaps you can advise a more reliable and popular way to solve the problem.

Threads don't stop between Activities. That would be impossible to do safely- threads cannot in general be safely stopped by anyone but the thread itself without risk of data corruption or deadlock. So Android doesn't even try. (You can cancel a thread from another thread, but that works by setting a flag and hoping that the thread you want to cancel looks at it occasionally to honor it.)
The real problem is twofold
1)How do you know if the thread is already running so you don't launch it again. This is solvable in a variety of way.
2)Do you want the thread to work when the app is in the background? This is the real problem, because Android kills background apps regularly, which will end the thread. There is no reliable way to make a thread run constantly in the background in Android. Here your best bets are either a foreground service running to keep the app active, or to not use a thread and make your app even t driven (for example, setting a repeating alarm for every 15 minutes and running then).

Android Studio: Can you control apps running in background from another app?

I am trying to create an Android app that shuts Spotify and thereby turning off music after you fall asleep.
The user gets to choose how long to keep the app running. My question is, can I kill background apps from my current app.
I tried looking on Android Studio's developer website and Google but could not find the answer I was looking for. Thank you.

Service runs in your app process. If your app is garbage collected, the service will stop until:
You start the service in new process via manifest file declaration
You make the service sticky (recommended).
go ahead and research above two and let me know if you would like more explanation or code
If you see official documentation of Service, Google clearly explains why and when service will be destroyed. What is useful in your scenario:
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.)
using startForeground will ensure your service keeps running in the same process. some pointers:
A service with attached client will not be destroyed even on low memory scenarios
A service will be killed in low memory scenarios, regardless of the process. Running in a different process is better but does not guarantee it won't be destroyed by system.
Don't use system.exit(0) to end your app. call finish() on activity.
Starting sticky service just ensures that service is restarted when memory is freed.
hope it helps!

Android which is better for service stopself or never stopping it

I have in my project services that start only once and inside the service there is a thread that runs every second or so.
And then there is some services that after they finiah their procedure they call stopself and then they are started again for elsewhere.
My question is which of these structures are better for a service and why?

If you often start and finish Service, try using IntentService
It automatically shuts down after work finished.
Developer Guide

What k0sh said. If your service is running, it is using battery. If you don't need it running, stop it and save battery.
The difference between a running service and a stopped service is the likelihood that the process running it will be killed. A running service has a fairly high priority (low oom_adj). Android will try not to kill it off. A service that is not running has no affect on the priority of its owning process. If there is no other reason to keep that process around, Android will kill it, when it needs space.
Even a running service, though, will be reaped, eventually. There is no way to keep a process running forever.

What are some ways to optimize a service running on Android?

I'm wondering what you can do programmatically to minimize the footprint that your service will have on a device? Are there any particular tricks to the way that you write a service so that it doesn't take up much system memory? I guess low memory footprint is my main concern so that a user does not want to turn the service off and is willing to have it always running.
***EDIT***
Okay so reading the answers I"m thinking that I must be doing this wrong. I am using the AlarmManager to periodically wake the service up but I am not ever stopping the service unless the user indicates via the main activity. So should I include at the end of my onStartCommand after my service performs what it needs to should I call stopService? Doesn't stop service call onDestroy because if it does I was deregistering my AlarmManager in onDestroy.
The way that it runs right now when I go to running services on my phone it has the service running but it is not actually doing anything until the AlarmManager goes off at which point it performs it's small function and that's it.

I guess low memory footprint is my main concern so that a user does not want to turn the service off and is willing to have it always running.
Theres a huge one for optimization. Androids services are not meant to run all the time (like Windows services or unix daemons).
They are more like a task solver, e.g. download a file. After finished with their task, they should call Service.stopSelf().
If your app needs the service again, it should restart it then for the appropriate task.

It really depends on what your service is doing so there's really no right or wrong answer. The important thing that I try to stay mindful of is not to keep the service alive for any longer than is required. If your service spends most of its time in an idle state, then consider waking it periodically with an alarm, and stopping the service once its periodic work is complete. This has the added benefit of preventing many task killers from destroying your service if it doesn't stay running for very long.
I also try and use inexact alarm as these are generally kinder on batteries, and battery life is also something that you should be mindful of.
In terms of memory footprint, it is always worth freeing up any unused resources, and keeping your code as lean and mean as possible, whether it is in a Service, Activity, Receiver, or anywhere else. Although current smart phones have considerably more memory than feature phones, Android is increasingly being run on comparatively lower spec hardware, so it's worth being mindful of lower end devices.
Reto Meier has recently written some articles which cover these sorts of topics on his blog.