The logic of where refractory period enforcement was moved out of the
anomaly tracker and into the metric's predictAnomalyTimestamp. It was
done for ORING, but not for MAX. This fixes MAX.
Bug: 74446029
Test: adb sync data && adb shell data/nativetest64/statsd_test/statsd_test
Change-Id: I51e43c7c132f424af8fe20a37f2ad10cc55b5989
changes are:
1) for pushed atoms, use attribution node in place of uid when
appropriate
2) name changes to be more consistent
Bug: 73823969
Test: manual test
Change-Id: Iacf7186dbd7a2282f7fe481f43dbbf92e1165b47
Mostly to add test to assure the corner cases are covered.
One minor logic change is if two true conditions happen, in the case
when following happen:
(bucket boundary1) -> (condition false) -> (condition true) -> (pull
triggered for the boundary1)
Previously we take the latest. Now we skip the late boundary pull.
Bug: 76384731
Test: unit test
Change-Id: I345c2210a58bf03eb91d65742573073d2668358b
+ change StatsPullerManager internal time units to be consistent
+ use series of alarms for pullers, instead of use setRepeating
Bug: 76223345
Bug: 75970648
Test: cts test
Change-Id: I9e6ac0ce06541f5ceabd2a8fa444e13d40e36983
Ble scan logging in statsd has a few problems:
1. We want finer-grained detailed than just 'unoptimized'. What defines
unoptimized should be done at the config level, not be hard-coded.
2. The current mechanism is actually incorrect. When reset is called,
each ble scan is only told *once* that it stopped, but if the nesting
level is higher than that, statsd will think it is still nonetheless
running.
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases -t android.cts.statsd.atom.UidAtomTests#testBleUnoptimizedScan
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases -t android.cts.statsd.atom.UidAtomTests#testBleScan
Fixes: 71607284
Fixes: 69478888
Change-Id: Ied44f79aa569daab2acc85e90627a9736d0689a3
+ Config count is 10 per uid
+ Update the limit for metrics, matchers, conditions, etc.
Test: statsd_test
Bug: 73122377
Change-Id: I3e1adfe318d1354a7c9d1bf484855661aa3a1fc8
Add UsbDeviceAdded to log VID, PID, and interface
types of USB devices added to the system.
Add a fall duration to physical drop detected.
Bug: 74260509
Bug: 74261750
Test: Built and booted Walleye
Change-Id: I2b38697ba52869bc448fac2cc4b8bdb3fa75fa64
When triggering a Perfetto trace, pass the alert and config id to the
perfetto command line tool to record them into the trace. This lets us
correlate Perfetto traces with statsd alerts.
Bug: 73627502
Test: Manual
Change-Id: I301ee5e5e8bdb83d08e8d55b994c15a6541a92f2
Merged-In: I301ee5e5e8bdb83d08e8d55b994c15a6541a92f2
(cherry picked from commit 209a5915dcfe030912dda57df4fb6390385c7de3)
Several statsd atoms are not logged correctly from batterystats, due to
possible nesting issues (batterystats only reports a single stop at the
end, whereas statsd expects each stop, resulting in statsd thinking that
the event is still continuing). This cl fixes those.
Bug: 69478888
Test: current ones still pass
Change-Id: I3ae8d7cc3d2eec7d4ab2721c83d208384adbf690
Changes the temperature atom to use an int instead of a float because
metrics and anomaly detection assume the data will be an int or a long.
Bug: b/74011562
Test: statsd temperature CTS test
Change-Id: I6e5845a40c28aefd30c2be9709c6f9de1783cf02
This atom logs time spent on cpu per frequency per uid.
On marlin, there are 27 frequency steps per uid (should be 50+ if
flatten to both cores)
On walleye, there are 52 frequency steps per uid.
So it easily goes to 6k data.
Soft limit set to 6k now.
Hard limit set to 10k to accommodate future processors
Memory impact: on marlin, start memory no config is 2,346K
after using this atom in one guage metric, it is 3,067K
Bug: 72505991
Test: cts test
Change-Id: I067a32e54e4a457fdf9a25911aa16030e893ef4d
Previously tried an optimization that results in corrupted proto
output. This changes to a safer approach of storing the snapshot data
in memory and only converting to proto output when the
ProtoOutputStream is provided.
Also fixes a security issue when trying to invoke triggerUidSnapshot
since we forgot to use SCS' permissions.
Test: Added a unit-test to verify output of StatsLogProcessor.
Bug: 76231867
Change-Id: Id410ce3505fda9d71caa71942ef3068b55872c66
We can increase the buffer of metrics we store in statsd memory, but
we still request the clients to call getData when the metrics memory
exceeds 128 KB (previously was 90% of 128 KB).
Bug: 76171061
Test: Test that unit-tests still pass.
Change-Id: I901545b364ed313af8c033ce9b40d3cfadb93213
