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
Qualify the test for wallpaper animation to exclude the dummy
animation. This keeps us from treating a dummy-animating wallpaper
as an exiting wallpaper and providing the wrong animation.
Hide wallpapers when the wallpaper target window is hidden. This
fixes a timing issue where the wallpaper was exposed for one pass
through performLayout after the launcher was hidden.
Fixes bug 6454992.
Change-Id: Ib4f9205c01a37e6f48f1f93ddcf2476e40ff942f
If there were apps already installed that were added in a later system
OTA, bad things would happen.
If the previously installed application is an older version, simply
delete the installed application. If the system app is older than the
previously installed one, mark it as a disabled system app and use the
previoulsy installed application.
Additionally, the application will now have the correct granted
permissions.
Bug: 6251602
Change-Id: Iea444b6acac460fca1e08d4e2cbf68a258214ca6
Clean up related to new Vibration policy.
The vibrate behavior is now only derived from:
- presence of a vibrator on the device
- current ringer mode selected: NORMAL, VIBRATE or SILENT
If no vibrator is present the ringer mode can only be NORMAL or SILENT.
The control of ringer mode via volume keys when volume keys control the "master"
stream type (RING on phones, MUSIC on tablets) is as follows:
If a vibrator is present:
VOL- and volume equals 1: NORMAL => VIBRATE
VOL- and volume equals 0 and not continuous press: VIBRATE => SILENT
VOL+ and in SILENT mode: SILENT => VIBRATE
VOL+ and in VIBRATE mode: VIBRATE => NORMAL, volume = 1
If no vibrator is present:
VOL- and volume equals 0 and not continuous press: NORMAL => SILENT
VOL+ and in SILENT mode: SILENT => NORMAL, volume = 0
VIBRATE_ON and VIBRATE_IN_SILENT settings are not stored/retreived any more.
AudioService checks and corrects ringer mode and stream volumes if necessary when reading from
DB at boot time.
Also:
Added dump for stream volumes in AudioService.
Added device names missing in AudioSystem for USB accessory and USB device.
Issue: 6036529
Issue: 6414950
Issue: 6448163
Change-Id: I77fb821ec63e4e566320cac2701b4ac466e86aef
System applications which had an update applied to them at some point
were in a semi-broken state when removed via an OTA. The
"updated-package" setting would stay around forever and permissions
wouldn't be revoked.
Change-Id: I908e813b5de59c0f777d9b051253b28255a1c694
Deliver new intents to an existing parent from the calling uid obtained from
the applicationInfo instead of the process record, since the process record
might be dead.
Stoopid monkeys.
Bug 6328725
Change-Id: I4371a5705ccd7004f0dfe11da7c48d1563fb8dac
1. Since we are using a stateless proxy accessibility service to
perform default accessibility gesture handling it shuld not
operate against not important views.
bug:6422069
Change-Id: I74df9c2415ab3b164d9ac5873f7004c0459e2bfa
