What's the goal here? All telemetry slugs already include a "memsize". Are you looking for more or different?

We're performing some fairly invasive changes -- not shipping fonts, whole resource directories, whole categories of drawables. I'd like for that fact to be a part of the telemetry payload, and everywhere else it's relevant -- e.g., crash reporter. Not only is this interesting on its own (how many users are on resource-constrained builds?), but it also lets us partition data -- how much better is startup time, or is it worse because Android has to downsample images?

I guess my point would be: Don't we already "know" the APK is then memory-constrained version by looking at the Android API version and the Firefox release, if, for example, we ship a memory-constrained APK to Gingerbread users?

(In reply to Mark Finkle (:mfinkle) from comment #3) > I guess my point would be: Don't we already "know" the APK is then > memory-constrained version by looking at the Android API version and the > Firefox release, if, for example, we ship a memory-constrained APK to > Gingerbread users? We can infer it, but there's always sideloading, distributions, third-party app stores, etc. which can result in an install that's not the app we expect it to be. Generally: it's a tiny flag, and makes the telemetry analysis a 100%-confident matter of picking an item from a dropdown. Thinking more long-term: heuristics might scale to 2 builds, but start to fall down if we ship, say, Gingerbread, HC-JB, JB+, with tablet and phone varieties. We're going to want to be able to spot issues and crashes based on flavors.

Not critical for bug 1100361

We don't support resource constrained builds anymore.