This changelist introduces a stub implementation for
DreamOverlayService for test purposes. It also allows
DreamManager to set the DreamOverlay.
Bug: 204890435
Test: atest DreamOverlayTest
Change-Id: Ia59e70d08f76d5928e72e815c990195934292ad5
This changelist moves the binding logic to the
dream overlay service into the OverlayConnection
class within DreamService. This helps better
track the binding lifecycle.
Test: manual
Test: atest DreamOverlayTest
Bug: 205077932
Change-Id: I92959a9ecb53533d998abd711f960ef4fe0628d0
Previously, the DreamService would send the window
attributes to the DreamOverlayService. However, it is
possible that the Window isn't fully associated with
a token at this stage.
This change ensures the Window is only passed when
the token is ready, tracked by when the DecorView
is attached.
Bug: 204605351
Test: atest DreamOverlayTest
Change-Id: Ib1d25ba55edb648739aca22d861e9522102d0668
By default, all user interactions with a device control while the
device is locked will require authorization. Add a new field to the
Control class that allows the application that builds the control to
determine if the device requires authorization or not.
Fixes: 202978576
Test: atest ControlActionCoordinatorImplTest
ControlProviderServiceTest
Test: atest CtsControlsDeviceTestCases CtsControlBuilderTest CtsControlTemplateTest
Change-Id: I294662b88637e18bf620aff2eed4749ae304ebd4
This changelist introduces IDreamOverlay, an interface
for rendering an overlay on top of a Dream. IDreamOverlay
implementations can register with DreamManagerService to
be bound to by DreamService when dream commences. The
overlay will be passed the Dream Window information so
that it may render within this window space.
Bug: 201676854
Test: atest DreamOverlayTest
Change-Id: I382ba2acb4a6922f19250753f8f0afc4181a6454
This commit introduces a time threshold for passing on "equivalent"
events for location time zone providers. When TimeZoneProviderEvent
instances are created, they are assigned a time from the elapsed
realtime clock, which will enable comparison with other types of events
generated by other flows. Events that have a sufficiently different time
will be passed to the system server. The time will be in the order of a
few minutes, the intention being to filter out high frequency events
that would cause the system server to do work unnecessarily, while
keeping a coarse idea of how recently the LTZP reported the state.
This commit adds the time to the TimeZoneProviderEvent and plumbs
through the configuration for the filter threshold from the system
server to the client code. The threshold can be set with server flags,
which are mostly intended to support the test logic.
Changes made at the same time:
1) Fix an issue in TimeZoneProviderRequest.equals() with an incorrect
reference equality check.
2) Rename some long-winded constant names - LOCATION_TIME_ZONE_PROVIDER_
-> LTZP_
3) Change some server flag strings so that "ltzp_" is spelt correctly
(which I do not anticipate using, but does mean that S and >S devices
respond to different flag strings).
Bug: 197624972
Bug: 200710190
Test: atest core/tests/coretests/src/android/service/timezone/
Test: atest services/tests/servicestests/src/com/android/server/timezonedetector/location/
Test: See associated cts/ change
Change-Id: Id682d420be21b9215b92f54bad599517c322fb6a
This changes owners files based on latest org changes and changes
links to improve maintainability.
Changes:
+ It removes a specific owner from most to reduce future maintenance.
+ It adds indirection so android/app references the associated service
code, tests reference the OWNERS of the code under test.
+ services/core/java/com/android/server/timezonedetector/OWNERS is the
single list of time / time zone detector maintainers.
+ Code associated with time zone rules moved to libcore/ ownership
+ It adds one new file for an upcoming commit.
+ Added documentation around API purpose to API OWNERS files, since
there are multiple similar-looking package names with different purposes
/ clients.
Test: None
Bug: 189810551
Change-Id: I948d4b8eff59f3cd5ff63018949e49679795a5c0
Prepare for rate limiting TimeZoneProviderService. The first step is to
add duplicate event detection. Later, this will be extended to add a
time component.
i.e. the android.service.timezone.TimeZoneProviderService
will pass on suggestions that are semantically different from a previous
event, but will not if they are semantically the same.
In a later commit it will be made to pass on changes that are the same but
newer than some threshold.
Most of the changes in this commit are to track a change to the binder
API and the move of TimeZoneProviderEvent so that it can be used in code
outside of the system server.
Also:
+ TimeZoneProviderService is now stateful, so add dump() implementation.
Because dump() is called on the main thread, add locks needed for safe
threading (previously, all logic took place on a known handler thread).
Test: atest hostsidetests/time/host/src/android/time/cts/host/LocationTimeZoneManagerHostTest.java
Test: atest core/tests/coretests/src/android/service/timezone/TimeZoneProviderEventTest.java
Test: atest services/tests/servicestests/src/com/android/server/timezonedetector/location/ZoneInfoDbTimeZoneProviderEventPreProcessorTest.java
Test: treehugger
Bug: 197624972
Bug: 200710190
Change-Id: Ia3246e969fda61836c8e1eee3007a8177d119994
To enable more voice-oriented in-app user journeys, Google Assistant
needs to access more information regarding the visible activities
via the Voice Interaction Session. Thus, we provide the APIs to receive
the changed visible activities in Voice Interaction Session.
Bug: 178244510
Test: atest CtsVoiceInteractionTestCases
Test: atest CtsVoiceInteractionTestCases --instant
Change-Id: I019d09fee8105ae1eadbc76803f46fd8b1948f6b
If the system is under somewhat pressure, the one second timeout might
not be enough, let's use a longer timeout to mitigate it.
Bug: 194080642
Test: see b/199700573#comment10
Change-Id: I8b9f40b332138b771d0892917b3f737caa2311a0
The DreamService calls onWakeUp, which allows the dream application to
finish the dream itself and apply an exit animation for up to 5 seconds
(after that, the system force removes the dream window). During the time
when the dream application is performing an exit animation, the dream
activity window is opaque. This causes problems when the dream
application applies a long exit animation - turnScreenOn+noHistory
activities are put under the dream (because dream has highest z-order)
and get destroyed before they get a chance to be drawn (because they
never become visible).
This CL makes the dream activity translucent before onWakeUp is called.
This allows turnScreenOn+noHistory activities to be resumed underneath
the dream, while the dream is transitioning out.
Bug: 162880999
Bug: 198359939
Test: manual
Change-Id: I536c871dab934273b79466426d861778661156dc
The DreamService calls onWakeUp, which allows the dream application to
finish the dream itself and apply an exit animation for up to 5 seconds
(after that, the system force removes the dream window). During the time
when the dream application is performing an exit animation, the dream
activity window is opaque. This causes problems when the dream
application applies a long exit animation - turnScreenOn+noHistory
activities are put under the dream (because dream has highest z-order)
and get destroyed before they get a chance to be drawn (because they
never become visible).
This CL makes the dream activity translucent before onWakeUp is called.
This allows turnScreenOn+noHistory activities to be resumed underneath
the dream, while the dream is transitioning out.
Bug: 162880999
Bug: 198359939
Test: manual
Change-Id: I5045ba8765dd1918cf85ec0fa433617843e727bd
