1826718 - Collect data about available system memory on Android

Status: NEW

(Fenix :: Experimentation and Telemetry, task, P2)

Description

[Marco Castelluccio [:marco]]

We have "system[1].memory_mb" in telemetry.main, but we don't have anything for Android.
We would need to collect this data through Glean instead (or both Telemetry and Glean).

Comment 1

[Marc Leclair [:mleclair]]

Do you know when we would want to gather that information? I think it would be possible to add. I think we just need to know when we want to collect this information.

Comment 2

[Marco Castelluccio [:marco]]

Is there a ping for mobile similar to the main telemetry ping?

Comment 3

[Jonathan Almeida [:jonalmeida]]

After speaking with data engineering, we should probably put this in our metrics ping, and collect it initially in our setStartupMetrics and then maybe use a MemoryDistribution metric type to record multiple samples at different times.

Comment 4

[Jonathan Almeida [:jonalmeida]]

(In reply to Jonathan Almeida [:jonalmeida] from comment #3)

After speaking with data engineering, we should probably put this in our metrics ping, and collect it initially in our setStartupMetrics and then maybe use a MemoryDistribution metric type to record multiple samples at different times.

Had some casual conversations with others and now I'm questioning how accurate this data would be. The amount of memory that we would report are based on what other apps a user has in memory, and thus what is available to us will change and incorrectly give us unhelpful estimates.

Looking at only how much RAM our user's devices have is also not enough to know what we have accessible to us. Maybe dalvik.vm.heapsize (based on the build.prop) is something we could get a better estimate on - I'm not sure if that's a value we can retrieve though.

Comment 5

[Kayacan Kaya [:kaya]]

Hi :marco!
I was wondering if you have any expectations/requirements/recommendations for the collection of this data that would answer the questions where/how/what and many more?

---

From our end, I can propose the following as answers to those questions:
1- What to collect?
-- the available system memory that can be used by any process on the device and the current runtime memory that our app&processes are using. So as far as I checked the available APIs, we cannot exactly know how much memory available particularly for our processes, but rather for the general use by any processes.

2- When to collect?
-- we can have a task running in the background that collects those data for every [predefined time according to our data on how long an average session is] seconds in an active or backgrounded app session.

3- How to measure?
-- after collecting data periodically per app session, before the app gets killed, we can get an average of those locally collected values and record the average memory usages (both the average of available memory and the average of runtime memory that our processes are consuming).

What are your thoughts on those? We will propose to prioiritize this ticket so it gets shipped before some of the important features so we start seeing some data regarding our memory usage prior to big changes and analyze their impacts as well.

Comment 6

[Marco Castelluccio [:marco]]

This sounds reasonable to me, perhaps you can check what we are doing on Desktop to see if there's anything additional?

Is it worth/possible measuring the memory usage at the time we get killed by the OS? Or when we receive memory pressure events?

When I filed this bug, my intention was to have data to be able to tell if a given amount of additional memory usage would be OK or too much. I'd say what you propose should help answering that question.

Comment 7

[Kayacan Kaya [:kaya]]

Hi :marco,

I linked the bug related to enhancing tab kill telemetries. I plan to record ApplicationExitInfo which will have the last PSS and RSS values available for a process at the time that gets killed. I will distinguish between the process kills by checking the reason for the kill and REASON_LOW_MEMORY is one of them. This information will also be useful for us to have better analysis on the tab kills telemetries, that's why I wanted to link that ticket here.