Android Built-in Metrics
The Bort SDK contains built-in support for collecting various types of metrics from Android devices.
Some are automatically collected, and some require configuration in the Memfault dashboard.
To record custom metrics, see the Reporting APIs.
Be sure to configure which metrics you would like to be Timeseries and Attributes in the Metrics Dashboard.
Battery (and related) Metrics
Collected Since Bort 3.0
Bort collects metrics from the Android batterystats subsystem. This includes data from many components which may affect battery usage (Radio, Wifi, Bluetooth, Screen, CPU, GPS), in addition to statistics about the battery itself.
These metrics are displayed on the device timeline:
And several summary metrics are also available. Each metric is listed below, noting the batterystats output code that it is derived from (they are defined in the batterystats source):
audio_on_ratio
: percentage of time (0.0-1.0) audio was switched on (see batterystatsa
).battery_health_not_good_ratio
: percentage of time (0.0-1.0) when the battery health was not "good" (g
) (see batterystatsBh
).battery_level_pct_avg
: mean battery level (0-100).bluetooth_scan_ratio
: percentage of time (0.0-1.0) with bluetooth LE scanning active (see batterystatsbles
).cpu_running_ratio
: percentage of time (0.0-1.0) CPU was running (see batterystatsr
).cpu_resume_count_per_hour
: number of times per hour CPU became active (see batterystatsr
).cpu_suspend_count_per_hour
: number of times per hour CPU became inactive (see batterystatsr
).cpu_wake_count_per_hour
: number of individual CPU wakeups (see batterystatswr
).doze_full_ratio
: percentage of time (0.0-1.0) spent in full Doze mode (see batterystatsdi
).doze_ratio
: percentage of time (0.0-1.0) spent in any (full or light) Doze mode (see batterystatsdi
).gps_on_ratio
: percentage of time (0.0-1.0) GPS was switched on (see batterystatsg
).max_battery_temp
: maximum battery temperature (°C x 10) during the period (see batterystatsBt
).phone_radio_active_ratio
: percentage of time (0.0-1.0) the phone radio was active (see batterystatsPr
).phone_scanning_ratio
: percentage of time (0.0-1.0) the phone was scanning (see batterystatsPsc
).phone_signal_strength_none_ratio
: percentage of time (0.0-1.0) the phone signal strength was "none" (0
) (see batterystatsPss
).phone_signal_strength_poor_ratio
: percentage of time (0.0-1.0) the phone signal strength was "poor" (1
) (see batterystatsPss
).screen_on_ratio
: percentage of time (0.0-1.0) the screen was on (see batterystatsS
).screen_brightness_light_or_bright_ratio
: percentage of time (0.0-1.0) the screen brightness was "light" (3
) or "bright" (4
) (see batterystatsSb
).wifi_on_ratio
: percentage of time (0.0-1.0) Wifi was on (see batterystatsW
).wifi_radio_active_ratio
: percentage of time (0.0-1.0) Wifi was on (see batterystatsWr
).wifi_running_ratio
: percentage of time (0.0-1.0) Wifi was on (see batterystatsWw
).wifi_scan_ratio
: percentage of time (0.0-1.0) Wifi was scanning (see batterystatsWs
).wifi_signal_strength_poor_or_very_poor_ratio
: percentage of time (0.0-1.0) Wifi signal was "poor" (1
) or "very poor" (0
) (see batterystatsWss
).
These metrics would be good candidates for Timeseries metrics, to monitor fleet performance over time and find outlier devices.
Device Temperatures
Collected Since Bort 4.0
Bort regularly collects several device temperature metrics, from the HardwarePropertiesManager:
- CPU
- Device Skin
These are reported with min/max/mean values each hour. Note that each device has a different collection of sensors - an example device with one device skin sensor and two CPU sensors might have a set of metrics like this:
temp_skin_0.max
temp_skin_0.mean
temp_skin_0.min
temp_cpu_0.max
temp_cpu_0.mean
temp_cpu_0.min
temp_cpu_1.max
temp_cpu_1.mean
temp_cpu_1.min
These metrics would be good candidates for Timeseries metrics, to monitor fleet performance over time and find outlier devices.
Storage Usage
Collected Since Bort 4.3.0
Before Bort 4.3.0, these metrics were collected differently (as
storage.primary.*
).
Bort regularly collects device storage usage metrics from the
Environment.getDataDirectory
(getFreeSpace
/getTotalSpace
):
storage.data.bytes_free
storage.data.bytes_total
storage.data.bytes_used
storage.data.percentage_used
These metrics would be good candidates for Timeseries metrics, to monitor fleet performance over time and find outlier devices.
Installed App Versions
Collected Since Bort 4.0
Bort can collect installed app versions as metrics. These can be configured on the Memfault Settings Dashboard, on the Data Sources tab, by entering package names to collect:
Wildcards can be used, to collect multiple apps sharing the same package root.
Each collected version is stored as a metric, prefixed with version.
:
These metrics would be good candidates for Attributes, to enable e.g. searching for devices with a given app version installed, or checking the installed versions on a specific device.
System Properties
Collected Since Bort 4.0
Bort can collect Android System Properties. These can be configured on the Memfault Settings Dashboard, on the Data Sources tab, by entering each property to collect:
Each collected property is stored as a metric, prefixed with sysprop.
:
These metrics would be good candidates for Attributes, to enable e.g. searching for devices with a given system property, or checking the properties for a specific device.
Connectivity Metrics
Collected Since Bort 4.4.0
Bort collects metrics describing connectivity changes on the device:
connectivity.type
: current primary connectivity:NONE
,WIFI
,CELLULAR
,ETHERNET
, orUNKNOWN
. Aggregated metrics for each type e.g.connectivity.type_CELLULAR.secs/hour
.airplane_mode
: tracks whether airplane mode is enabled.connectivity.validated
: tracks whether current connectivity has been validated for internet.connectivity.captive_portal
: tracks whether device is connected to a captive portal.