The NextAction date has arrived: 2017-06-07

CCing pschmidt@ directly

Hey Peter, do you have any estimate of when you might be able to accommodate this?

You can get at the Google app settings only after the device has had a one time network connection established.  Want me to proceed and if so o.k to do this on the fly or wait for current build to complete?

You can go ahead and do it on the fly. Thanks Peter!

The NextAction date has arrived: 2017-06-08

Done.

Silly question,  Wiping these as part of the provisioning step will reset it back?

... I had no idea that these were wiped as part of the provisioning step :-(

Are they flashed with a completely new image every run, then? Do you have any idea who controls the image that we flash onto the phones?

(sullivan@ suggested talking to vhang@ and jbudorick@, so I'm going to do that)

I'm going to assign this back to myself for now and keep an eye on the phones to see if it sticks.

The NextAction date has arrived: 2017-06-09

After talking with jbudorick@, it sounds like the phones aren't actually wiped during the provisioning so much as some of the settings are set back to a default state. pschmidt@, is there any chance that you could check just one of these phones (preferably an actual perf bot running tests rather than a bisector) to see whether it looks like your changes stuck?

The good news is that the initial results look *very* promising.

Because Telemetry collects and aligns systrace with the power trace, we can see in trace viewer exactly what's happening on the phone during the benchmark.

I've attached screenshots of what the kernel thread looks like before and after Peter disabled 'Ok Google' detection on these phones. There's a *huge* difference in activity on the kernel thread, where the trace events associated with microphone activity go from lots (2300) to zero from what I can tell.

Deleted: before.png 66.5 KB

	before.png 66.5 KB View Download

Deleted: after.png 64.8 KB

	after.png 64.8 KB View Download

Also, just for easy reading: here's a direct link to the power.idle_platform graph that we're trying to make more stable.

https://chromeperf.appspot.com/report?sid=c68f0acc47311d231434db076b5fec95d25de315e19a0909fcbe3409f0ee887f

The NextAction date has arrived: 2017-06-12

Re: #15.  Spot checking a couple shows that disabling the "O.K Google" detection has stuck.

Great to hear!

jbudorick@/sullivan@, do you have any idea how we could

1) Disable "Ok Google" detection on all existing Android phones in the performance labs and
2) Ensure that "Ok Google" detection is disabled on all new Android phones added to the performance labs in the future?

Not sure about (1) but for (2), I imagine that we can
1) Fail a benchmark if the "OK Google" is not disabled.
Or
2) Add something like swarming quarantine check that will stop phones that do not have "OK Google" disabled.

The NextAction date has arrived: 2017-06-14

Snoozing this for another week. I sent an email to the internal alias of engineers responsible for this feature, asking whether it's possible to disable it over ADB.

I reached out to the Hotword eng team and they suggested revoking the microphone permission of the GSA with:

adb shell pm revoke com.google.android.googlequicksearchbox android.permission.MICROPHONE

ben, where should I add this command? Is there some swarming bootstrap code I should modify?

This function would be a good place for that: https://chrome-internal.googlesource.com/infradata/config/+/b524f20e908b6a822b7f5082337272ac2de23578/configs/chromium-swarm-dev/scripts/android.py#216

That does device-provisioning stuff like disabling setup-wizard and screensaver. Once it's running on dev and looks good, you can roll the change to prod's bot config (https://chrome-internal.googlesource.com/infradata/config/+/master/configs/chromium-swarm/scripts/android.py)

I worry that, by putting this in the swarming code rather than Telemetry code, people are going to have a hard time doing local performance testing.

Ned, is there a precedent that indicates where you think we should put this code? It seems like, right now, some of this type of code is in swarming whereas some of it is in Telemetry, but I can't tell if there's a consistent store for which code we place where.

I think it should look s.t like this:
1) Device setup (once per device's life time) --> swarming
2) Test setup (once per test run) --> Telemetry

Got it. In that case, I think it makes sense to put this in the swarming code.

@Charlie: though I think the actual code should still be owned by us. My hope is we gonna make s.t like a script, and we just need to find a place in swarming code to invoke that script as a subprocess. :-)

Got it. Yea, that probably makes sense. I'm not sure at what point during the build process we have access to the Catapult repo, but I imagine that this would be some binary at, for example, telemetry/bin/prepare_perf_device that would run before any Telemetry tests? Any opinions on where such a script should go?

My idea is that script will not depend on Telemetry/, but Telemetry/ will depends on it (similar to https://cs.chromium.org/chromium/src/third_party/catapult/common/battor/battor/ & how swarming infra is using this for dividing 7 battors on 7 phones).

Maybe we can make a top level module in catapult/ named perf_stablizer/? :-)

Marking this as "Available" given my recent pivot away from power/CPU noise