I'd like more info re its performance & preliminary flakiness data if possible before we add it.

It's enabled on catapult CQ, and it has been reliable enough for us there (https://build.chromium.org/p/tryserver.client.catapult/builders/Catapult%20Android%20Tryserver?numbuilds=200). For the run time, it took about 8 minutes 30 seconds with 6 Android devices.

We don't have swarming hook up in catapult CQ yet, so I don't know how to get the flakiness data from dashboard without enabling this suite on CQ or Android Chromium main waterfall first.

Ping John: what do you think of enabling telemetry_unittests on android in CQ given the information in #29?
Another proposal is we can enable this on main waterfall first before adding it to CQ. 

I think having on waterfall first is prerequisite for adding to CQ? (Although I might be wrong?)

#3: As capacity goes, I think we can handle that on ANSR. LARNG is out of the question, though.

#4: As implementation goes, we can't add it to one of the waterfall bots w/ matching configuration w/o adding it to the CQ. We could add it to a bot that doesn't have a matching CQ bot (e.g. the M64 bot), which we've occasionally done w/ other experimental suites.

+dpranke: anything else to do here before adding telemetry_unittests to android_n5x_swarming_rel?

(er, actually +dpranke)

I think you've covered it.