I’m creating a service that runs in the background. It does the following:
- Gathers the user’s data (with permission)
- Runs certain tasks every X minutes, and sends this data to a server every Y minutes
- I’d like if other people could write their own UI, widgets and other cool stuff.
Currently, the service continues to run between task runs/network sends (without a wakelock).
The service listens for validation and runtime changes; this requires a separate process. There are ways around this but they would involve using IPC (which I don’t think would cause a big performance hit).
Questions:
- Should the service be allowed to die between tasks or should I let it run without a wakelock?
- Is it more effective to remain alive than to open a database every minute or so?
- Can people use my service if it’s not in a separate process?
No. By which I mean it should run in the same process as all your other components.
No. It will automatically be in a separate process from the code from the “other people”.
Your users may disagree with this plan. Everlasting services are the reason why users attack developers with task killers and force-stops from the Settings app.
I recommend that you use an
IntentService(since you need the background thread anyway for the network I/O) and let the service shut down in between polls. Also, please allow the user to control the values of X and Y from your opening paragraph.Generally, yes. Opening the database takes a very small amount of time (e.g., handful of milliseconds), unless the flash storage is busy. That is a small price to pay to avoid complaints from users about your service running all of the time.
Yes, so long as you are exposing some API (AIDL, documented set of
Intentsto send as commands viastartService(), etc.).