Pro Android with Kotlin

31
CHAPTER 4: Services


This is an arbitrary name-value pair in the form android:name="..." android:resource="..." android:value="..." />. 
You can have several of them, and they go into an android.os.Bundle 
element available as PackageItemInfo.metaData.
For you as a professional developer, understanding what a process actually is and how 
it gets treated by the Android OS is quite important; see the android:service flag in the 
manifest for process control. It can be tricky because process internals tend to change with 
new Android versions, and they seem to change on a minute-by-minute basis if you read 
blogs. As a matter of fact, a process is a computational unit that gets started by the Android 
OS to perform computational tasks. Also, it gets stopped when Android decides it has 
run out of system resources. If you decide to stop working with a particular app, it doesn’t 
automatically mean the corresponding process or processes get killed. Whenever you start 
an app for the first time and you don’t explicitly tell the app to use another app’s process, a 
new process gets created and started, and with subsequent computational tasks existing, 
processes get used or new processes get started, depending on their settings and relations 
to each other.
Unless you explicitly specify service characteristics in the manifest file, a service started by 
an app will run in the app’s process. This means the services possibly live and inevitably 
die with the app. A process needs to be started to actually live, but when it runs in the 
app’s main process, it will die when the app dies. This means a service’s resources needs 
matter to the app’s resources needs. In former times when resources were scarcer, this was 
more important than nowadays with stronger devices, but it is still good to know about. If a 
service needs a lot of resources and there is a shortage of resources, it makes a difference if 
the whole app or just that greedy service needs to be killed to free resources.
If you, however, tell the service to use its own process by virtue of the android:service 
manifest entry, the service’s lifecycle can be treated independently by the Android OS. 
You have to decide: either let it use its own process and accept a possible proliferation of 
processes for just one app or let them run in one process and couple the lifecycles more 
closely.
Letting several computation units run in one process has another consequence: they do 
not run concurrently! This is crucial for GUI activities and processes because we know GUI 
activities must be fast to not obstruct user interactions, and services are conceptionally 
bound to longer-running computations. A way out of this dilemma is to use asynchronous 
tasks or threads. Chapter 
10
 will be talking more about concurrency.
If the service needs to address the device protected storage, as in the Direct Boot mode 
triggered by the android:directBootAware flag in the manifest, it needs to access a special 
context.
val directBootContext:Context =
appContext.createDeviceProtectedStorageContext()
// For example open a file from there:
val inStream:FileInputStream =
directBootContext.openFileInput(filename)

---