I am doing my Master thesis at the moment on WiFi positioning and in order to test my algorithms I needed to collect some data.
To do this I have written a short and very simple program for Android which simply collects the RSSI for all availible access points found by each scan and saves them to file. I have set up a BroadcastReceiver that listens on the event WifiManager.SCAN_RESULTS_AVAILABLE_ACTION and I use a Timer, here called tim, to initiate scans with a WifiManager, called wifi as follows:
tim.schedule(new TimerTask(){
#Override
public void run(){
wifi.startScan();
}
}, 0, 1000);
The problem I am having now is that the initiated scans don't seem to happen every second even if I succeed in initiating them and every now and then there are other scans initiated from some other app that gets recorded as well.
Is there any easy way to scan on a set interval and not receive the scans initiated by some other app?
The whole app can be found on https://github.com/while/RSSIMiner if it helps in any way.
Is there any easy way to scan on a set interval?
If this doesn't work well, I'm afraid not. From my experience, "hardware related" methods may not work exactly like their definition says. For example, I once created a small app which records your position every X minutes. So I call requestLocationUpdates with some minTime parameter. But my phone simply ignores the minTime value, and I get updates from the GPS as soon as they're available, whcih is not what I wanted. I posted a question about it here, and got this answer, from which we learn that prior to jelly bean, devices may simply ignore this value...
So it may be something similar now. I'd try to run this code on the latest Android version. And I don't understand that much in Wifi, but isn't 1 second a too frequent interval for scans? Perhaps the system doesn't ignore the scan request (So it returns true) but the hardware does?
Can we ignore the scans initiated by some other app?
As far as I know, it's negative here too. There are no extras contained in the SCAN_RESULTS_AVAILABLE_ACTION broadcast so you can't know which app initiated the scan.
The best solution will be to defnie your requirements. You can use the ScanResult.timestamp to determine if you should use this result or not. For example, if you're trying to get the RSSI for each access point each second, you can compare the current BSSID to previous BSSIDs. If the current BSSID was included in a scan result from the last second, you can simply ignore it. Then, it doesn't matter how many results you get.
Another, much more simple soltuion will be to create a boolean called scanInitiated and set it to true when starting a scan. When receiving the broacast, use the data only if scanInitiated is true, and then set it to false. This isn't so reliable when the intervals are short, but for long intervals it will work great.
Related
I'm developing a set of complications that I would like have regardless of the other installed apps and watch faces. Yes, at some point I am reinventing the wheel, but at the same time I am using this as a learning project. This will also ensure that I always have all the complications I use, available and that they all have the same format and style, instead of relying on 3rd party apps to provide them separately.
The set will have complications for Heart rate, gps coordinates, hours, minutes, seconds, dd/MM date, dd/MM/yy date, battery, etc.
When I started programing all this I found several problematic pieces (most likely because this is the first time I develop complications, or an app for android wear for that matter) and hence this question.
Note that some of this behavior might be specific to the Huawei Watch 2 LTE.
1) Upgrade interval push / pull.
I understand complications as data providers, whose only responsibility is to provide the data to whatever watch face is calling them. This means that we are not certain (and we rely on the watch face developer) to know about the complication and request updates accordingly. This turns some complications completely useless if not updated in time (for example display the Seconds). Could also leave to complications displaying old data (for example old GPS coordinates, old heart rate bpm).
So ok, I decided to implement ProviderUpdateRequester with the AlarmManager to push data to the watch face. The problem again, is with complications that should happen faster, like seconds, as Android will block pending intents if they are schedule too often. So in order to get around that, I decided to use Android handlers within the same service instance, which turn out to be not a good idea because of the next topic.
2) Complication lifecycle
By debugging, I found out that the instance of the ComplicationProviderService object that is executing onComplicationActivated, onComplicationUpdate, onComplicationDeactivated can be different. This means that this is not a sticky service (single instance) that will be always running, but every update creates a new instance of the service. This is problematic because of heavy initialization complications: for example GPS, or Heart Rate monitor that need to listen for new values and it might take a while to retrieve the first value. And also, for those complications that can't rely on AlarmManager, and/or need to keep some sort of state between updates executions.
3) Display aware service
To get around the previous point , let's say you have static variables on your complication service , which are initialized onComplicationActivated and disabled at onComplicationDeactivated. For example, this could be getting a reference for the LocationProvider and starting listening for location updates. This will ensure that each invocation to onComplicationUpdate will not have to perform the heavy/cold initialization and will have access to the most up-to-date data.
However, this also means that your logic will executed regardless if onComplicationUpdate is called or not.
When in ambient mode (or screen off) the watch face can decide not to update the complication by not calling onComplicationUpdate, but it's not aware of our static logic, nor the ComplicationProviderService has a callback invocation for when the screen goes into ambient mode or turns on/off. This is a problem, because in our example, if the screen is off, we are still going to be listening for GPS coordinates, and most likely draining the battery.
Sure, we can deal with this by using a combination of BroadcastReceiver (Intent.ACTION_SCREEN_ON/OFF) and DisplayManager.DisplayListener, but then again, not sure if i'm taking the correct path here, because this will mean that we are now creating services that need to be statically aware of the state of the display.
4) Detect screen on/off
The BroadcastReceiver for Intent.ACTION_SCREEN_ON/OFF works as expected when ambient mode is disabled, but it doesn't it's enabled. When ambient mode is enabled, Intent.ACTION_SCREEN_OFF is dispatched when going into ambient mode, but Intent.ACTION_SCREEN_ON is not dispatched when coming out of ambient mode. While a bit more complex, this can be accomplished by using DisplayManager.DisplayListener to get updates on the onDisplayChanged callback.
TL;RD
1) How do you ensure watch faces display your complications in a timely manner to always have correct and most up-to-date information?
2) How do you deal heavy/cold initialization of a ComplicationProviderService if everytime onComplicationUpdate is called the service instance is different?
3) Is making a long running service display-aware something crazy to do?
4) Technically the screen is still on when in ambient mode, so why is Intent.ACTION_SCREEN_OFF being broadcasted? Why isn't Intent.ACTION_SCREEN_ON/OFF symetrical when ambient mode is enabled?
5) Maybe complications shouldn't be use for exposing realtime information?
Thanks a lot
A couple of things to unpack:
Complications are not meant to be updated frequently (think minutes, not seconds) - this is to preserve battery.
ProviderUpdateRequester is designed more for (on average infrequent) irregular updates like messages coming through a chat app.
Time dependent complications - there are not an "update" as such but Wear provide ways for developers to count up / down from certain time and for displaying date related field (world clock, day of the month) without the provider sending the system updates all the time. For this last one, please refer to docs for ComplicationText.TimeDifferenceBuilder
and ComplicationText.TimeFormatBuilder.
For your use case, a more appropriate thing maybe to consider an always-on app. User uses it for a certain time period for a specific purpose so they explicitly agree to use to use more battery to track things like GPS or heart rate. For example, a lot of running apps on Wear do this.
I hope this helps.
I want to make an app (or service) that always looks for beacons every minute. If it finds one, it shall start an intentService and upload coordinates to my server.
I have looked at examples in the altbeacon documentation and they are indeed working. However, I am not able to tweak it the way I want.
The best example I found was how to start an app in the background. Here I can set the interval time, scan time, and it is doing what it should - except it only announces new beacons (didEnterRegion method).
There is also an example that continuously scans for beacons (Getting Ranging Updates from Nearby Beacons With Telemetry), but I have not been able to control the interval and scan time (even though it says it is configurable). Also, I must make sure that this will always run, and never goes into some kind of sleepmode.
Lastly, I have tried to mix all of this into my own service using various timer approaches, but I was told by a distant co-worker that the altbeacon library makes a service by itself, and I should not have to.
Does anyone have any tips on how to do this?
Edit
I have used davidgyoung's approach, since the example seems to be pretty much out of the box for me. I will need a few days to test, and get back with an update.
Doing this with the Android Beacon Library is quite straightforward, and you can use the reference app as a starting point.
It is true that you do not need to make your own service, as the library has one of its own. Using the reference app as-is, it starts up automatically on the background and scans for beacons at boot, and will restart itself within five minutes using an AlarmManager even if you kill the app.
Using this approach, simply start ranging in the Application class and process your results in a callback method in that class.
I believe you can use Estimote API for this. Manually you can create service, create instance of BeaconManager if it == null on service or your command started. Add setMonitoringListener and now you can send results from onEnteredRegion.
What's the purpose of setReportDelay for BluetoothLeScanner in Android? I can't imagine why one would get reports with delay...
From Android Official Site:
setReportDelay() takes reportDelayMillis parameter where reportDelayMillis is:
Delay of report in milliseconds. Set to 0 to be notified of results
immediately. Values > 0 causes the scan results to be queued up and
delivered after the requested delay or when the internal buffers fill
up
coming to your question:
What's the purpose of setReportDelay for BluetoothLeScanner in Android? I can't imagine why one would get reports with delay...|
As i understood the purpose of this is that sometimes when you scan for a very short period of time, not all the devices/beacons can be found, but on the second scan another one can be cought while scanning.
Ex:
Suppose you have three beacons and you made two different scans for 1s. On the first scan only single beacon is found, but on the second other beacons found too. Setting a delay will queue all of them and you will be able to show all of them. Otherwise sometimes single beacon, sometimes all of them and sometimes two of them will be shown.(This is related mostly with the frequency they transmit)
You can use also Lists for this purpose, so when a beacon is found you add them to the list and show them after some delay(using Handler/Timer). But this will require more work. So it is probably simplified with this function
setReportDelay() > 0 causes the scanner to queue up results and then fire the onBatchScanResults() from ScanCallback rather than the normal onScanResult().
This is quite useful if you need to do a UI update every few seconds: rather than refreshing your UI every time an announcement packet arrives, you can simply delay the results. Also, you get a more complete result set.
Note that your device need to be able to support this. See
http://developer.android.com/reference/android/bluetooth/BluetoothAdapter.html#isOffloadedScanBatchingSupported()
Different devices scan slightly differently. When scanning some will return the same found device multiple times per scan.
If you set a delay, Android will create a queue, and all duplicates are filtered out before that list of devices in the queue is returned.
Let me summarize my problem and what I would like to achieve.
I have a SonyEricsson X10i phone with Android 2.3.3. I realized that sometimes my phone not receiving calls even if it indicating full coverage. I checked myself in the MSC/VLR and it indicates that I registered and my phone is currently active (and also there is no IMSI DETACH flag), so it should working correctly (only the last Activate Date is a little bit old ~couple of hours, which can be good as well, without SMS/Call/Location Update), as I mentioned before the phone indicates full coverage and it seems it’s on the network. But when I tried to call it I only reached the Voice Mail.
In the MSC/VLR I see No Paging Response Cause for the call, but the phone does nothing. I tried with other SW version (4.0.3 ICS), but the same result. But I not noticed similar behaviour with a different handset (same type).
Sorry for the long summary.
So because what I described above, I ‘m trying to write an application/service which will perform GSM/UMTS location update in 15-20 minutes, but I couldn’t find any kind of procedure in android.telephony.gsm.GsmCellLocation, android.telephony.TelephonyManager which will do this for me.
My other concern is the
getState()/setStateOutOfService()/ setState() procedures from ServiceState class…
It seems they not really working. For example, when I first call the getState() I always get back STATE_OUT_OF_SERVICE, which is not true…
When I’m set the state to STATE_POWER_OFF or STATE_IN_SERVICE, at least I get back that state from getState() afterwards, but the phone does nothing for that . (Not even indicate out of coverage,etc…)
Every suggestion/comment are welcome.
I have also seen this problem many times (2 phones from the same manufacturer as yours). From your question, I understand that you want to force the phone to send an MM periodic location update (which it should be sending anyway).
This is too low level, and there's nowhere you can force this directly in the programming interface. The mobility management procedure is part of the phone stack, and is specified in detail in 3GPP TS 24.008, available from www.3gpp.org. Paragraph 4.2.2 defines when the phone is supposed to send these location updates.
The only other thing would be to try by indirect means to force the phone into a condition where it would send a location update. You might be able to do that by trying to select another network manually. If it's successful, and you then manually re-select your home network, then you would trigger a location update. If it's rejected and falls back to its home network, then I think a location update would be triggered as well.
But there would also be small costs to this - battery use while it does a networks scan, and time lost while it scans and does manual network selection.
(My personal experience is that the lost calls don't happen often enough to justify this.)
I'm doing a camera application that will automatically geo-tag each picture taken. Using
LocationManager.requestLocationUpdates() //simply to get the GPS running
LocationManager.getLastKnownLocation() //for each picture, to get coordinates
is mostly enough to simply pluck out coordinates from the phone as fast as possible, since it is still a camera application and you don't want to waste time getting GPS data.
(Assume using GPS_PROVIDER only, not NETWORK_PROVIDER pls)
However the issue will be if the user enters a tunnel for example and the phone is unable to continue getting updates. 10 minutes later when getLastKnownLocation() is called, I will get an outdated location.
I want to find a way in which I can set an 'expiry' time on the Location, depending on individual comfort level.
In other words, keep using getLastKnownLocation(), but if the data is (for example) more than 5 minutes old, don't bother with it, and I rather have a 'null' location. if the data is 2 minutes old however, that still is fine
You can implement this yourself. There's nothing in the underlying API that includes this, but it's perfectly fine to stash the time that you initiated the request (or got the last one) in your app, perhaps in a SharedPreferences. You also have to be weary of things like how fast the user is moving, etc.., so in general you might need to put a fair amount of thought effort into determining how you want to do this. There's not any way (in the API) to find out how fresh the call to .getLastLocation() will get you. For a few minutes it's probably best to employ the technique I mentioned. For a lot longer you might want to consider something like an AlarmManager (which you should be using anyway if your app runs on a timescale that is that long). You seem to be using .getLastLocation more than I do, however. I often simply just request updates and then "put the dot down" whenever I get the first update. In general I've found that .getLastKnownLocation() isn't really all that reliable, but maybe that's just because I don't use apps with my location very often.
Managed to find out that each Location returned had a time variable
long time_a = my_loc.getTime();
We can use this to compare with
Calendar cal = Calendar.getInstance();
long time_b = cal.getTimeInMillis();
long interval = time_a - time_b;
The interval is then the 'validity' of the location fix, and can be easily used for my purpose :)