|sumduration |minutes |Total duration of all unlock episodes.
|maxduration |minutes |Longest duration of any unlock episode.
|minduration |minutes |Shortest duration of any unlock episode.
|avgduration |minutes |Average duration of all unlock episodes.
|stdduration |minutes |Standard deviation duration of all unlock episodes.
|countepisode |episodes |Number of all unlock episodes
<!-- |episodepersensedminutes |episodes/minute |The ratio between the total number of episodes in an epoch divided by the total time (minutes) the phone was sensing data. -->
|firstuseafter |minutes |Minutes until the first unlock episode.
!!! note "Assumptions/Observations"
1. In Android, `lock` events can happen right after an `off` event, after a few seconds of an `off` event, or never happen depending on the phone\'s settings, therefore, an `unlock` episode is defined as the time between an `unlock` and a `off` event. In iOS, `on` and `off` events do not exist, so an `unlock` episode is defined as the time between an `unlock` and a `lock` event.
2. Events in iOS are recorded reliably albeit some duplicated `lock` events within milliseconds from each other, so we only keep consecutive unlock/lock pairs. In Android you cand find multiple consecutive `unlock` or `lock` events, so we only keep consecutive unlock/off pairs. In our experiments these cases are less than 10% of the screen events collected and this happens because `ACTION_SCREEN_OFF` and `ACTION_SCREEN_ON` are `sent when the device becomes non-interactive which may have nothing to do with the screen turning off`. In addition to unlock/off episodes, in Android it is possible to measure the time spent on the lock screen before an `unlock` event as well as the total screen time (i.e. `ON` to `OFF`) but these are not implemented at the moment.
3. We transform iOS screen events to match Android's format, we replace `lock` episodes with `off` episodes (2 with 0) in iOS. However, as mentioned above this is still computing `unlock` to `lock` episodes.