All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=890754

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=46bc2250b177f37fad60964423e38b75130e9aefd00b98c10083d0ad3dec7cca


Bot(s) for this bug's original alert(s):

Android Builder Perf

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8933859950295285872

It's not clear to me whether or not this increase was expected.
Please have a look and either:

1. Close as “Won't Fix” with a short justification, or
2. Land a revert / fix-up.

Hi, I'm trying to run `tools/binary_size/diagnose_bloat.py 9003d89c3b423e96556dfaba58ce62a596bc3fe0 --cloud` to diagnose this further, but I'm getting this result:

I     31 Processing 2 commits
I   3095 Downloading build artifacts for c02251d23a5d96962aec9f0c2e92bb5909fb757c
E   4257 Failure: Unexpected error while downloading gs://chrome-perf/Android Builder/full-build-linux_c02251d23a5d96962aec9f0c2e92bb5909fb757c.zip. It may no longer exist on the server or it may not have been uploaded yet (check https://build.chromium.org/p/chromium.perf/builders/Android%20Builder). Otherwise, you may not have the correct access permissions. Process output:
ServiceException: 401 Anonymous caller does not have storage.objects.get access to chrome-perf/Android Builder/full-build-linux_c02251d23a5d96962aec9f0c2e92bb5909fb757c.zip.

Do you know what I need to configure / who to contact to get this to work?

Try running "gsutil.py config" to authenticate (one time step).

It's probably even more useful / easier to look a the binary size trybot result for the change:
https://ci.chromium.org/p/chromium/builders/luci.chromium.try/android-binary-size/64943

(need to click on "show experimental" to have the bot show up. The bot was made non-experimental shortly after your change :P)

OK, I think this is expected. Most of the binary size is from the Blink bindings that were landed (~10k) and components of the net/third_party/quic library (~30k).

Chrome already pulls in most of net/third_party/quic. The increase here is because we set up both sides of a QUIC connection (client & server) to support peer-to-peer use cases, so now the QUIC server-side components are also included in the binary rather than just the client-side components.