Add fields to count packages in BackgroundDexoptJobEnded atom
This new fields should help to differentiate the "full"
background DexOpt runs (where almost every package needs to
be re-optimized, usually following a mainline or OTA update)
and the "incremental" runs (where the number of package to
re-optimize should be way lower) - at the moment the two
cases are treated in the same way when it comes to metrics,
with the possible effect that the average duration of the
background DexOpt job is not accurate because the two extreme
cases are mixed together.
Bug: 290340704
Test: atest art_standalone_artd_tests
Test: atest ArtServiceTests
Change-Id: Iebb845e395b52e51f415feb171a88bbbd23e2610
Merged-In: Iebb845e395b52e51f415feb171a88bbbd23e2610
diff --git a/stats/atoms/art/background_extension_dexopt_atoms.proto b/stats/atoms/art/background_extension_dexopt_atoms.proto
index ea66983..c782948 100644
--- a/stats/atoms/art/background_extension_dexopt_atoms.proto
+++ b/stats/atoms/art/background_extension_dexopt_atoms.proto
@@ -86,4 +86,13 @@
// sleep. Deprecated as the job scheduler holds a wake lock, hence this
// duration is always going to be the same as above.
optional int64 duration_including_sleep_ms = 4 [deprecated = true];
-}
\ No newline at end of file
+
+ // The number of packages successfully optimized in this run.
+ optional int32 optimized_package_count = 5;
+ // The number of packages depending on the boot classpath.
+ optional int32 packages_depending_on_boot_classpath_count = 6;
+ // The total number of packages scanned in this run. This is usually the
+ // total number of packages on device, but may vary due to
+ // OEM customizations.
+ optional int32 total_package_count = 7;
+}