Develop Reference

Android service without lock considered useless?

According to Android docs:
A Service is an application component representing either an application's desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use.
But my service get killed very quickly - around 10 seconds - when the user leaves the app or the screen gets turn off. It seems according to Android Kotlin Foreground Service stops after some time that you need some sort of mechanism to prevent the phone from getting in doze mode.
So, what is the purpose of having a service without a wake lock? And why does the documentation never mention something remotely related to wake lock when dealing with services?

You can have a Service that is doing work for an Activity. If the user navigates away from the app or dims the screen or ignores his phone long enough for it to be clear that he isn't looking at it, what is the point of the Service continuing to run? The user isn't looking at the Activity, so processing in the Service is not important enough to keep the phone from sleeping.
On the other hand, if you have a Service that is performing important work and you need to keep the phone from going to sleep, then you obviously need to get some kind of wake lock or use some other method to keep the phone on.
These are 2 different scenarios with different requirements.

Android 8.0: keeping a background service alive

I believe you all are already familiar with "background service limitations" imposed on Android 8.0 and up (https://developer.android.com/about/versions/oreo/background.html#services).
I'm having a very particular problem right now. My application is meant for a very specific use case. App checks for certain data on the server every minute and in case of some wrong value, user is being alerted immediately. Obviously so far application was running in a form of background service and my customers never cared about (obvious) battery consumption coming from complex calculations that are being performed every minute.
Now, whole idea is that app needs to stay alive, working and in background (even with permanent notification, i don't have anything to hide) regardless of anything! If phone is in a deepest possible sleep state - service needs to keep running. If there's 2% battery left - service needs to keep running. So far, i managed to achieve that using alarms and "guardian services" which prevented any way of stopping the background service while app is installed. But now, with Android "0" - what's the way to go? Is there a JobScheduler that will guarantee execution at given rate (every minute) regardless of anything?
How SMS / Phone, WhatsApp and similar apps achieve that "awake no matter what" state?

That's what Google tells us.
A process is not forever.
If you feel you need your foreground service to stay alive
permanently, then this is an indicator that a foreground service is
not the right answer.
Effective foreground services on Android
I think you could use repetitive tasks with WorkManager or change the architecture and use FCM. In any case, Google will not let us work as it did before.

Does an Android listener need to be running the whole time?

I'm writing my first independent Android app. It will sit in the background and respond to a few events generated by the OS, somewhere between a few times a day to a few times a week depending on the user.
Coming from a PC programming background, I thought I might need a service, but Android Developers > Service says:
What is a Service?
Most confusion about the Service class actually revolves around what it is not:
A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of.
A Service is not a thread. It is not a means itself to do work off of the main thread (to avoid Application Not Responding errors).
The app should not need to consume any resources unless one of the events it's listening for happens. The user should also not need to actively use the app after it's been set up, only if they want to change its settings.
I have games that seem to do something similar to what I want. They sit in the background and can receive messages (e.g. it's now my turn), and when I click on the notification it loads the game into memory, which takes a few seconds longer than if it was already in memory.
If the user hasn't used the app's interface for a month, I want it to still be in operation (even if the device has been power-cycled) and respond to events but not to appear in the list of recent apps (assuming a month is long enough to push it off the end). Ideally, I want it to respond to the events within one second; it doesn't have to be near-instant. What's the normal way this is done?
An app (occasionally used) and a separate "service" process/thread (persistent)
A combined app and "service" (persistent)
A combined app and "service" (loaded into memory by events)

Not enough reputation to comment, but just to tell you that nothing prevent Android to kill your service, To restart your service after the user reboot its phone you can add a broadcast receiver and listen to
https://developer.android.com/guide/components/broadcasts
.Also, if you don't want to display a notification while your service is running you will have to use a background service instead of foreground one. Hope this help.

Effective way to monitor for SMS's in the background, even after app execution ends

I have developed an app wherein my requirement is that I have to monitor for SMS from a particular sender containing a particular text in the background. This I have done with relative success, using a combination of asynctask and sentinel based while loop. However, this won't work if I force kill my app after triggering the SMS monitoring, or if I leave the phone idle for hours after I trigger the process.
I realize that background service is probably the best way to go.
My requirements are:
1) The SMS monitoring has to be done in the background even if I kill my app after triggering the monitoring process.
2) If I want to deactivate this process at any time, I should be able to go back to my app, and do so on clicking some button.
3)The service should linger even if there is an intermediate power off of the phone.
How do I go about doing this in an effective manner? Detailed solutions with code/pseudocode would be highly appreciated.

Is it possible to hold multiple Wake Locks?

I'm developing a small utility app that scans 2D barcodes, and then submits each barcode to an IntentService where a longer task is performed.
When the activity is shown, it should prevent the device from sleeping, until the barcode is processed in the service. If the service finishes the processing, it stops itself, but the activity should still be visible.
I'd like to hold a SCREEN_DIM_WAKE_LOCK WakeLock during the activity lifecycle, but as this type doesn't prevent the CPU from sleeping, I'd also need to acquire a PARTIAL_WAKE_LOCK in the activity when a new 2D code is scanned, and release it in the intent service after it has been processed.
The SCREEN_DIM_WAKE_LOCK purpose is to avoid the user the inconvenience of pushing the power button each few seconds to wake up the device and be able to read a new barcode. The user will have to read a great number of codes one after another and the activity should be around even for the short intervals where there's no user interaction.
I know in Android there's no 100% guarantee of the app being on top, not closed, or foregrounded due to several conditions my app can't control, but I'd like to go as far as I can.
So it is possible to hold multiple WakeLocks? Where could they be declared to be accesed both by the activity and the service? (Singleton, extending Application?)

It is possible to hold multiple WakeLocks. In fact it's done all the time when multiple applications sync at the same time when the screen is off. (Imagine your GMail and Facebook apps sync at the same time when the screen is locked. They don't know about each other will have different WakeLocks. May or may not be different types of WakeLocks)
Android will make sure everyone's expectations are met (maximum battery drain in other words.)
In my opinion, I think you're over-thinking the fact that you need a SCREEN_DIM_WAKE_LOCK as this can accidentally drain a LOT of battery, but I may be wrong depending on your use case.
So the short answer is YES. You can hold multiple WakeLocks and Android will (should) act as expected. Only thing to keep in mind is that you release both Wakelocks properly.
In the issue of getting on top of the screen, I think you should release the WakeLock of your activity when it goes to Paused state (when somehow another activity is on top, or use intentionally press the power button). Because at this point, user is interacting with another app, and you should respect it and let it control its own behaviour. You don't have to give up the partial wake lock from your service until you're done.
Hope This Helps.