mResizedWhileNotDragResizing is set is task bounds is resized, however
individual window's size may not change (eg. a floating dialog). The
relayout window may not come and the mResizedWhileNotDragResizing
flag won't get cleared.
bug: 28111853
Change-Id: If8bb79cc07d9c67d6e5685b0adc24a9ce2623ec6
The PackageInstaller app manages side-loading apps as well
as permission management. It should be updatable, hence
should rely on system APIs to talk to the platform. This
is the first step of defining an API boundary.
Change-Id: I9814eafd0b22ae03b4b847a7007cdbf14c9e5466
When closing the IME in docked adjusted mode, we still need to pass
in the IME window so we can still execute the logic to delay starting
the animation, so we don't see a black hole before the animation is
started.
Bug: 28175599
Change-Id: I606d30bd63b5e909fdebd78b0aa4968bd9f26c24
- Don't set a dim layer in the docked controller if we are not dimming.
- Check to make sure the docked divider window isn't null before trying
to use its layer for dimming.
Bug: 28339915
Change-Id: I33d49d26ffcaec63d135f82a6208e127ba0f0570
- New service TVRemoteService triggered by SystemServer
- Provider service proxy and watcher for maintaining connections to unbundled
services which have the BIND_TV_REMOTE_SERVICE permission.
- Shared library to facilitate connections between unbundled service and
TVRemoteService.
- Unbundled service needs TV_VIRTUAL_REMOTE_CONTROLLER
permission to be fully functional.
b/23792608
Change-Id: Ief5c6995883d1f7268a73bdd0c920c4c3f42cddb
If the dock divider is visible, window manager raises the IME from the
app's layer on top of the divider. However if the IME was targeting the
status bar, it would also remove it from the status bar's layer and
move it atop the divider (but below the status bar).
To fix this, we now only perform the adjustment to the IME's layer if
that moves the IME up, but never down.
Change-Id: I1308f51b98fffee64a5075c49697f5bc177ea32e
Fixes: 28024606
If either visible or nowVisible is true we need to wait for next
activity to become visible before we destroy the previous activity.
In some code path (eg. clear task top), when starting a new activity,
old activity is first paused and visible set to false with a dummy
transition set. Then finish activity is requested. At this point visible
is already false, but nowVisible is true. We still need to wait for
next app become visible to avoid a black frame shown in between.
bug: 27796252
Change-Id: Ief3d5fc8f11c51a729c424f996ab2597c815e4dd
Some of the information reported for a display is dependent on resources to do
the right calculations. For example, {@link DisplayInfo#smallestNominalAppWidth}
and company are dependent on the height and width of the status and nav bar
which change depending on the current configuration.
Bug: 28182307
Change-Id: I2ba5de4bcfb3fa3ad334e69eb192bd15f8f7ebb2
We're seeing reports of the display being too dim at initial wake up.
Saving the buffer for this initial period lets determine whether this
is a calculation error or something wrong with the sensor readings.
Bug: 27951906
Change-Id: I96b5dd0772de056c3c5e54d59c13d1a3d902d343
When task was moved to docked stack using adb command,
recents didn't show and docked stack was minimized when
home task obtained focus.
This CL shows recents if needed when task is moved to
docked stack.
Bug: 28215216
Change-Id: If1cfb9d24bd77cc9c3c8fad3479f115d7aca1301
* introduced a new intent DISMISS_KEYBOARD_SHORTCUTS and
and new public API in Activity (which sends a broadcast
to KeyboardShortcutsReceiver) which applications can
use to dismiss the keyboard shortcuts.
* plumbing and implementation for a new call to dismiss
keyboard shortcuts from PhoneWindowManager and used it:
** when starting activities invoked via Search+key
** when starting activities invoked via META
** when starting activities via application launch keys
* removed unused variable in
Activity#onProvideKeyboardShortcuts
Note that for apps started via touch (aka non-shortcut)
like tapping the Settings gear icon from the notification
bar the menu is not automatically dismissed.
Bug: 28012198
Change-Id: I83a8d4f342bb8a08115a648648834d0d2bac19fd
This is so we can record more specific times in PackageUsage.
If file with only one timestamp per package is found, the value is
copied to all usage slots.
Bug: 27902702
Change-Id: I8affe43c735e54620a9204433aad367cfddfded7
When reloading wifi firmware, unsolicited responses from netd were
processed after softap had started and caused wifi tethering to be torn
down.
The NetworkManagementServer.wifiFirmwareReload call has been changed to
not only block for the command to finish, but also until all unsolicited
messages (interface updates) have been handled. We should now be able
to handle interface updates in tethering without suffering from the
softap bringup/interface down notification race condition.
BUG: 27857665
Change-Id: Ie57cb8f760781b3227df575b577b33667070d63e
This patches changes how captive portal tests and network lifecycle
events are logged as connectivity events:
- it splits NetworkMonitorEvent into two event classes:
- ValidationProbeEvent for logging individual probe events.
- NetworkEvent for logging network connection, validation,
lingering, and disconnection.
- it removes the redundant CaptivePortalCheckResultEvent class.
The information logged in CaptivePortalCheckResultEvent was already
logged by NetworkMonitorEvent, but missing the evaluation durations.
It is now logged by ValidationProbeEvent.
- it removes the CaptivePortalStateChangeEvent class, which is now
redundant with NetworkEvent, but missing evaluation durations.
In addition, it adds event logging when ConnectivityService puts a
network into lingering or removes a network from lingering.
Bug: 28204408
Change-Id: I8f9752e4d36175ecfcbd1545a01a41bad6e06ea4
Add a method that allows callers to wait until all unsolicited
responses received from the native daemon during a command are
processed.
When commands are issued to a native daemon (such as netd) through the
NativeDaemonConnector we block until the command response is received.
Any responses or events that are a side-effect (considered
"unsolicited") of the command are placed in a Message and handled as
callbacks. The order of their processing is not guaranteed and, as we
have seen from bugreports, can be handled several seconds
later - causing the SoftAP that was just set up to be torn down
because a late interface down/removed is indistinguishable from a
new interface down/removed.
This CL adds a method that first checks to make sure callback thread
is not the same thread as used for the blocking call. The new
waitForCallbacks method uses a CountDownLatch to force the calling
thread to wait until all unsolicited responses received from the
native daemon during the execution of the command are handled.
The wifiFirmwareReload method is also updated to use the new
waitForCallbacks method.
BUG: 27857665
Change-Id: I3e22978f720b1cbf57fbb64ad4fea73f8c2d408a
Stack bounds were wrong after moving all tasks from docked stack to
fullscreen stack, if fullscreen stack was created while moving.
This lead to very wrong bounds when rotating the screen the next
time.
Bug: 27870534
Change-Id: I6d054922ffc7baa7cd1a86d0d3448050cbacd21f
Rather than hoping the process will crash for some other reason, it is
better to just get rid of it right away. The Intent was not delivered,
so there are no guarantees that the app will continue to function
correctly.
Bug: 28196243
Change-Id: I036fbc5ffd42dc7259437cc5a733976478a2dd3a
* changes:
Revert "Death to synchronous transactions (2/2)"
Fix a few weird state issues from race-conditions
Fix lifecycle bug in when calling positionTask
Animation fixes when task is not resumed
Keep stack from mReuseTask
Final fixes for growing recents transition
The divider's layer assignment could change after the initial adjust
animation has finished.
bug: 28255739
Change-Id: I5899fe22e4fec680c49c881437c7f85d8ee9ca74
- This was causing us to try and launch the Recents activity again after
docking because the running task was the newly docked task and not
Recents.
Bug: 28177001
Change-Id: I222e50f6de00a9d7881da2182eebc61564fd3266
This reverts commit dd05f0365aa0df9ba9a7631c8e02ed67f472132d.
There seems to be some logic that gets triggered inside surface flinger
regarding commit time of the transaction, and without it seems that
animations got jankier. No time to investigate...
Bug: 28305789
Change-Id: I7261cf8719d3528f8f5bee19e507b8ba88b8b729
