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.

Which should I use class for the stopwatch to run in the background. "IntentService" or "service"

what service class should I use for the stopwatch that will run on the background
Which one should I use in terms of performance.

You should use foreground service (with Service instead of IntentService) in this case.
Reasons:
Android Oreo 8.0 defined Background Execution Limits. So you will not be guaranteed of service life.
Your app is also killed in Doze mode & Standby .
If you are running a continuous service with a long thread & start-sticky then your app is being suspected by optimization apps and OS. Your app will be considered battery draining.
Intentservice kills itself when work is done. Whether normal Service fits your requirement where only you have controls of your service.
Solution:
As i said make normal service as foreground service. See here. That will notify user till your service is running. And it will not be killed by OS due to any above reason.

Here is an old question with loads of answers regarding differences between Service and IntentService. Maybe you can find something there.
From personal experience i'd say they are not that much different. Just the way you use them. I would say stick with the one you think fits your application best overall.
Service vs IntentService

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.

When to use a thread / service in Android?

When should a thread or a service be used?
Should they be used for authentication? For instance, in my app I was considering using a thread or service (I am authenticating via Active Directory.)
Do you have examples of when each would be used?

Update: It seems the Android documentation includes a corresponding clarification now, see http://developer.android.com/reference/android/app/Service.html#WhatIsAService.
Original answer:
In Android, a Service does not provide any concurrent execution ("run in background"). It is actually more of a simple Java object which merely is instantiated (and managed) via the Android system instead of your application via new.
The most important property of a service is therefore not about deferring workload; this can be achieved with simple threads.
What makes a service object special is that it is registered with the Android system as a service. This let's the system know that this object provides some sort of service and should be kept alive as long as possible, or until it is stopped. Normal application threads do not have this special meaning to the Android system and will be terminated much more generously at the discretion of the system.
So, if you need some background activities to go on only while your application/Activity is active, a thread can do what you need.
If you need a component that keeps active will not be purged even when, after a while, the Android system decides to remove your Activities from memory, you should go for the service, or even a "foreground service", which is deemed even more important by the system and even less likely to be terminated to reclaim resources.
Of course, if desired, a Service object can also be made to contain one or more Thread instances which could then live as long as the Service object itself.
Edit:
Oh, plus: A service is, of course, the way to go if you want to provide some service(s) to other applications, which can "bind" to a service only.

A thread should be used in a long running process that would block the UI from updating. If it's more than a second or two you might want to put it into a background thread and notify the user with a dialog or spinner or something. If you lock the UI thread for more than 5 seconds the user will be prompted with a "kill or wait" option by the OS.
A service does not run on separate thread, so it will block the UI, but you can spawn a new thread within a service. A service is used more for something that should happen on an interval or keep running/checking for something when there is no UI shown.

Just look at this nice post Android Thread Constructs(Part 4): Comparisons
.
or Difference between Service, Async Task & Thread?.

Use service if you need something that is either used by other applications or outlives your application activities. The good example of service is file transfer that may take long time and you don't want to force user using your application during this time. Use thread (usually via AsyncTask or similar) in other cases.
For authentication purposes AsyncTask seems like a good choice.

I believe the main difference is about Android system attitude. Service is a part of android infrastructure, so android recognizes service as a working part of application and considers killing service as a last option. Moreover, you can tune up service priority in order to do it as important as foreground activity. As for threads, android does not recognize a thread as important part which must be kept. So usual threads has much more chances to be killed.
For instance If you have an activity which start a working thread and then go background, as android do not recognize thread as a working part, it may think that application do nothing, because no activity or service running and kill the whole app, including the working thread.

As per Android Developer Guide (http://developer.android.com/guide/components/services.html#Basics) :
A service is simply a component that can run in the background even when the user is not interacting with your application. Thus, you should create a service only if that is what you need.
If you need to perform work outside your main thread, but only while the user is interacting with your application, then you should probably instead create a new thread and not a service. For example, if you want to play some music, but only while your activity is running, you might create a thread in onCreate(), start running it in onStart(), then stop it in onStop(). Also consider using AsyncTask or HandlerThread, instead of the traditional Thread class. See the Processes and Threading document for more information about threads.
Remember that if you do use a service, it still runs in your application's main thread by default, so you should still create a new thread within the service if it performs intensive or blocking operations.

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.