Develop Reference

Running BLE in background on Android

Where I'm Currently At:
I would like to be able to run Bluetooth in my app in the background on android. I have read various guides and understand the idea of creating an intent service (something like android.app.IntentService and extending it, overwriting the onHandleIntent with your desired behaviour) however, I don't understand how that would interract with my existing behaviour? So for example, I currently call:
...
var bluetoothManager = utils.ad.getApplicationContext().getSystemService(android.content.Context.BLUETOOTH_SERVICE);
adapter = bluetoothManager.getAdapter();
adapter.startLeScan(Bluetooth._scanCallback)
...
(this is in JavaScript, using the nativescript runtime, so don't worry about it looking a bit wierd.)
Where I'm trying to get to:
I would like to being able to scan for and reconnect to paired devices in the background and recieve (store in SQLite) GATT Characteristic updates.
Question:
So how do I create this functionality in the type of service that can be run in the background as described above?

The Bluetooth LE Gatt APIs are built upon Android's Binder mechanism, which means it will only work during the app process is alive. You must make sure your app process isn't killed by the system. The easiest way to do that is to have a foreground service running (not an intent service). The only important thing is that the foreground service is alive and running, your service class itself doesn't have to do anything. But I guess the easiest way is to put all your BLE code inside that service. See https://developer.android.com/guide/components/services.html#Foreground.

service and three activity, start service is the right way?

I developed a Ble Android App composed from three activity and one service:
- the first one to scan the device
- the second one to connect to device
- the third one to write communication result on the screen
- inside the service there are some functions to connect to device, to check the connection , to automatically reconnect etc etc and this service is a started service and binded to each activity (the first app start this service)
On some tutorial I have seen that in this case is being used a not started service but a binded one. But I wonder myself, when we switch between two activity, if the service is not "started" one, is there the risk of ower service may be closed from the system, because in the switch between activity the service is binded with nothing ?

Two answer your question - there is a risk your service will get stopped at any time. If you design your app around the idea that the service will be on as you switch through activities then you're going to have a much more complicated design than you need.
You might notice that there is a service defined in the example: http://developer.android.com/guide/topics/connectivity/bluetooth-le.html
That service, as it's written does just one thing. It scans for a device and when it finds one it broadcasts the BluetoothDevice (which is a Parcelable). Then the service stops scanning. This scanning code could just as easily be in an application. But the key is that the scanning shuts down and the BluetoothDevice is passed via intent to some other component.
A good thing to keep in mind too, is that when you use BLE your application is talking to a service already. So defining a new service to wrap the BLE connection is completely redundant (technically speaking). Having multiple activities to bind to a service to talk to one device ... possible, but not without its complications. The number of edge cases you'll run into makes the effort much more work than just having your activity talk to the device directly.
Hope that helps.
Cheers.

Android service to get data from Bluetooth

I have an Android service that starts at boot, and I want to get events from an external device using bluetooth.
I wrote a sample activity that connects to the device via bluetooth using spp and eveything works ok.
I now want to integrate this code into the service.
what is the best practice to get data from bluetooth spp using a service (and not activity)?
how will it impact the battery life?
Thanks!

Your Bluetooth code should be roughly the same for the service as for the activity. The fact that you got it working in an activity means you've already moved all blocking operations off the main thread. It will probably be easiest to use a regular Service (vs. IntentService) since that is more similar to an Activity.
Regarding best practices, you will probably want to hold a CPU wake lock for the duration of comm with your external device - to ensure the comm completes - and that certainly has implications for the battery, but that seems reasonable and necessary to me. Other then that it shouldn't be much different then doing it in the activity. It would be more battery friendly if you didn't start at boot, but I guess that depends on your requirements.
(Note that SPP is the normal mode of bluetooth comm on Android, so you can look at the Bluetooth chat sample for applicable code - but it sounds like you are probably beyond that stage.)

Bluetooth Communication in thread or Service in Android?

I am developing app which has bluetooth communication involved. The bluetooth communication should go on even if the Activity that sets up the connection closes down. First, I have thought of using Service for this and that seemed to be right way. But, in Bluetooth chat example the communication happens in another thread and not in Service. I have used that code in my app and its working properly. Is using Thread for bluetooth communication proper or do I need to make use of Service only? The bluetooth communication should be active till my app is in RAM and it should not matter if I switch between activities.

Well a seperated Thread is not differnd then a service in you case, except that it follows the activity life cycle of Android, but a Thread might be killed and no state can be recovered. Android will try to restarted a service once it was killed.

A little too late to answer your query, but better late than never I suppose.
I have worked on an application that has the bluetooth communication between two devices and I would like to summarize my experience.
A service we use normally when we want do some background process that is not very heavy, in a way, I mean the service (if it is huge) will block my main UI thread hence slowing down your OS or ANR may be, which is what we don't want.
The bluetooth communcation is an ever running process which should be done using a Thread only as this will work as a separate thread and wont have any impact on the main UI thread.
Please correct me if I am wrong.

Which background model to run

I am trying to develop an application which will require a service to
run in the background. I am relatively new to android programming,
and after reading many posts, blogs, how-to's and books on creating
and managing services, I am still pretty confused about which model I
should try to use.
First, let me present (in general) the application requirements: I
need an application which will spawn a background process (service?)
which will connect to a bluetooth device. The bluetooth device is
designed to deliver data to the android device. The issue is that the
data could come in at any moment, so the bluetooth connection has to
stay active. Note that the application is a VERY SPECIFIC app and is
NOT intended for public use. I do understand the arguments for not
having background apps running all the time, but please understand
that this is a very specific application for a very specific client.
Now, in general, I think the program flow would be to start the
application (and launch a UI activity). Then I need to configure and
connect to the bluetooth device. At this point, the user should be
able to do other things - make phone calls, check their email, etc.,
while the bluetooth connection is still active and potentially
receiving data. If data comes in, a notification is fired, etc.
So here are my questions and concerns:
If I start an app (which spawns a UI activity and ultimately my
bluetooth connection service) but the app is killed, apparently, the
service handling the bluetooth connection is killed as well. How can
I keep that alive? I read that Service.setForeground() was
depricated, but even if I were to set it to the foreground, if the app
is killed, the service is killed as well. I need to have it run in
the background with as high of a priority as possible (again, I do
understand that this is considered "bad form", but this is a specific
app and this functionality has been requested by the client).
If I started the app (and the service, etc.), but the user, say,
answers a phone call, the app is put into the background. However,
let's say the user goes back to the home screen and starts a DIFFERENT
instance of the app, i.e., he doesn't hold down the home key to select
the already running app from the task manager but starts a completely
new one. If the service handling the bluetooth connection is still
running, how will this new instance behave? i.e., how can I get it to
connect to the bluetooth service which is ALREADY running in the FIRST
instance of the app instead of this new instance? Do I have to use
some form of a Remote service instead of a local service? This is
where I'm a little confused by things as it seems remote services and
defining an AIDL seems to create a lot of extra overhead, and since
I'm already creating a lot of overhead with the service running in the
background all the time, I want to keep that as small as possible.
How can I insure I am connecting to the same service already running?

1)
The service does not depend on an Activity. You can have it running on the background until you call stopSelf().
You can have a BroadcastReceiver that listens to the android.intent.action.BOOT_COMPLETED so your service is started when the phone is turned on.
2)
Your Activity should bind to the service. And get the info from it.
Check this question.