Wi Fi Scan Generation
Originally the idea was to generate wifi measurements with corresponding location data (longitude, latitude). Afterwards these measurements should've been used to create a wifi-heatmap of all the measurements taken by the TCA users. Since the contributor responsible for the heatmap left the project, the measurements are currently functional but disabled.
A full measurement consists of:
- date - the date it has been taken
- ssid - "name" of the wifi access point (AP)
- bssid - MAC address of the AP
- dBm - the signal strength
- accuracyInMeters - the horizontal accuracy of the location measurement
- latitude
- longitude
To gather all this data, the following approach was used:
Whenever a user connects to any wifi-hotspot, a wifi.STATE_CHANGE triggers a NetworkChangeReceiver. This receiver then initiates a WifiManager scan by calling startScan(). After the scan finishes, its details are then available in another listener: "ScanResultsAvailableReceiver". It was already implemented to take care of the automatic eduroam setup. The onReceive method is then extended by adding a check, looking for any networks with SSID "lrz" or "eduroam" within the scan results. To this point, the available information does not yet contain any location information. It is therefore necessary to pass each matched wifi-scan to the storeWifiMeasurement method. In it, the Android-SDK's location manager is queried by requesting a single location update. The information about longitude and latitude is then stored together with its location information into a local SQLite table: "wifi_measurement". If there was at least one match, a handler is started within a customizable random timeframe. This handler is used for starting the next wifi-scan and therefore leads to a recursion. This recursion only stops when there was no eduroam/lrz - SSID found in the last WifiManager-Scan.
The following three classes therefore need to be explained further.
It is instantiated and started, each time the last scan found an lrz/eduroam SSID in the scan results. After a randomly generated amount of seconds, it then starts the next wifi-scan, which leads to a recursion. This recursion breaks by not starting a new postDelayed call when the last scan results didn't include a SSID match. It is implemented as a singleton and therefore takes care there is always only one instance at a time. Its method startRepetition does the previously mentioned random number generation and after waiting for this time period, starts the new WifiManager scan. The amount of seconds is generated inbetween MIN_TIME_PASSED_IN_SECONDS and MAX_TIME_PASSED_IN_SECONDS.
Since synchronising to the backend after each individual measurement is highly inefficient, the WifiMeasurementManager handles the insertion of deletion of measurements to a local SQLite table: "wifi_measurement". Its uploadMeasurementsToRemote (i.e. the backend) method is called, each time StartSyncReceiver receives a broadcast message. This currently means the maximum amount of time passed inbetween the last sync to the backend is StartSyncReceiver's "START_INTERVAL", which is currently set to three hours. Given that a user is connected to the internet, this means that his scans will be synchronized to the backend at least every three hours. It is important to note that the uploadMeasurementsToRemote - method also purges all the locally stored wifi-measurements after a successful sync.
The custom implementation of the LocationListener interface is responsible for requesting the single position update. It is required as additional information for giving the signal-strength a spatial mapping. It's also possible to specify a MINIMUM_ACCURACY_IN_METERS, which is the minimum threshold of horizontal accuracy a measurement needs to fulfill to be stored (and later synchronised). The same goes for the constant value: MAX_MILLISECONDS_PASSED, which restricts the "age" of a location measurement to be not older than the amount of milliseconds specified.
A retrofit endpoint was added. It receives an array of wifi-measurements and stores each individual measurement to the TCA's server database. It automatically skips faulty measurements.
The accumulated data can be used for creating a wifi-heatmap, as it was previously planned. An additional idea might be to determine a user's current location without GPS, solely by knowing the surrounding APs and their signal strength.
How to enable?
Utils - InternalSetting "WIFI_SCANS_ALLOWED" to "true" Utils - InternalSetting "WIFI_SCAN_MINIMUM_BATTERY_LEVEL" to a float inbetween 0 and 1.
WIFI_SCAN_MINIMUM_BATTERY_LEVEL specifies the minimum amount of battery the user's phone needs to have to start new wifi-scans.