How to Deal with Android Size Alerts
Most alerts should not have a bug created for them. Please read on...
If the alert is for “other lib size” or “Unknown files size”:
- File a bug against agrieve@ to fix resource_sizes.py.
- ...or fix it yourself. This script will output the list of unknown filenames.
If the alert is a downstream size alert (aka, for Monochrome.apk):
- The regression most likely already occurred in the upstream MonochromePublic.apk target. Look at the upstream graphs to find the culprit & de-dupe with upstream alerts.
- If no upstream regression was found, look through the downstream commits within the given date range to find the culprit.
- Via
git log --format=fuller
(be sure to look at CommitDate
and not AuthorDate
)
If the alert is for a roll:
- Use a bisect to try and determine a more precise commit.
What to do once the commit is identified:
Debugging Apk Size Increase
Step 1: Identify where the extra bytes came from
Figure out which file within the .apk increased by looking at the size graphs showing the breakdowns.
Step 2: Reproduce build results locally
Option 1: Build Locally
- Follow the normal Android build instructions.
- Ensure you're using the same GN args as the bots by looking at the
generate_build_files
step of the build: - Save artifacts you'll need for diffing:
mv out/Release/lib.unstripped out/Release/lib.unstripped.withchange
mv out/Release/apks out/Release/apks.withchange
Option 2: Download artifacts from perf jobs (Googlers only)**
- Replace the bolded part of the following URL with the git commit hash: https://storage.cloud.google.com/chrome-perf/Android%20Builder/full-build-linux_HASH.zip
Step 3: Analyze
- If the growth is from native code:
- If the growth is from java code:
- If the growth is from images, ensure they are optimized: