When encountering non-monotonic stats rows, recover remaining data by
clamping to 0. In particular, this avoids edge-case where persisting
threshold checks would never trigger. Also recover when tethering
snapshots are missing.
Bug: 5600785, 5433871, 5600678
Change-Id: I1871954ce3955cc4ac8846f9841bae0066176ffe
LayoutTransition was making an incorrect assumption that there could
only be one transition animation on a child of a transitioning container.
But if multiple children are added/removed to/from that container, there would
be multiple calls to set up changing animations for each existing child
of that container. This meant that the child would have multiple, new
OnLayoutChangeListeners added to it as part of the setup process.
Meanwhile, we would cache only the latest listener in a hashmap that used
the child as a key for the listener. Then when we cleaned up the hashmap later,
we would remove only the latest listener from the child, leaving the rest there
for eternity.
The fix is to skip the setup entirely for children that already have listeners
set on them; they must, if that's the case, already have been set up and are
already listening for layout changes. Setting up the animation is redundant,
and adding another listener is a leak.
issue #5588509: memory leak in systemui
Change-Id: Ie2192593d84702be7243c18760dfdb3a027b761c
Bug: 5601629
References tend to always be equal to the things they are referencing,
use copies instead.
Change-Id: I0827878e91ef1fa6e0abe2d6499d55f4a211d890
A build with the wimax network type defined but wimax disabled
causes an NPE in ConnectivityService's constructor.
bug:5237167
Change-Id: I929eac217e1afa0e61346fdbc3e96a7d3ad09a54
LayoutTransition was making an incorrect assumption that there could
only be one transition animation on a child of a transitioning container.
But if multiple children are added/removed to/from that container, there would
be multiple calls to set up changing animations for each existing child
of that container. This meant that the child would have multiple, new
OnLayoutChangeListeners added to it as part of the setup process.
Meanwhile, we would cache only the latest listener in a hashmap that used
the child as a key for the listener. Then when we cleaned up the hashmap later,
we would remove only the latest listener from the child, leaving the rest there
for eternity.
The fix is to skip the setup entirely for children that already have listeners
set on them; they must, if that's the case, already have been set up and are
already listening for layout changes. Setting up the animation is redundant,
and adding another listener is a leak.
issue #5588509: memory leak in systemui
Change-Id: I2c9f312cc2bcf4f2d08ac6b5d8f8e495aa4f3597
-> On the Xoom, this change gets us back up to 60 fps. The
change is really more of a workaround for the fact that we don't
have vsync, and we ought to be able to change it back once we do.
Change-Id: I80888f18887bf5f2fed72c19641ed430ef6dbfcf
This does not happen on high end gfx devices. This happens
only if only one EGL context is initialized in the current
process.
Change-Id: Ibd1737efdf84eef8a84108b05795440d1ae9964e
disable dithering which shouldn't have been enabled
in the first place because the frames are typically scaled.
we still use a 16-bits texture format to preserve memory.
Bug: 5600948
Change-Id: Ib4d6e133df4375d0d735cd4325b6e589bbc5dafe
1. The dismiss method in a PopupWindow is first removing the
popup View from the WindowManager and then if the content
View differs from the popup View the former is removed from
the latter. Then dismiss() clears the dismissed flag so a
subsequent call to dismiss() is a NOP. However, removing
a View both from the WindowManager and from its parent
ViewGroup triggers stuff wich may lead to a subsequent call
to dismiss(). This leads to a stack overflow exception.
bug:5598944
Change-Id: I2aeeda591be3e9aa98fec1ee17ea8f0e746e6992
This reverts commit 562dfff65ac79590c0b7c50019cd3d107e8b4e0e. These API's are still used
by GMM in the version that ships with MR1, so we need them to keep Beam working for
GMM. Note that these APIs are hidden.
From version 5.13 onwards GMM will use the new API's.
Change-Id: I316a9c9b7d0052a14f6c1df70f2ed463bca61800
Fix a bug that caused animated drawables to not schedule properly when
a view has not yet been attached. Also make ImageViews update their
drawable visibility state properly, which will handle scheduling
concerns as ImageViews are attached and detached from their windows.
This should also fix the bug where animated notification icons in the
status bar do not animate until the posting app posts an update to the
notification.
Change-Id: I24c403182831258d1f251736e920c9efe1d38299
...should not be restarted when rotating screen on xoom
This was a side-effect of a previous fix to compute the screen layout
config class based on the actual space available to the application, not
the raw display size. On a device like Xoom, the system bar causes us
to switch between LONG and NOTLONG depending on whether the system bar
is on the short or long side of the screen.
To fix this, we now compute the screen layout class the same way
"smallest width" is computed: looking at all of the possible rotations
and using the smallest of them all. In addition to preventing the device
from toggling between long and notlong on a Xoom-like screen, this will
also avoid other possible undersireable behavior like changing screen
layout size when rotating.
This does mean that Xoom is no longer considered a long screen even when
in landscape, because it is not a long screen in portrait.
Change-Id: I85f90a16294ef5a7de94d5b9231abbc6f914fe90
This reverts commit 03da2f00aac04e6565a02cf5a9bf6bb1ec926930.
Committer: Tom Taylor <tomtaylor@google.com>
On branch revertsetting
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: api/current.txt
modified: core/java/android/provider/Settings.java
modified: core/java/android/provider/Telephony.java
modified: packages/SettingsProvider/res/values/defaults.xml
modified: packages/SettingsProvider/src/com/android/providers/settings/DatabaseHelper.java
We've decided not to disable messaging notifications with a secure setting.
Instead, all the work will be done within the messaging app itself.
Change-Id: Icde6894e76da1007b6026c8ec7dc56e488453c06
