When StatsCompanion informs statsd that an anomaly alarm has fired,
statsd will need to check to see whether an anomaly has indeed occurred.
This will require determining which anomaly alarms have times in the
past (since that indicates that the anomaly did indeed occur). This
capability is now added.
Test: adb shell data/nativetest64/statsd_test/statsd_test
Change-Id: I5464c94634df70832d2723d8c4718277776d58aa
Implement ProtoOutputStream.h to write protobuf format data.
Usage of dumping proto:
ProtoOutputStream proto(fd);
proto.write(fieldId, value1); // dump a single value
// start to dump a message:
long long token = proto.start(messageFieldId);
proto.write(nestedField1, nestedValue1);
...
proto.end(token);
fieldId will be generated by protoc-cpp plugin(TBD). It is an encoded uint64_t
value, with 0 - 32 bits as its proto number, 33 - 40 bits reserved for
field type, int32, bool, string, message, etc. and 41 - 43 bits for
single, repeated or packed type. Currently packed field is not
supported.
Bug: 65641021
Test: N/A, need to wait for protoc-cpp plugin and will test in
incident_helper
Change-Id: Ic188615b950235aae0edeee4876b78d31feb5619
We want to provide a sane default for the bootaction library name so
that the developer isn't required to mess with read-only properties to
get this working.
Also small cleanup to remove duplicate and unused libs from Android.mk.
Bug: 67644323
Test: builds (master)
Test: properly loads default lib (nyc-iot-dev)
Test: logs and exits when lib doesn't exist (nyc-iot-dev)
Change-Id: I865a45f43b3594c99419e7e27c9798ee944d0db2
The UID map is updated by StatsCompanionService, which listens to broadcast
updates indicating that an app was updated/installed or removed. Also,
the entire map is updated when statsd first connects to the companion
service. Also, there is a way for metrics producers to subscribe to
updates, so that they can know when an app was upgraded.
Test: Created new unit-test for mapping and manually tested for install
and remove. Did not manually test the app upgrade.
Change-Id: I6676ae5c93b75c72d9badabb36aa9c40006db07d
+ also synced proto from google3 to fix the LogEntryMatcher proto
+ MetricsManager represents StatsdConfig, it's responsible for initializing and managing all
LogEntryMatcher, Condition, and Metrics. Start review from here.
+ Added more complete StatsdConfig initialization, including building the map for:
LogEntryMatcher -> Metrics
LogEntryMatcher -> Condition
Condition -> Metrics.
All the maps use index(int). The extra amount of memory for storing mappings help us
quickly process log events.
The StatsdConfig initialization process detects malformed config
- Circle dependency
- Missing definition
etc.
And once we detect ANY error, statsd will reject the config. And the resources related to this
config will be released.
Test: Added unit tests
Change-Id: I2c4aefdbf3e2aa1701eacbb2fb5e653819ec1fbb
CountMetricProducer now has a CountAnomalyTracker which stores past
bucket information. Anomalies can be determined by seeing if the
information from the past and current buckets exeeds a threshold.
Test: manual
Change-Id: I35103c01dd32dcc31cb155f5685161cbaf969d03
Currently the boot parameters are tied pretty tightly to the bootaction
functionality, but volume and brightness need to be set on the
bootanimation regardless of whether there's a bootaction or not.
Extract boot parameters into a separate class to make it easier to apply
volume/brightness in a future CL.
Bug: 65462981
Test: Manual test, can succesfully read params on boot.
Change-Id: I32daad64cb8aab39fcd0ca17503218e0605ccd27
(cherry picked from commit f78561e7bbe580d0f0dbca7a615c575973ef6ce4)
When statsd is told that it is time to poll data, it asks
StatsCompanionService to pull kernel wakelock data, receives the result
(as a string), and outputs it to screen.
Still to do:
1. don't use a string; use a parcel instead
2. don't output it to screen; do something useful instead
3. do more than just kernel wakelocks
4. pull data on demand, in addition to just on periodic pulling
Test: added setPollingAlarms to statsd.main and confirmed that kernel
wakelock information was written to screen
Change-Id: I35f5164420699dea1a00c9e530b938904f1d3055
This cl is to let statsd understand statsd_config, and compute metrics
defined in the config.
+ StatsLogProcessor is given a StatsdConfig (hard coded right now).
We construct a MetricProducer for each of the metric, and the metrics
share Condition and LogEntryMatchers
+ Added the CountMetricProducer type for CountMetric.
We can now count times of SCREEN_ON events given a config.
TODO: 1) conditions are not implemented.
2) slicings are not implemented in CountMetric
3) move the interaction to dropbox to a separate thread
4) decide how the in memory metrics would be used by anomaly detection
Test: manual test.
$ adb shell /system/bin/statsd
$ cat config_file.dat | adb shell cmd stats config
Change-Id: I38f4059c0dc5a827c338131d4a6fa7d4cbe865db
Awhile back we explicitly blocked any new ASEC installs, with the
expectation that we'd eventually remove the logic entirely. We've
had them disabled for about a week now without incident, so let's
rip out the remaining code.
Test: bit FrameworksCoreTests:android.content.pm.PackageHelperTests
Test: bit FrameworksCoreTests:android.content.pm.PackageManagerTests
Bug: 32913676
Change-Id: I1ecc35487420731f5c4bdf03bca5751548ce51b3
We now provide some parameters that can be set on reboot and passed into
the bootaction library. This becomes part of the public libandroidthings
native API, so we need to use the public type.
Bug: 65462981
Test: `mma` builds successfully
Test: Test bootaction.so can receive boot params (tested on nyc-iot-dev)
Change-Id: Ibf6548730e0bac023f6a0a3aef925b0938418a10
Extract protobuf class out and creates EncodedBuffer class
which holds protobuf data.
Next step is to create a ProtoOutputStream and let incident helper
adapt the change as well.
please see frameworks/base/core/java/android/util/proto
Bug: 65641021
Test: unit tested
Change-Id: I0dd343b2e62d60f091c8f857fae3452ec8da6b96
Includes matching for both simple and compound matchers.
Change-Id: Id913d2625d205ad9a529019e98ae805f730f4d48
Test: Added new unit-tests and checked on marlin device.
We delay shutting down the animation if there is a boot action present
until we are told by the system to shutdown.
This addresses an issue we are seeing where we switched to a very short
bootanimation (bootanimation_mini.zip) to save CPU but this kills the
boot action prematurely.
Bug: 37992717
Test: Ran locally against imx7d.
Change-Id: I23556b21128b80d08cc55eaa761439a570b8eebe
Bug: http://b/65462981
Test: Parameters in next_boot.json are passed to
boot action; next_boot.json is moved to
last_boot.json to allow reading by
DeviceManagementService.
Change-Id: Ie290711ea48a3a221cfad2e9266215b76631ecbd
Added .clang-format, because there isn't an official .clang-format file for Android framework code.
before we upload changes, do:
clang-format -style=file -i [file list]
to format the files that you touched.
Test: formatting only. NO code changes.
Change-Id: I90e87f1ee6618da8ea9bc2221c609c415a4046a8
Statsd code now lives in android::os::statsd namespace. Existing files
are largely modified to follow this convention.
Exception: parse_util, since it seems a bit different.
Test: code compiles and existing statsd_tests still pass
Change-Id: Idf92a071b9ed172d01eb3087a4fa3609d67a038c
If statsd or statsdcompanion crashes, or if one loads
before the other, the other will be able to accomodate.
When statsd loads, it will attempt to tell statscompanion that it's
alive, and then get on to its business, while assuming that
statscompanion is not alive. Only when statscompanion tells statsd
that it is alive, statsd will then start to use it.
When statscompanion loads, it will attempt to tell statsd that it's
alive and then do nothing (since it has nothing to do). When statsd
tells statscompanion that statsd is alive, statscompanion will respond,
telling statsd that it is alive and, if that binder call returns, will
get to work.
This way, if statsd loads first, it can work unobstructed until
statscompanion informs statsd that it is alive, at which point they
shake hands and work. Conversely, if statscompanion loads first, it will
do nothing until statsd contacts it, at which point they will shake
hands and work.
Test: manual
Change-Id: I969ad47fb8060e27814d05ad37433a02711cfa6a
StatsCompanionService can now inform statsd that an alarm (for anomaly
alerting and for polling) has fired, so that statsd can act accordingly.
Test: manual created an alarm from statsd.main and checked logcat that
statsd received the broadcast that it fired
Change-Id: I1d33dfbee0d3e213c91dd6973d2622ecacc890c8
