1525606 - Consider using a different value for the `os` field in the baseline ping

Status: RESOLVED FIXED

(Toolkit :: Telemetry, enhancement, P1)

Description

[Alessio Placitelli [:Dexter]]

(In reply to stefan from bug 1520182 comment #10)

@dexter i wonder if recording the SDK version (?) like 21 is a good idea for os_version

there really are three values possible for a devicve it seems: FireOS 6.3.0.1, SDK Level 21, Android 7.0.1

and I bet we want to understand all of them in reporting

We should consider filling the os field with some information other than the Build.VERSION.SDK_INT, as we currently do and as telemetry-android did.

Comment 1

[Alessio Placitelli [:Dexter]]

Hey Megan, Frank! What do you think of the proposal from comment 0? It has a few implication for analysis, since I think it would work different than the legacy telemetry-android. I'm not even sure what's the value reported by Firefox for FireTV in that case.

Comment 2

[Frank Bertsch [:frank]]

Looks like Fire TV just reports the major version.

Can we instead do what we did for manufacturer/model and split these up? i.e. have SDK version as a separate field.

Comment 3

[Alessio Placitelli [:Dexter]]

(In reply to Frank Bertsch [:frank] from comment #2)

Looks like Fire TV just reports the major version.

Can we instead do what we did for manufacturer/model and split these up? i.e. have SDK version as a separate field.

Interesting. Looks like the way to tell the "os" apart in that case is by using the app name. The value for os is "Android" for both vanilla Android and FireTV.

@Stefan, do you know (or can redirect the ni?) how can we get the "proper" OS name on Android? i.e. FireOS vs just Android. Since we care about this, what do you think of this proposal:

• platform_name = "Android", "iOS", "Windows", "Linux", whatever :)
• os = The specific os name (e.g. "FireOS" or fall back to platform_name)
• os_version = the displayed OS version, e.g. the one from Build.VERSION.RELEASE
• android_sdk_version = android specific SDK version for the device.

@all - what do you think of the above proposal? Introducing an Android specific field makes me a bit itchy, but it seems we might be running into something similar for bug 1526395.

Comment 4

[Travis Long [:travis_]]

It's possible we could look up the android sdk version from the os version. That could help with overfitting to android here and having an android specific metric.

Comment 5

[Frank Bertsch [:frank]]

Android-specific fields are fine so long as they aren't reported for other platforms. Let's plan on keeping those as part of the glean library and reported in our major pings (baseline, event, metrics).

The bigger question for these kinds of fields is: given a custom ping, how can they easily include these metrics without having to copy+paste the code? For example, if they include glean/os_version in metrics.yaml and add their own pings, could we handle that in the client? (That's just one option, you'll probably have better ideas).

This is probably an issue we can tackle separately in the future as we build out more of the non-default pings.

Comment 6

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Regarding reporting Android vs FireOS, please loop in Chenxia, who probably knows details best.

Comment 7

[Chenxia Liu [:liuche]]

We can look up the Android OS version, and possibly the device name (e.g. AFTT for Fire TV Stick).

However, Severin did some research recently and we don't have access to the Device OS version through the Android APIs(at least for Fire TV) - we could hard-code the platform (e.g. Fire OS), but note that it's not dynamic, and it would also not include the actual OS version (e.g. 5.2.6.6). It's possible that there's some closed/hidden API that might have that, but I wouldn't count on it.

Comment 8

[Alessio Placitelli [:Dexter]]

(In reply to Chenxia Liu [:liuche] from comment #7)

We can look up the Android OS version, and possibly the device name (e.g. AFTT for Fire TV Stick).

However, Severin did some research recently and we don't have access to the Device OS version through the Android APIs(at least for Fire TV) - we could hard-code the platform (e.g. Fire OS), but note that it's not dynamic, and it would also not include the actual OS version (e.g. 5.2.6.6). It's possible that there's some closed/hidden API that might have that, but I wouldn't count on it.

I had a quick conversation with Serverin, and turns out he knows no easy way to access the Fire TV version through public and stable APIs:

The normal method for querying the OS version in Android doesn't work on Fire OS (it returns the Android version it was forked from).

Comment 9

[Alessio Placitelli [:Dexter]]

(In reply to Alessio Placitelli [:Dexter] from comment #3)

• platform_name = "Android", "iOS", "Windows", "Linux", whatever :)
• os = The specific os name (e.g. "FireOS" or fall back to platform_name)
• os_version = the displayed OS version, e.g. the one from Build.VERSION.RELEASE
• android_sdk_version = android specific SDK version for the device.

Unfortunately, there seems to API to tell Fire OS vs Android apart. The further we can go, for now, is:

• os = The os name (e.g. "Android", but we might make this overridable in the future so that apps can change this to "Fire OS")
• os_version = the displayed OS version, the one from Build.VERSION.RELEASE, e.g. "8.1"
• android_sdk_version = android specific SDK version for the device, e.g. SDK 21

Comment 10

[Alessio Placitelli [:Dexter]]

Sebastian helped verify this, looks like Build.VERSION.RELESE is what we want and the current approach is sound.

Nexus 5

Build.VERSION.BASE_OS =
Build.VERSION.CODENAME = REL
Build.VERSION.INCREMENTAL = 3437181
Build.VERSION.PREVIEW_SDK_INT = 0
Build.VERSION.RELEASE = 6.0.1
Build.VERSION.SDK_INT = 23
Build.VERSION.SECURITY_PATCH = 2016-10-05

Fire TV

Build.VERSION.BASE_OS = NHG47K
Build.VERSION.CODENAME = REL
Build.VERSION.INCREMENTAL = 0001376148612
Build.VERSION.PREVIEW_SDK_INT = 0
Build.VERSION.RELEASE = 7.1.2
Build.VERSION.SDK_INT = 25
Build.VERSION.SECURITY_PATCH = 2018-07-01

Comment 11

[Alessio Placitelli [:Dexter]]

Attachment: Schema PR

Comment 12

[Alessio Placitelli [:Dexter]]

Attachment: Implementation PR

Comment 13

[Alessio Placitelli [:Dexter]]

Attachment: glean-android-sdk-version.md

Comment 14

[Chenxia Liu [:liuche]]

Comment on attachment 9053849 [details]
glean-android-sdk-version.md

1) Is there or will there be **documentation** that describes the schema for the ultimate data set available publicly, complete and accurate? 
Yes, in metrics.yaml: https://github.com/mozilla-mobile/android-components/blob/f3bcad20cef5111f8091469292eb07ca9d80db97/components/service/glean/metrics.yaml

2) Is there a control mechanism that allows the user to turn the data collection on and off? (Note, for data collection not needed for security purposes, Mozilla provides such a control mechanism) Provide details as to the control mechanism available.

Yes, all library consumers must provide a data control toggle


3) If the request is for permanent data collection, is there someone who will monitor the data over time?**
Yes, telemetry team [e-mail]

4) Using the **[category system of data types](https://wiki.mozilla.org/Firefox/Data_Collection)** on the Mozilla wiki, what collection type of data do the requested measurements fall under?  **
Type 1

5) Is the data collection request for default-on or default-off?
default on

6) Does the instrumentation include the addition of **any *new* identifiers** (whether anonymous or otherwise; e.g., username, random IDs, etc.  See the appendix for more details)?
No, collects android SDK version

7) Is the data collection covered by the existing Firefox privacy notice? 
Yes

8) Does there need to be a check-in in the future to determine whether to renew the data? (Yes/No) (If yes, set a todo reminder or file a bug if appropriate)**
No

9) Does the data collection use a third-party collection tool? **If yes, escalate to legal.**
No