1. Some obsolte logic was placing invalid index in the array of
scroll wheel items which was resulting in failure to look its
string representation from the cache causing a NPE.
2. While editing the current value via the IME the middle item
of the scroll wheel was partially visible i.e. the user was
able to see a dimmed version of the old value intermixed with
the new one.
3. The logic for hiding the IME while poking a button i.e. starting
to use another way of changing the current value, was incorrect.
bug:5480205
Change-Id: I1c2c96402bd38bac1dec64ccc6b550410332b9d7
This fixes a crash where we weren't hiding the view when there's
no registered media player. It now hides the view when AudioManager
tells it to clear the data.
It also avoids a possible race condition where a request can
come in from AudioManager before the callback is set.
Change-Id: I3360e775c75396e1eee11413d317df5b39ceb487
Since the feedback type is an integer the bits of which correspond to a given
feedback type, the AccessibilityNodeInfo#feedbackTypeToString should return a
string representation of all feedback types. The current implementation
incorrectly assumes that the argument had only one flag set. Note that this
is a new ICS API and we would like to have this fixed.
bug:5486933
Change-Id: I5e461c385e199cce4c3054907ff0acf5e9d92afc
It is no longer sufficient to check the value of
internal.R.bool.config_showNavigationBar to determine if a
navigation bar (separate from the status bar) is shown on a
device, because the emulator needs to be able to override
this value (now possible by setting qemu.hw.mainkeys to "1"
or "0", for navbar or no navbar, respectively).
This logic is now contained in PhoneWindowManager, and any
clients wishing to know whether the system has a software
nav bar should consult the new hasNavigationBar() method.
Bug: 5404945
Change-Id: I119d32a8c84b88b2ef46f63244e7f11dc5de0359
The code that initializes accessibility events was assuming the AdapterView
always has an adapter and this caused NPE. Now the right method of the view
is called to get the item count.
bug:5474162
Change-Id: I6c330dc2894477df9447a4ecfddc7bd62c575d59
A LayerScreenshot is a special type of layer that contains a screenshot of
the screen acquired when its created. It works just like LayerDim.
Make sure to call compositionComplete() after rendering into a FBO.
Bug: 5446982, 5467587, 5466259
Change-Id: I5d8a1b4c327f9973d950cd4f4c0bca7f62825cd4
- Fix ordering problem in sync manager that would cause its wake
locks to slightly appear in the system process when they should
be fully accounted against the app.
- Allow the system process to have more wake lock names in its
battery stats.
- In the bug report output, print totals of the wake locks for each
process, to make it easier to parse what is being printed for things
like the system process with a huge number of individual wake locks.
Change-Id: I3cf39330f22f3c51c11e65e4124150d73a7da2dd
This fixes three issues;
- Make the background black while the transport is showing.
- Show scrim sandwiched between artwork and overlapping UI.
- Remove gaps in sides of background assets.
Change-Id: I563fc680c4c042d8b25ec37332aeab528cf838ca
* commit '6d076a425ab10441996ebe194b0c181d16912ece':
fix bug where the instance saving of the ChooseTypeAndAccountActivity would only work in the case where onSaveInstanceState was called.
If you turn the device from portrait to landscape mode and immediately
invoke the lockscreen, it will come up in landscape mode and switch to
the desired portrait mode within a couple of seconds. Previously,
Face Unlock would come up in landscape mode, but its position would
not change once lockscreen corrected itself, causing Face Unlock to be
partly off the screen.
This has been fixed by checking if we are already bound to Face Unlock
when the layout is created. If this is true, then the layout is being
created due to a change in orientation, and we stop Face Unlock, and
restart it at the new position.
This commit also adds a fix where we now use INVISIBLE for the Face
Unlock area when it is not showing instead of using GONE. The
dimensions of the Face Unlock area is 0-by-0 when set to GONE, and we
want to avoid the possibility for the Face Unlock service being
assigned a zero area. I'm not sure if this was ever causing problems,
but it certainly is not the intended behavior.
Also cleaned up some comments and logging.
Change-Id: I68deb49cb26dafb5c238167d0c23f0eed2cfb75a
Making the notfication delete-all animation smoother by carefully
choreographing the various parts of it. The problem with the previous
animation was that there was simply too much going on at the
same time, causing things like layout and recreating display-lists
in the middle of animations that became choppy as a result. This
approach swipes all items off quickly, then scrolls the shade up to the
top, making both sets of animations smoother as a result.
Fixes#5431207: Notification delete-all should be smoother
Change-Id: Iefe8ab5d661e05adcd10379dab85227d17904450
