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
Visualizer capture buffer must be reset if audio framework has stopped
calling process for a given period of time to get read of residual
data from previous captures.
Issue 5571920.
Change-Id: I6e73f971bb812cdbb2979a3b5e763abab07634eb
To allow applications with non-standard Camera use cases to use the
platform sound files and routing, add a method to play any of the
standard Camera sounds (shutter, autofocus, record start/stop) using a
background thread.
Bug: 5447107
Change-Id: I2524853a626e3ce334a7aad2f7de061d5c04abd0
In fact, there's even more going on here. Icons were
appearing cut off because of the unusual width of icons on
the right-hand side of the status bar; we now take extra
steps to ensure that the IconMerger is only wide enough to
show an integral number of icons. But that causes problems
with the rest of the status bar the IconMerger makes itself
thinner than the overall layout requires, so there's now a
containing layout to absorb the additional horizontal space
properly.
Bug: 5136545
Change-Id: I8c4d1ee2bcd976c452510b33c196fbe0c3e8c660
Also fixes some minor problems in other tests and reduces the HTML test page to
the minimal valid HTML5 document.
Bug: 5140673
Change-Id: Icc3730d017b778b0e618af3fcfee028300dd0a56
Previously, the input dispatch rate was capped by default to 55.
This worked fine for systems with a refresh rate of 55 or lower. But on
devices with a higher frame rate (such as stingray at 60 fps), we do not
receive events as fast as the rendering system wants to redraw the frames, so
we would occasionally miss events between frames, resulting in a visual
stutter during drag operations where the dragged object would essentially
stay still for a frame.
This fix increases the default rate to 90, or 1.5 times the highest typical
refresh rate of our devices.
Change-Id: Id8622185b3da93f9f6505157d2e6f3f33e36bd04
