Is the following possible with the current Estimote Android SDK?
Basically I want to use it for "passive geofencing", and be able to add geofenced reminders that will trigger when I'm near a beacon, even if the app is not running or has not been opened since the last phone reboot.
Background monitoring now is implemented in the SDK.
Keep in mind that in order to have monitoring working, a service (BeaconService) that works in the background needs to be running.
In order to achieve that you need to in your implement boot broadcast receiver (android.intent.action.BOOT_COMPLETED) which would start the service.
Right now only ranging is implemented in Android SDK. Monitoring is going to be implemented in the next version of the SDK.
Once this is done you could write your own on boot broadcast receiver (in your app) that would start monitoring selected regions.
What is the status of this feature?
Has the Android SDK been updated with passive geofencing yet?
Thanks, @Wiktor, can you clarifiy a bit.
"In order to achieve that you need to in your implement boot broadcast receiver (android.intent.action.BOOT_COMPLETED) which would start the service.
"
Which service should be started? Is it com.estimote.sdk.service.BeaconService ?
Isn't it started normally with another call (The Android SDK somehow starts this service)?
Yes, it should start Estimote service by starting monitoring a region.
@Wiktor: You're saying that if we want the app to wake up after geofencing, we should start the Estimote service (from the BroadcastReceiver) by starting to monitor a region.
Now, since we don't want the app to be visually opened to the user every time they boot their device, the way to "start the Estimote by starting to monitor a region" would be to let the BroadcastReceiver start a custom service, which in turn would fire the beaconManager.connect() and beaconManager.startMonitoring() commands. Right?
If so, how can you integrate these commands in a service? Is it like the example on the Estimote site? Where:
...onCreate creates the BeaconManager and defines the MonitoringListener or RangingListener
...then onStartCommand calls the connect() command and starts ranging or monitoring
...finally onDestroy calls disconnect()
Pretty much as you said.
Your app has been waken up after geofencing event. You create BeaconManager and store it in your Application object. Then you fire up ranging/monitoring. You cannot call disconnect() in onDestroy since it would result in stopping ranging/monitoring.
@WIktor, thanks for your clarification. Note that I'm talking about the onCreate, onStartCommand and onDestroy handlers of a service. The service does not get destroyed except when the user explicitly chooses to, and in that case it is only logical that the ranging/monitoring should stop.
Hi,
did you make any progress in this or do you have an idea for implementing the iOS 7.1 behaviour on android . There, the enterInRegion-method is called, even if app is killed (not running in background)
I always thought this is no problem on android:
- App is killed manually by the user
- The service for monitoring is still running in the backend
Possible: Services (START_STICKY), startForeground and AlarmManager, Broadcast Receiver (for waking up after device reboot)
But I am still struggling with the use case, if the app is killed by the user. Do we need to restart monitoring every ten seconds with AlarmManager? Or is startForeground with an icon in the actionbar the only possibility? Or do we need to couple event to device reboot -user needs to reboot - or any other event ?
Anyone implemented this?
All the best,
Sascha
Hi Sascha, thanks for checking in.
You mention a few techniques that do little bits of what you want:
- STARTSTICKY has no effect when a user has killed the app, it only helps when the service was killed due to memory issues. This is new in Android 4.3 and it seems to be a conscious choice not a bug.
- startForeground only helps you to keep your app alive longer in case of memory scarcity. So it helps prevent the need for STARTSTICKY but it is of no use when the user kills the app
- AlamManager: I haven't tried it, but my guess is that Android will kill any alarm managers associated with an app if the user actively kills the app. Same logic as with STARTSTICKY.
Really the only thing that doesn't get killed is the BroadcastReceiver. And it can only listen for a few relevant events. You can get part of the way by telling your BroadcastReceiver to listen for the USERPRESENT event. Any time the user unlocks their screen after killing your app, this will restart your app. This is the only event which a BroadcastReceiver can hear that relates somewhat to your user's intention of being informed or not (aside from BOOTCOMPLETED of course). Other events that the receiver can pick up, which you might use for a hacky solution if you are desperate, are POWERCONNECTED, POWERDISCONNECTED, BATTERYLOW, BATTERY_OKAY.
My question is: do you really want this behavior at all?
When a user swipes the app out of their 'recent apps' list, that's a pretty definitive sign that they don't want to be bothered by your app anymore. Not now and not again until they tap the app's launcher icon.
Look at it from the perspective of an average user, who is unlikely to know they can kill a "service" in their settings. Suppose they are momentarily annoyed by your app continuing to push itself to the foreground. Suppose they swipe your app from the 'recent apps' list to get rid of it.
And then your app reappears after ten or twenty seconds.
I for one would seriously consider uninstalling the app right then and there, and addding a negative review in Google Play just for the heck of it.
I hope this helps you all at Estimote and anyone else.
Thanks for your detailed answer Wytze.
I found a nice 90% solution. I implemented an IntentService according to http://stackoverflow.com/questions/15758980/android-service-need-to-run-alwaysnever-pause-or-stop
and also have a TimerTask in it.
After the app is killed manually, the service and timer task is still running or will be restarted by the system (if memory is ok). Android 4.3 .
So I think this is correct, works and also not as hacky as BATTERY_OK.
If we really need a 100% solution, then we need to develop very hacky, you are right. But the behaviour should be like in iOS 7.1 that beacons are detected, alghough app is manually killed (http://beekn.net/2014/03/apple-ios-7-1-launches-major-ibeacon-improvement/)
GhosTrack is the best application for geo fencing in Android Platform. You can use it for tracking your kids school or your sales/marketing/medical personals movement. GhosTrack is a multipurpose application. Its perfect for anything tracking in Android Platform. Its small but full of mighty features. You can also modify your track by varying time/distance. GhosTrack has a SOS button by which your kid can notify you when he/she is in danger. The most important part is GhosTrack doesn’t require any internet connection in any end. You can do the tracking with internet or even without internet. GhosTrack is available on Google Play. Free version has some restriction. Try the paid one for full phase tracking and all the other features.
Hi Abu Saleh,
Thank you for sharing details about this app! I can't see how it is connected to beacons though? :) As far as I understand it's not based on Bluetooth Smart technology. But thanks anyway!