There are two parts to VD's native allocation:
1) VD's internal data structure (i.e. groups, paths, etc that make
up of the VD tree). This structure can change, when a VD is used
to load a different drawable resource.
2) Two bitmap caches, not both of which will necessarily be allocated
The size of the bitmap cache depends on canvas matrix and drawable
bounds, and therefore can often change.
We need to count the native allocation from the above against Java heap.
Bug: 26269056
Change-Id: If833aedcf7f3efe00ea73a41ddccb1b48066ffd8
- 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
Bug: 28242626
Bug: 27972184
Bug: 27973681
This is resolving issues in ScriptGroup (V1) again.
In ScriptGroup.destroy(), we also need to consider the old API where
mClosures is not initialized.
Also cleaned up the finalizer for ScriptGroup and Allocation:
Since BaseObj.finalize() calls BaseObj.helpDestroy(), instead of
BaseObj.destroy(), there is no possibility that the finalizers of
child objects may race their parents finalizers. Note that
helpDestroy() does not try to recurse on child objects.
Change-Id: I9dbb2b60f8478f656f8a418c2b5fc8d6848aeef0
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
If the expanded child was smaller then the collapsed one
the UI could get very weird. We're now measuring the expanded
version at least as big as the collapsed one.
Change-Id: Ibb99c4926121b2affcc181071b5e439f23c8e4f2
Fixes: 28318145
Fixes: 28015447
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
