WifiInfo changed to return SSIDs with quotes included, so relax our
identity matching to accept matches regardless of quotedness.
Bug: 7695807
Change-Id: Ib5d06666035e06b2d4b2f7cb498767d63b1b1828
An earlier fix made it possible to call requestLayout() during layout
(which is not recommended in most cases outside of a ListView) without
ending up with blank content and internal layout flags in a confused state.
However, that fix incorrectly detected a problem in some cases (such as
ListView practices of adding views during layout) which were actually okay;
as long as you make sure to measure and layout your children properly
before returning from layout(), then it's not a problem. We were improperly
spamming the log with supposed problems, and causing more overhead in correct
cases by running a full request/measure/layout pass after the first layout
pass, all of which is unnecessary in cases where the containers know what
they're doing.
This new fix changes the logic to only cause the second layout pass (and third,
posted to the next frame, if things are really done incorrectly) if the layout-request
flags are still set on the requesting views after the full layout pass is complete.
This situation causes the blank screens we've seen in buggy apps, and is exactly
what we should avoid. However, correct cases (e.g., ListView) will not have these
problems because they run measure/layout correctly after the request calls, which
clears these flags. The upshot is that buggy cases will be detected and compensated for
(by clearing the flags and then running a second request/measure/layout pass, as in the
original fix) and non-buggy cases will be noop'd, going back to their previous, working
logic flow.
The bug below is one of the buggy apps to demonstrate this problem. I noticed that the
original problem (blank screen) is no longer reproducible. I suspect that logic was
added to the app to force a refresh after it is attached. You can still detect the problem
(and the fix) by seeing that prior to the fix (say, on mr1.1) there is a delay of about
a second between the end of the progress bar updates and the showing of content on a
screen that used to just remain blank. With the fix (both the previous version and this
one), the content is updated immediately, because we now handle the buggy request-
during-layout situation in the same frame as it occurs.
Issue #6914123 News and Weather app sometimes loads to a blank screen
Change-Id: I4c34817cc3dd44ba422ff50de4321624c0824d83
It appears StyledAttributes was renamed to TypedArray
prior to fw 1.0. Leaving references to the old name
around in the public docs is confusing.
Deliberating leaving...
tests/coretests/src/android/widget/LabelView.java
... as is - it's clearly unused.
Change-Id: I3f66e5f9cbe945d9d86530d37b88369b401f054d
1. This patch takes care of the case where a magnified window is covering an unmagnigied
one. One example is a dialog that covers the IME window.
bug:7634430
2. Ensuring that the UI automator tool can connect and correctly dump the screen.
bug:7694696
3. Removed the partial implementation for multi display magnification. It adds
unnecessary complexity since it cannot be implemented without support for
input from multiple screens. We will revisit when necessary.
4. Moved the magnified border window as a surface in the window manager.
5. Moved the mediator APIs on the window manager and the policy methods on the
WindowManagerPolicy.
6. Implemented batch event processing for the accessibility input filter.
Change-Id: I4ebf68b94fb07201e124794f69611ece388ec116
More reuse of StringBuilders, less broken home-grown formatting code.
Long-term, we should hand this over to icu4c, but they're not ready yet.
Bug: http://code.google.com/p/android/issues/detail?id=41401
Bug: 7736688
Change-Id: Ib3c1e1aad05827df646aa18645cce19dffb7551f
Pass targetSdkVersion to installd so it knows the appropriate
permissions to apply to the app's home directory.
Bug: 7208882
Change-Id: Ia62ed36b32ee5af01077fb10a586024411be8ed4
During the destroy sequence, it happens that the mWebViewClassic was
set to null in the transferMessages function and consequently, the
call to WebCoreThreadWatchdog.unregisterWebView(mWebViewClassic) is
not really removing the view from the watchdog's list; creating a
memory leak.
Change-Id: I2bae7c8d7c473e2af25e62a485699f88269d6658
Author: Jean-Christophe PINCE <jean-christophe.pince@intel.com>
Signed-off-by: Jean-Christophe PINCE <jean-christophe.pince@intel.com>
Signed-off-by: Shuo Gao <shuo.gao@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 57869
A recent change altered semantics of getLanguage call to return client
language instead of service language. This solved problems
with interferences between two clients using different lanaguages.
This change created a bug - new TTS client instance have no language set.
Since reading user preferences requires additional permissions I've
added new tts service method - getClientDefaultLanguage that will return
user preferences.
I've also added new client method, getDefaultLanguage, that allow easy
access to this data.
Bug: 7666482
Change-Id: Ieb7d2ba3a99d20c513add97f054874720a1cd82e
* commit 'dc4beb483eb14f1b56154125c67b780802756572':
Make implementation of isEmpty consistent with implementation of getCount in HeaderListViewAdapter
* commit 'e7ec492f13355888c90b3f08fbc66e49dda7ed24':
Make implementation of isEmpty consistent with implementation of getCount in HeaderListViewAdapter
