|
![](/i/favi32.png) Pro Android with Kotlin@de android telegram Pro Android with Kotlin Developing Modern Mobile31
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)
|
|
|