- updates APIs naming and uses Consumer<TranslationCapability>
instead of PendingIntent
- Implements the propagating capability updates in the client side
Bug: 176208267
Test: manual.
Test: atest CtsTranslationTestCases
Change-Id: I171c908b529e2ef300e4bbd55c1565b33a25c1e5
Add FLAG to registerDisplayListener method to receive
brightness-specific changes.
getBrightnessInfo() method added to
android.view.Display to get brightness value, min, max
and highBrightnessMode status.
Bug: 168210311
Bug: 171023136
Test: atest com.android.server.display
Change-Id: I581e86e039cc7cf1bbca4cf7af03daa41dbddfe0
This change adda the apia in the TranslationService that allows to
update the TranslationCapability to the registered clients. This
change doesn't contain the register part in the TranslationManager,
the change will be done on the next change.
Bug: 176208267
Test: atest CtsTranslationTestCases
Test: manual verification
CTS-Coverage-Bug: 182990474
Change-Id: Iec7b3dc30f99985415162394d0e64d8e825ea5d9
In R we consolidated SetWindowStopped to use ViewRootImpl
surface changed callbacks. This affected the timings of when
the app would get SurfaceView SurfaceHolder callbacks. The
callbacks would be invoked in ViewRootImpl traversal before
the measure pass. If the app tried to add to the view hierarchy
in the callback, the view would not measure and layout the
new view properly.
To fix this, move the ViewRootImp SurfaceChangedCallback
after the measure pass.
Test: app in bug can add a view from SurfaceHolder.Callback#surfaceCreated
Fixes: 181529599
Change-Id: I06923113f7fc8e90242060c34f1d309d53b5a87b
When autoEnterPip from Task with multiple activities, besides passing
the mLastRecentsAnimationBounds we should also try to pass the last
PictureInPictureSurfaceTransaction to the new Task and apply both.
Changed also
- deprecate the last recents animation bounds and use the transaction only
- reset the transform once applied to the original task
Known issue: original task appears transparent in overview once.
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/hNZ0H62PqgVDEUGh1TVMiT
Bug: 184789412
Bug: 185509920
Test: manual with ApiDemos, see Video
Change-Id: I7fb77e41e1963e14ecaf53bd135d6b4cb24493c9
Also moves the #initNotificationIconArea call to be within
CollapsedStatusBarFragment, rather than requiring StatusBar to call it.
This makes our unit tests better because now we don't need to call it
manually.
Also fix a bug in #onDozingChanged that was passing disabled1 in for
disabled2.
Test: atest and manual
Bug: 183229367
Fixes: 185897059
Change-Id: I0a65f9e90e66680f0b602b89f89ec0a4900e9df8
The new configuration did not reported to the NexusLauncher activity
when the device rotated to landscape. It seems that the configuration
object of the ActivityClientRecord was unexpectedly updated somewhere,
so the configuration handling was skipped and not reporting to the
activity.
Copy the configuration from mPendingMergedConfiguration vs. directly
assigning the given configuration object reference.
Bug: 185820525
Test: atest NexusLauncherTests:TaplTestsQuickstep
Change-Id: I6768fe86e5c977c32a975562ec058c82d4f9c2fc
The surface may not be cleared by its owner when
it lose control last time. We had CL[1] to clean
up the surface if we don't plan to show.
Add new checking condition for last control, so
once we have control we only remove the surface
if last control was null.
[1]: I4910c2a06cc67b0470477b245fc1de54b75f10f9
Bug: 185557884
Test: atest InsetsSourceConsumerTest
Change-Id: I1a4f05f9b4cf6fa121554ff0abc9fdc418b95276
Recently introduced check for isBufferQueueLayer doesn't work
because the FX_SURFACE_NORMAL flag is 0x0 not 0x1 as expected.
Bug: 185941687
Test: Existing tests pass
Change-Id: I1b341bffcd8b0f0c0e7f2e3da27cb201b6e1d6ff
As a part of internal libcore API cleanup some of the functions
previously exposed are getting removed from public surface.
This CL replaces usage of art optimized reflection methods with default
ones.
Bug: 154796679
Test: m droid
Change-Id: I14cfa4af95e2d4b34cee02decaec33d928c25b73
Recently exposed ViewRoot API requires requestTransparentRegion for
many of the use cases we want to support. requestTransparentRegion is
already public API, however the documentation and definition is a little
confusing and arguably it shouldn't do anything unless we also implement
gatherTransparentRegion. gatherTransparentRegion is already made public
through SurfaceView, and so exposing it properly on View seems like
a non disruptive option.
Bug: 179647628
Test: android.view.cts.ViewRootSyncTest
Change-Id: I72fb2744bc03cdd26d64547dbebeb12751a33a2a
We introduced some APIs for initial demo but we dropped these APIs.
To avoid to break the client app, we keep the API until the client
moves to new APIs. It's ok to delete these API now.
Bug: 185448758
Test: manual
Test: atest android.translation.cts.UiTranslationManagerTest
Change-Id: I5ea71d4658246f52610e1f62412d60c6c58bb31e
