Keep track of whether a foreground service has been shown in a
notification channel and, the first time one is, make sure the channel
is sufficiently important regardless of what the user or app last
set for it.
Bug: 77931346
Test: runtest systemui-notification
Change-Id: Idecad2dceb8cc918feec91ca1ee26edf3d3ab7de
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
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
The transition delay will be the latency until all the leashes
were created etc. Thus, the actual latency is going to be in
WINDOWS_DRAWN_DELAY.
Also fix an issue where we inadvertently started a transition,
and then the transition logger was hanging.
Bug: 72967764
Test: Swipe up from home button, observe eventlog
Change-Id: I2b1fb7d9d694a629a33653c1fa3d5ed47f53de6b
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
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
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
It's fine to rearrange and update right now since the protos aren't
being used yet. In the future, we should just update the mapping
function.
Bug: 65750826
Test: $ cts-tradefed run cts-dev --module CtsIncidentHostTestCases --test com.android.server.cts.PowerIncidentTest
Change-Id: Ia5e44ec74009a68e06d74e0cfb4a4c83b1bcb58a
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
The previous code saved a String in the proto like
"NotificationManager.Policy[priorityCategories=PRIORITY_CATEGORY_REMINDERS,PRIORITY_CATEGORY_EVENTS,PRIORITY_CATEGORY_MESSAGES,PRIORITY_CATEGORY_CALLS,PRIORITY_CATEGORY_REPEAT_CALLERS,priorityCallSenders=PRIORITY_SENDERS_STARRED,priorityMessageSenders=PRIORITY_SENDERS_STARRED,suppressedVisualEffects=SUPPRESSED_EFFECT_SCREEN_OFF]".
This unfortunately would mean that the String would have to be parsed on
the server-side, which kinda defeats the purpose of migrating to protos,
so I made a proto for this :)
BUG: 65750824
Test: flash device and check incident.proto output, comparing it to the previous output
Change-Id: I87607dc7b72ce3519132da23167b4bdce3b7ef4c
Also added WindowContainerProto and ConfigurationContainerProto
Will be used by cts tests in upcoming CLs that replace StackId APIs.
Test: adb shell dumpsys window --proto
Bug: 64146578
Change-Id: Id6ca2a93e3d15ac696ab54cb241870e973985967
