476 CHAPTER 13: Android Service Class and Threads: Background Processing
This is one of those complex, involved topics in Android, because it involves binding, synchronization,
processes, processor cycles, threads, access control, permissions, and similarly advanced “OS layer”
(OS level) topics, as these are all accomplished using the Linux Kernel (the lowest operating system
layer) of the Android OS. We looked at these different levels of the Android OS back in Chapter 3, so
you can refer to Figure 3-1 if you need another “refreshing” view of this Android application hierarchy!
Tasks that are delegated to an Android Service also tend to be very processor intensive, so keep
your end-user’s battery life in mind while you are developing processor-intensive applications. As you
might guess, the two primary power drains on an Android battery are prolonged CPU processing and
keeping the display screen lit (on) for long periods of time (which we covered in the video chapter).
Services are generally utilized to handle things that need to be running in the background of your app,
in parallel with an Android user’s real-time usage of your application, but not directly synchronized, or
connected in real-time, with that application’s user interface (or user experience) design.
Tasks that are generally delegated to an Android Service class are not typically tied to the user
interface and user experience tasks, because forcing concurrent (synchronized) processing might
cause that user interface task or user experience task to become stilted or jerky (that is, they won’t
portray a smooth user interface response or a good user experience).
Android Service Classes: Characteristics
A Service in Android can be defined as an application component that can perform CPU
processor-intensive functions in the background. This is done without the need for any user interface
design or any Activity display screen. A Service does not require any user interaction in order to
accomplish its processing task.
An Android application “starts” a Service object by using an Intent object, and a Service object will
continue to process in the background even if an Android device’s owner switches over to a different
Android application to do something else, such as answer a phone call, reply to an incoming email,
or accept a social media connection request.
Any Android application component can “bind” to a started Service object and interact with it.
It can even perform interprocess communication, which you may have heard referred to as IPC.
We will be taking a closer look at processes and threads in the next section of the chapter, after the
overview of Android Service class and object attributes.
Binding is an advanced programming concept that involves establishing a real-time connection
between two separate application component processes. Once bound, the processes will alert each
other whenever something has changed. The alerted process can then check and see if an update
needs to be made based on that change. If you are a game programmer, you will commonly define a
bind between your scoreboard UI design and your scoring engine, for instance, so your scoreboard
numeric read-out will change in real-time, as your game is being played.
An Android Service usually will take one of two forms—either “bound” or “started.” Let’s start with
the started Service, as it is the most common. An Android Service becomes “started” when the
application component, such as an Activity, starts it. This is done by calling a .startService( ) method.
Once it has started, a Service can run in the background indefinitely, even in a scenario where a
component that started the Service gets subsequently destroyed, either by the application program
logic or by the Android OS. A started Service performs a single operation and does not return a