Not all alerts should not have a bug created for them. Please read on...
&rev=COMMIT_POSITIONin the URL.
android-binary-sizetrybot result for the roll commit.
--apply-patchwith the fixing commit (last one in the range).
tools/binary_size/diagnose_bloat.py AFTER_GIT_REV --reference-rev BEFORE_GIT_REV --all [--subrepo v8] [--apply-patch AFTER_GIT_REV]
BEFORE_GIT_REVwould actually be
Binary-Size:footer clearly justifies the size increase, silence the alert.
Otherwise, file a bug (TODO: Make this template automatic):
Caused by “First line of commit message”
Link to size graph: https://chromeperf.appspot.com/report?sid=6269078068c45a41e23f5ee257da65d3f02da342849cdf3bde6aed0d5c61e450&num_points=10&rev=$CRREV
Link to trybot result: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/android-binary-size/$TRYJOB_NUMBER
Debugging size regressions is documented at: https://chromium.googlesource.com/chromium/src/+/master/docs/speed/apk_size_regressions.md#Debugging-Apk-Size-Increase
Based on the trybot result: 20kb of native code, 8kb of pngs. (or some other explanation as to what caused the growth).
It's not clear to me whether or not this increase was expected.
Please have a look and either:
- Close as “Won't Fix” with a short justification, or
- Land a revert / fix-up.
It typically takes about a week of engineering time to reduce binary size by 50kb so we'd really appreciate you taking some time exploring options to address this regression!
It typically takes about a week of engineering time to reduce binary size by 50kb so it's important that an effort is made to address all new regressions.
Figure out which file within the
.apk increased (native library, dex, pak resources, etc.) by looking at the trybot results or size graphs that were linked from the bug (if it was not linked in the bug, see above).
See //docs/speed/binary_size/metrics.md for a description of high-level binary size metrics.
See //tools/binary_size/README.md for a description of binary size tools.
See optimization advice.
If you have spent O(days) trying to reduce the size overhead of your patch and are pretty sure that your implementation is optimal(ish), then add a comment to the bug with the following:
Close the bug as “Won't Fix”.