Note: It is currently only safe to renumber the fields because we have
not started using them yet.
* animationadapter: added in http://ag/3709688, but was not following
the indentation policy or the unit naming policy. The durations that
have documentation in
frameworks/base/services/core/java/com/android/server/wm/ state that
they're in milliseconds. These durations didn't have documentation, but
I'm assuming they're in the same units.
* batterystats: was not following the indentation policy
* jobscheduler: AppIdleController was removed in http://ag/3699210 and
the proto was only partially updated
* powermanagerservice: BatterySaverStateMachineProto added in
http://ag/3763026 but was not privacy tagged and the indentation was off
* surfaceanimator: was not following the indentation policy
* remote_animation_target: was not following the indentation policy
* others: weren't following the indentation policy
Bug: 74975371
Test: flash device and run 'test CtsIncidentHostTestCases'
Change-Id: Id012f4690b1d58816fef096523e1a0ea2bccadb0
I left out the protos that aren't officially used in incident.proto in any way.
The notification captions are set in NotificationManagerService and
ConditionProviders. They're not set by the app at all.
Bug: 72393215
Test: flash device and check incident.proto output
Change-Id: I4b36e066740fa1e6755eb946e2bcfa4959d9f9db
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
Moving to the proto/.../server directory since PowerManagerService is in
com.android.server.
Extracting enums from other components into their own files.
Bug: 65750826
Bug: 65750806
Test: flash device and check incident.proto output
Change-Id: Ib91b7c08142fa66adf18b6e85106d4cbb5adf660
The rationale for this change:
1. When defining enum values for platform, we want to use the current
integers, in some cases zero is not defined, but proto3 enforces a zero
default value.
2. Android Metrics Team uses proto2 on server-side
3. When copying .proto to server-side, the known issue of dropping
unknown fields might affect if using proto3
4. Not much benefits from using proto3
Bug: 67110257
Test: manully generate incident report and it looks normal
Change-Id: Ia63e39de549a46683e9f80fcb74f1d771782b7f4
Implement enough functionality in protobuf dumpsys to replicate
old functionaltiy in android.server.cts.WindowManagerState
Test: cts-tradefed run commandAndExit cts-dev --module CtsWindowManagerHostTestCases
cts-tradefed run commandAndExit cts-dev --module CtsServicesHostTestCases
Change-Id: Ib527ab3f44620a08cf03b77c37c2bae883d90e13
