Bug: 72667033
Test: tested loading /product/media/bootanimation.zip after moving it
from from /system/media to /product/media on sailfish
Change-Id: I10612dd77da7c2c67b02b00b7f0eb2b28e49cc98
Records start and duration of shutdown, along with reason and if it was
a reboot.
Test: manually verified statsd received atom. CTS test for this will be
difficult, and I will investigate further later.
Change-Id: I0f6b595e0e251fd0a8b38127182d055885460a55
Defines following atoms:
-- AppStartMemoryStateChanged
-- ProcessMemoryState
-- LmkStateChanged
-- LmkProcessKilled
These changes are based on the discussion with WestWorld team.
See: go/android-p-memory-metrics
Bug: 72177881
Test: Manual
Change-Id: I884f23f3d7627440af5faa25f9479ba0d8763bec
1/ Avoid unnecessary field/dimension proto construction.
2/ use unordered_map for slicing.
3/ Use dimension fields to compare dimension keys.
Test: all statsd tests passed.
Change-Id: I2f74f78589b7f6ecd0803a2ead822b8d0399f334
+ refactor pullers in StatsCompanionService to be more modular
+ rename CpuSuspendTime and CpuIdleTime to SystemElapsedRealtime
and SystemUptime
Test: will add cts test
Change-Id: I463103fb271511cef4e0f877c20fd167fe8b173b
Freeze period is defined as a pair of calendar dates (recurring annually)
during which the system should block any incoming system updates, including
security patches. They are set on top of existing system udpate policy
types (automatic, windowed, postpone) such that outside the freeze
periods existing policy semantics will still apply. They are created to
allow admin to keep their device fleet from any destabilizing changes during
critical period of the year, for example during Christmas sales period.
Device Owner can set several freeze periods, although to prevent the device
from not receiving OTAs indefinitely, each single freeze period is
restricted to be at most 90 days, and adjacent freeze periods need to be at
least 60 days apart. To properly enforce these restrictions, any freeze
periods the device previously experienced is tracked by DevicePolicyManager
and are validated against any new policy. This is to deal with corner cases
such as the admin repeatedly set a short but overlapping freeze period on a
rolling basis, hence bypassing the 90-day freeze period restriction.
Test: runtest -c com.android.server.devicepolicy.SystemUpdatePolicyTest frameworks-services
Bug: 64813061
Change-Id: I2864192797dc194edd9c183b881da6cfe3fdba5e
+ Bugreport will use the non-verbose mode
+ Reuse the log_msg object in LogReader
+ Add logd errors to StatsdStats
Bug: 72383073
Test: manual + statsd_test
Change-Id: Id5a8b103074d034f5ece3c9831c740d44a5df9cd
Created an enums.proto that contains the device idle modes,
which is referenced by batterystats.
Note that, currently, batterystats is the origin of these
constants in the java code, and I have kept that as is.
Thus, batterystats references the enum.
Nevertheless, because the actual control of device idle
mode is DeviceIdleController.java, where these constants
will likely one day be moved, I have put the constants
in server/enums.proto (since DeviceIdleController is
in server, not os like BatteryStats).
Bug: 69478930
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases -t android.cts.statsd.HostAtomTests#testDeviceIdleModeStateChangedAtom
Change-Id: I6e66801ae8256aab423067f9a4b852a194564a8d
App transitions, from ActivityManagerInternal, are now referenced via a
proto enum. This is also referenced by statsd's atoms.proto.
Bug: 69478930
Test: still compiles
Change-Id: Ifb5cb0120d4cd4e2464ce3b5a7455842cb55259c
For frameworks constants that don't have intrinsic meaning (i.e. their actual
value and order don't matter), so that it is unlikely that their values
will be changed:
This cl introduces proto enums representing some constants found in
the Android codebase, and connects the two.
By using the Proto enum as the source-of-truth, it means that Java and
proto can be kept in sync. Otherwise, when the Java frameworks code
changes, it silently breaks the protos from working properly, since the enums
are wrong. By having the Java code reference the proto enums, it ensures
that everything is in sync. The values of the constants are unchanged.
But future changes to these constants will need to be done in the proto
file, which the Java file merely references.
The protos are necessary for incidentd and statsd and, in the future,
possibly dumpsys. In this way, the logging mechanism is much less likely
to get broken when new constants are added, and we can be ensured that
the logging accurately reflects the underlying codebase.
Bug: 69478930
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases
Test: cts-tradefed run cts-dev -m CtsIncidentHostTestCases
Change-Id: If79032c34b2799db1e3e70cb47b1312fd72092b9
Allows a uid that uploads a statsd config to additionally
register a BroadcastSubscriber with statsd. If statsd
detects an anomaly (according to the config's Alert),
statsd can inform a BroadcastSubscriber provided in the config.
The config uses a subscriberId (just an int) to identify the
BroadcastSubscriber. It then uses StatsManager.setBroadcastSubscriber
to associate that subscriberId with a given PendingIntent.
Then, when the anomaly is detected, statsd sends a broadcast
using that PendingIntent, alerting whoever was specified by
the config/setBroadcastSubscriber.
Bug: 70356901
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases -t android.cts.statsd.alert.BroadcastSubscriberTests
Change-Id: I4d9ea9a6c8a85e61fadfd99c1513c55abbadd5e9
Rename the activitymanager.proto to enums.proto, in accordance with the
new convention on naming these protos.
Also, changes processStateAmToProto from simplying multiplying by 100 to
a switch statement, to be more future-proof.
Also, changes the values of the proto's process state, to reflect that
the values will not be kept in sync with ActivityManager.
Note that this cl was originally started in ag/3008434, and partially fulfilled in ag/3114337.
Bug: 69478930
Test: run cts-dev -m CtsStatsdHostTestCases -t android.cts.statsd.ProcStateAtomTests
Change-Id: I2b3bf2552b879c74d8985338df5a57c01850cb91
Turns out that statsd leaves some file descriptors opened
without the O_CLOEXEC flag. This CL mass-closes file descriptors
up to a realistic number of FDs. This is to avoid SELinux complaining
about perfetto accessing these files from the statsd domain.
With this change perfetto works with statsd without disabling SELinux.
Relevant SELinux CL:
https://android-review.googlesource.com/c/platform/system/sepolicy/+/598774
Change-Id: I745d621937fbc9b20a4c733948cd0dd24dd6e8b2
