Welcome back, guys.
After broadcast receivers.
Let's have a look into services, which is our third key component in our Android application.
So when do we have to deal with services in our mobile application?
We sometimes have to handle a lot of stuff.
For example, in our game we have to render all those graphics, keep track about those objects and
things like this.
Beside games we might have to handle, for example, network requests or playing music, file interaction,
complex operations, things like this.
All of them require a little bit of time.
And this is the problem, for example, if you're trying to make network request in the main activity,
so within the on create method, then we have to wait until this network request has been finished and
this might take a while.
The problem right now is the application becomes unresponsive, let's say, for two, three or 4 seconds.
And this is something the Android system doesn't accept.
So after blocking the menu, I forget our activity thread for a certain amount of time.
The the Android system is going to terminate our application.
So if the operation simply takes too long, the the Android call system is closing our application.
And this is something, of course, we do not want to have the Android system doesn't want to have applications
that block the UI thread and we don't want to have applications that's being closed.
The solution for this one are services because they run in the background, they are not blocking the
UI thread and therefore they can be used for time consuming tasks, for example, like playing music
or making some network requests.
And generally speaking, we've got two types of services.
The first one is the start service, and this is the this is the most common approach.
Like we would have assumed it.
We simply start our service.
The service is performing some task and then the service gets closed.
For example, playing a music file, making a network request, things like this.
Okay, this is start service.
Beside this, we also having bound service and now it's getting a little bit complex, but not very
not too complex.
So inbound service is binding clients to the service, which means we could have other applications
interacting with our service right now.
The concept, I mean, this is pretty awesome that things like this are possible, but it is also a
little bit tricky because those clients are being bound to our service.
They can interact with this one, but we have now to wait until every client disconnects from our service,
until it gets shut down.
Okay, so these are our two services.
We've got the start service method and we've got an on bind method.
These are the main methods regarding to these two services.
All right.
The downside of the service is we cannot make an UI update.
This is not possible because as already mentioned, the service is running in the background and it
has no connection to our to our main UI thread.
Therefore, if you want to perform things like this, we need to use broadcast receivers.
But this is perfectly fine.
We are already familiar with this one.
So in common service interaction has been the following in the past.
We've got our Android application and this Android application has registered and broadcast receiver
to the boot completed broadcast event.
So after the smartphone has been finished booting, the smartphone is informing the applications about
this event with the boot completed broadcast.
Now within our application we could implement in broadcast receiver and in the receiver method we could
start our service which is polling our server.
If there are any updates for this app, this means the user doesn't have to open this application.
The smartphone has been finished, putting this broadcast event has been triggered.
Our own receive method is fetching this event and starting in the background our service which is connecting
or is requesting our server regarding to optics.
This was an yeah this wasn't common behavior till Android eight because then we are not having this
this background execution being allowed anymore.
Okay.
So this is pretty awesome because all these Android components can stick together, they can interact
with each other and they can perform a lot of interesting things.
Also, of course, vulnerable things.
Speaking of vulnerability, what do we have to look for and service if you want to attack it?
And the answer for this one is already no, at least for the START service, because the START service
so not the bind service.
The START service is being invoked via an intent and therefore we have to yeah.
We have to take a look into on that command method because there we are providing this intent.
Once again, we have to figure out which data is being passed into this function and what things we
can trigger.
Exactly the same like we have seen this in the broadcast receiver example.
Alrighty.
Okay.
Regarding to bein services, it's a little bit more tricky because there we are having a different option.
We are having a message object and yet we have to figure out and then we have to figure out what is
happening with this message object.
But I mean, the approach is.
It's pretty identical.
On the left, we're dealing with intense.
And on the right we are dealing with message, object to attack and service.
Once again, the service has to be exported and we need to have the permission to interact with this
one.
If it's using a custom permission, no problem.
Until the protection that will become signature, then we are having a little bit of problem.
But unless the protection level is not being set to a signature, we we might be able to interact with
this one if it has been exported.
OC Perfect, because this is everything we need to know about the service.