Prior to this fix once dimming had been turned on it stayed at the
same layer and associated with the same window until it was turned
off. Now the DimAnimator layer is updated if either the window layer
changes or the dimming window changes.
Fixes bug 6467865.
Change-Id: I3e1765b92b51be26e3718c8a87e2583041a36af9
Drawing in windows is suppressed during window animations, to make window
animations smoother. This means that drawing activities that the activity
requested are dropped on the floor. There is no call at the end of window
animations to tell the windows that they may now draw, which leaves the windows
and activities in an uncertain state, especially with respect to some of the
dirty flags that we use internally to know when we have requested (and satisfied)
invalidations on views.
The fix is to notice, on the WindowManager side, when we've finished window
animations and to schedule a traversal on the WindowManager, which will then send
out appropriate messages to the affected windows.
Issue #6461113 EventInfo is stuck in day view
Change-Id: I364c9c472531c467d44801698cfb453970173bb3
- Fading out recents first, then scaling up app
thumbnail
- Fade Recents out over 130ms
- Delay the window animation for 200ms first,
then animate for 200ms (previously we didn't delay
and then animated for 300ms)
Bug: 6390075
Change-Id: Ia8c753bf7ee03d2acef6eb2772b28d88fe10a682
1. Previous fix to hide wallpaper at the same time the wallpaper target
was hidden was too aggressive. In the case where one wallpaper target
was replacing another we would lose the wallpaper for an instant.
2. Previous fix to keep from overwriting the moving window boundaries
was incomplete. The default values for the parent window were 0,0
which caused the lock window animation to translate down and to the
right. Defaulting the parent window boundaries to the full screen
and restoring it to the full screen after each animation fixes this.
Fixes bug 6472070.
Change-Id: I0b13c642c1aaab666cdd0f4a1e7fb4b716e6b17f
1. Delegating activation gestures has several issues that we should
decide how to handle if possible before allowing an accessibility
service to take over them:
A) It is needed that every view than can be clicked or long pressed on
reacts to such as a response to calling performClick and performLongPress
which is not necessary true since the view may watch the touch
events and do its own click long click detection. As a result it may
be possible that there are view a user cannot interact with in
touch exploration mode but can if not in that mode.
B) Clicking or long pressing on a different location in a view may yield
different results, for example NumberPicker. Ideally such views have
to implement AccessibilityNodeProvide which provider handles correctly
the request for click long press on virtual nodes. Some apps however
just fire different hover accessibility events when the user is over
a specific semantic portion of the view but do not provide virtual
nodes. Hence, a user will not be able to interact with such semantic
regions but the system can achieve that by sending the click/long click
at the precise location in the view that was last touch explored.
2. Adding a flag on accessibility service info to request explore by touch
mode. There is no need to put the device in this mode if node of the currently
enabled accessibility services supports it. Now the problem is inverted and
the service has to explicitly state its capability.
3. Fixing a bug where includeImportantViews was ignored for automation
services.
Change-Id: I3b29a19f24ab5e26ee29f974bbac2197614c9e2a
Need to use PackageManager.INSTALL_{EXTERNAL,FORWARD_LOCKED} for
createInstallArgs instead of ApplicationInfo.FLAG_etc for the install
args to be created correctly. If certain flags conflict, there will be a
failure to delete the package.
Change-Id: Ibd8705943371596b2f2d6c24bd071b737ca74ef4
This problem was introduced in I74df9c24. The intention of the
change was still let UiTestAutomationBridge see the
non-important views, but there were bugs in the implementation:
1. AccessibilityManagerService was not really updating
mIncludeNotImportantViews when mIsAutomation is true
2. Wrong constant is used to set the flag
Change-Id: Ia0a2e9ed9720bd0ea3a563e0b492e870a6ec1586
In rewriteSingle(), catch Throwable to rollback to backup file,
instead of just IOException. Also add dumpAll() to pack up contents
for later debugging, and use it when encountering bad stats.
Bug: 6467868
Change-Id: Ic8e287cf5a235706811a304a88d71d11d3a79cd4
- Remove the notion of channel from an application perspective
- Remove the use of DnsSd as part of API and add a protocol type to allow
future extensions
- Use the listener object as a handler for stop and unregister operations. Also,
we now allow multiple active discovery operations.
- Remove init/deinit operations in favour of setting up construction
Bug:6434844
Change-Id: Id15521d571aac9c4053d81184ad66dfc54f636de
If the layout goes through more than one pass after detecting a window
movement but before animation begins then the later pass overwrites
the animation offsets. The incorrect values are large leading to an
animation starting location in the bottom right corner.
Fixes bug 6450310.
Change-Id: I0f74e67b3e9a15a9246151abf6d47384509340e9
