The existing behavior of EditText is that trailing blanks can cause a
line to exceed the layout width, causing the cursor to extend past the
line, which in turn causes horizontal scrolling. This patch clamps the
cursor to the layout width in the non-scrolling case, which makes the
spaces effectively invisible when they're at the end of the line, but at
least suppresses the scrolling.
The clamping only works reliably in left-to-right alignments, so this
patch checks for than and only enables the clamping in those cases.
Fix for bug 7699295.
Change-Id: I22bc4e6c9ded3d7716edfcf10dd2b5c31a5da9de
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
The C++ class names don't match what the classes do, so rename
ISurfaceTexture to IGraphicBufferProducer, and SurfaceTexture to
GLConsumer.
Bug 7736700
Change-Id: I08e677faf2ebb418ef131d0a8008e01037db0e50
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
