Phone sensors plugin

Owned by Maxim Moinat
Last updated: Mar 08, 2023 by Amos Folarin
3 min read

Description

The phone plugin contains a range of connections to phone sensors.

Another overview can also be found on the radar-base website: https://radar-base.org/index.php/data-sensors/

Github

https://github.com/RADAR-base/radar-android-phone

Sensors

Movement sensors

  • Acceleration
  • Gyration
  • Steps

Environmental sensors

  • Magnetic field
  • Light
  • Battery level

Location

Includes relative coordinates from both the GPS and network.

Location data is obfuscated by converting it to locations relative to an undisclosed reference location. Location data is stored in degrees latitude/longitude with WGS84 projection. At the start of the collection, each participant gets a unique reference location. A relative location for a participant is computed by subtracting the reference location from the actual location. The reference latitude is taken as a uniform random number between -4 to 4 degrees. This way, the relative latitude is close to the real latitude and distances between locations can be accurately estimated from the relative locations. The reference longitude is taken as the first real longitude value that is collected for a participant, so accordingly this sets the first relative longitude to 0. Altitude is obfuscated in the same way as longitude. The reference locations are stored on the Passive App for purposes of calculating the obfuscated relative location but are discarded at end of the data collection process (deregistration), no access is provided to these reference locations and they cannot be collected or shared. If real location data is required this can be achieved on a project-level basis by setting Firebase/App Config parameters for reference location to a reference latitude and longitude to both equal zero, so the resultant location data is not changed.



Social

  • Call log
  • Sms log
  • Contact list
  • Nearby Bluetooth devices

The identifiers (phone numbers) are pseudonymised by hashing them with an unknown key. Identifiers are hashed using the cryptographically secure HMAC algorithm, ensuring that hashes are not traceable to the actual identifier. Assigning a unique key per participant ensures that identifiers cannot be compared between participants, while they can be compared within one participant (a particular phone number always gets the same hash for that participant). The keys are not shared.


Bluetooth data. The app starts the action ACTION_SCAN_DEVICES and continues scanning until the ACTION_DISCOVERY_FINISHED event is given.

From the Android Javadoc:

This usually† involves an inquiry scan of about 12 seconds, followed by a page scan of each new device to retrieve its Bluetooth name.

† “usually” indicates, it may differ between Android versions or phone models.

Interaction

  • Interaction state
  • Application usage

Sensor Characteristics

There are three characteristics defining a movement or environmental sensor. These are its sampling frequency, resolution and dynamic range. Only the sampling frequency can be configured by using Firebase remote configuration. The resolution and dynamic range depend on the hardware vendor and thus on the phone model. These characteristics can be retrieved either from the phone specifications or by installing one of the many apps on the phone that display the hardware information (search for 'sensors' in the app store).

For example, the accelerometer of the LG G2 (STMicroelectronics v1) has a resolution of 0.001 m/s2 and a range of 39.227 m/s2. 


Android data sampling rate: 

The way intervals are managed in Android is inherently imprecise, as Android tries to group several events together to reduce battery drainage.

Quote from Android:

      Your alarm's first trigger will not be before the requested time, but it might not occur for almost a full interval after that time. In addition, while the overall period of the repeating alarm will be as requested, the time between any two successive firings of the alarm may vary. 

 Sampling rates are therefore only guaranteed at the average aggregate level. These properties affect all pRMT streams that are scheduled instead of being event-driven. Examples of event-driven streams are the hardware sensors, whereas periodic sampling happens on methods like contact lists, call logs, bluetooth devices, or weather.