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.)
Related
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.
I am working on an android project that requires communication against a BLE device.
as for now I am quite done - however I have one thing I cant solve -
I want to use a service to coomunicate against the BLE device and communicate
with thata service only by sending and recieving broadcasts.
my question is - for some reason when I try to connect to the device inside the service
by making the service extend LeScancallbak finding the device and connecting to it takes much longer and also the BLE GATT server is null (since the gattcallback is never called) however if I bind the service to activity and implement that LeScancallbak in the activity its a metter of acouple of milliseconds -
Did anyone also had the same problem or possibly have an answer to that strange behavior?
I want to use only the service to communicate against the bluetooth device since I want to stay connected to the device even when the application UI is not running (i.e. leave a background service) plus it looks more logical that connecting every activity to that service upon changing screens.
In case anyone have a better way to achieve that, I wil be happy to hear about it.
BLE has a lot of issues on Android, and implementing a service like you want will be difficult. I would recommend integrating the BLEService library produced by Ratio. The source is available on GitHub: https://github.com/RatioLabs/BLEService
I have a service that executes in 2 phones. They communicate with each other using sockets and execute some script (which may take 1-2 minutes approx.) and exchange files (using HTTP Post) between them.
I want this execution to continue, even when the screen is off, i.e acquire a Wakelock. I saw this link, but I'm not sure where to incorporate this in my code(as the device may sleep in the mid of execution). Any guidance is highly appreciated. Thank you.
I m using same app for 2 phones. In onCreate() it starts a service listening on a port. Clicking a button in phone1, does a HTTP Post of a file to phone2 and the communication keeps going on(as phone 2 also listens on a port initially).
Well, your primary objective seems to be to cause the owner of phone2 to attack you with a scimitar, since the phone2 will run out of battery.
That being said, your HTTP daemon will need to be in a service, where you acquire and release a WakeLock (and presumably a WifiLock, since what you want won't work over most mobile data connections).
WakefulIntentService is not useful here, because it is designed for sensible scenarios, where we need to keep a WakeLock acquired only for a brief period of time, to complete some specific task. In your case, you need to keep your WakeLock acquired indefinitely, as you have no idea when work might need to be done.
I m not sure where to incorporate this in my code.
In the service, presumably. You will probably acquire the WakeLock in onCreate() of the service and release it in onDestroy() of the service. If you wish to avoid a scimitar-related demise, you will make sure that the user has plenty of control over exactly when this service is running, and therefore have plenty of control over when this WakeLock is in force.
Why not implement that functionality with a service? See here. I'm not very experienced in android development but have worked recently in a project where a functionality similar to that was implemented using services.
I have a VOIP app that I would like to always run in the background to make it responsive to incoming calls. Reading through some forums I found running the app in the background would cause a battery drain.
Are there good practices that I should follow so as to run the app in the background?
Reading through some forums I found running the app in the background would cause a battery drain.
It is more that having something run all the time increases your opportunity to drain the battery.
Are there good practices that I should follow so as to run the app in the background?
Being a VOIP app already violates some of the "good practices". For example, you will need to (try to) have a service that runs forever, to maintain your open socket connection to the VOIP server. And, depending upon how your networking is set up, you might need to try maintaining a WifiLock, which will drain the battery.
Generally speaking, then, you just want to make sure that your service is doing as little as possible except when a call is in progress. For example, while you may need to send packets over to the VOIP server periodically to keep your connection alive, try to do that as infrequently as you can.
There are many smart VoIP applications that use Push Notification feature. That will not eat up as much battery, but you must have a consistent internet connection. One such option is Axvoice. Check out their apps at: http://www.axvoice.com/support/mobile-voip-applications.html
They will also run in the background like other apps, but the difference between Axvoice and other apps is you can reduce battery consumption because it will not be communicating with live servers all the time. Please have a look at this: http://www.wikihow.com/Save-Battery-Power-on-an-Android
Use a Broadcast Reciever. It is documented here
http://developer.android.com/reference/android/content/BroadcastReceiver.html
A BroadcastReciever will execute it's code when the specified broadcast is broadcasted through the system. In other words when you receive a call the system sends out a broadcast saying that there is an incoming call. If your receiver is made to pick up on that broadcast than it will react. Think of it like the Android system is broadcasting a lot of different radio stations and a BroadcastReciever is like a radio. You can set it to pick up whatever broadcast you want and execute some code when it does.
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.