Yes, I think this is done on the bots by running:

$ build/android/provision_devices.py -t [Release|Debug] --disable-network --disable-java-debug

Yeah I am pretty sure we do on the bots. Just think this should happen in general, or people will fail to reproduce benchmarks locally.

+dtu, aiolos, rnephew

We have a Q2 goal to normalize a lot of the setup in the various recipes that run telemetry. But we didn't think about this part of running locally. Does anyone know why this is in the recipe but not locally?

(And yes, crbug is the right place for run_benchmark bugs)

+nednguyen

We don't yet have a good way to differentiate what setup steps happen in Telemetry vs outside of Telemetry. In general, I don't think there's a way to guarantee a local run can reproduce the environment of a bot run (other than what Ned called a "best effort"), so I'm not yet convinced we can even support local runs.

I'm not 100% sure if it will be identical, but if you run the provision_devices script in build/android you can get pretty close to on bot setup.

Yeah, from our discussion last time, for environment preparation step do not have severe side effects, we should move it to telemetry: enable stay awake & disable rotation seems ok in this case. For the ones that have severe side effect like killing all the background services/wait few hours for the device to cool off, we shouldn't put them in telemetry.

provision_devices is a pretty big hammer (iirc it wipes the device by default).
I tend to agree with #8, disabling rotation and forcing awakeness seems to belong more to the telemetry / run_benchmark world than to the bot provisioning.

Agreed with comment 8.

We don't have anyone on our team who can take this at the moment. So let's put this in our telemetry backlog for now.

I think this would actually be part of our Q2 OKR to refactor the recipes so they are more consistent (moving things from recipe->telemetry when it makes sense sounds like part of that).