this need to be consider thread is a java object which mostly runs on android component. Android component has lifecycle java object don’t as such.
there could be possibility of leakage if thread outives android component. Go to diagram
You should always create a separate thread within a service if you are doing something more complicated.
The thread should stay alive, even when the user is not interacting with the application. In addition, a Service can be started from another application using an Intent.
Performnace issues Memory issues Battery drain Inconsitent data
Shift to code
You need to identify and understand what problem you are facing. Because there are other tools which might perform the task; before even you start thinking you need your service.
For non sticky service don’t re launch. For sticky service is re launch with different start id and NULL intent. For redelivery same start id and previous intent.
Nobody relaunches Hack use broadcast receiver at onDestroy() but very bad userExperience
sticky restart but intent is null so becomes non sticky Non sticky don’t restart Redelivery pass same intent which was sent before
java.lang.ClassCastException: android.os.BinderProxy at edu.navalkishoreb.androidservices.connectors.LocalConnection.onServiceConnected
Android Whats running in background
Android: What’s running in Background
Road to perdition
UI Thread (ANR)
Worker Thread (CalledFromWrongThreadException)
Handler AsyncTask (Component Destroyed)
Better Call Service
Service (when no one is looking)
Services / Threads (war of two worlds)
A service is not an alternative to background threads but it provides
another scope in which to run your worker threads!
• The thread should stay alive, even when the user is not
interacting with the application.
• In addition, a Service can be started from another
application using an Intent.
DO NOT let services live longer
than they are needed.
Intent Service [special case of normal service]
Bound Service [in same process]
Bound Service [in separate process-> Messenger]
Bound Service [in separate application-> AIDL]
START_STICKY to automatically restart if killed, to keep it active.
START_REDELIVER_INTENT for auto restart and retry if the service was killed before
stopSelf(). This is needed for services receiving inputs.
START_NOT_STICKY to not automatically restarts if killed, but wait for next
startService() call. For non-essential services.
START_STICKY_COMPATIBILITY with Android 1.6 and earlier legacy onStart()
• What happens if task is removed from recent?
• What happens if force stop?
• What happens if exception occur in running process?
Local Bound Services
What would happen if try to make connect IPC in LocalBinder?
Sync on Android
Well, you probably use it everyday...
setIsSyncable (Account account, String authority, int syncable)
setSyncAutomatically (Account account, String authority, boolean sync)
addPeriodicSync (Account account, String authority, Bundle extras, long pollFrequency)
requestSync (Account account, String authority, Bundle extras)
How the sync adapter works
Run in a background
Network type check
❏Introduced in Android 5.0 Lollipop (API 21)
❏When you would use this
- Tasks that should be done once the device is connected to a power supply
- Tasks that require network access or a Wi-Fi connection.
- Task that are not critical or user facing
- Tasks that should be running on a regular basis as batch where the timing is
❏ Job Scheduler
- Persists the data across device reboots
- Certain criteria can be set
- Service runs when set criteria is available
- Delay can be set
- Use for periodical running task
❏ Alarm Manager
- Broadcast listener to wake up
- Data get lost on device reboot
- Service keeps running until you manually
turns off or system do it for you
- Use for scheduling task at specific time