This new widget replaces DigitalClock. It listens to all the correct
system events and offer the ability to customize the formatting
patterns in 12-hour and 24-hour modes. It also supports fixed
time zones to create world clocks.
One more step towards becoming ClockOS!
Change-Id: I677e5dfca8cd8c8d1f8c49e54d7507f4d1885bf4
This patch fixes bug 7346656. In this particular case, the text line in
the EditText was split into multiple spans, with the boundary between
the "r" and "," in "r,". These were being drawn as two separate runs,
but measured as a single run, leading to inconsistent measurements
because this is a kern pair in Roboto.
The fix is to eliminate the special-case code for measuring. This will
actually improve efficiency, as the value computed in one pass is now
more likely to be reused in another.
Change-Id: I04142a0ec98f280fc1027c7cbdbf903e3096f8e4
Generate <p dir="rtl"> instead of <p dir=rtl>. The form with the quotes
is cleaner and will reduce warnings in apps that consume the output.
Change-Id: Ic9879c8c882c42079598b741e897a24415d96374
This fixes the digits in places like Settings' data usage page
and Calendar's drop-down, for languages such as Arabic.
Bug: 6811327
Change-Id: I2dafcc342e3279937735697b3748b47fdfc8e691
Use getZeroDigit() instead of a hard-coded '0' for formatting times using
formatElapsedTime, so locales with different digits like Arabic and Persian
could display the elapsed time properly. This is visible in Settings' list
of running apps.
Also changed android.text.format.Time's format3339 method to always use ASCII
digits, irrespective of the locale.
Change-Id: I731c96c21b3712ec347d9526e4ec3fe884dec276
This brings DateUtils and Time in sync with bionic, icu, WebKit,
DateFormatSymbols, Formatter, and SimpleDateFormat. And specifically
means that DateUtils now knows how to say "AM" and "PM" in Japanese.
Bug: 6719054
(cherry-pick of b12b61a88a029730b1f2b006ff914c9c719f3942.)
Conflicts:
core/res/res/values/public.xml
Change-Id: Ic1a811621a0ec338abd77458ac2046577f87c1e4
Applications using these fields and methods are just asking for i18n bugs.
Also @deprecate two int[]s that were never meant to be public.
Change-Id: I29b3a1c0c663fe344d2567df6ed3bb537270b3b7
All variations of getRelativeTimeSpanString() now properly handle dates
that are in the future. Prior, the version used by
getRelativeDateTimeString() would occasionally show the time instead of
a date when the future date was the same weekday as the current weekday.
This resulted in the time output being duplicated, eg.: "11:23, 11:23"
Change-Id: If20972a6942cce792fa233437f94dedfb71379f3
Signed-off-by: Steve Pomeroy <steve@staticfree.info>
We were doing line breaks after punctuation as long as they weren't
surrounded by digits. This is a misinterpretation of the Unicode line
breaking algorithm. Punctuation (class IS) is not hugely different than
the default classes (NU and AL) - there are breaks after punctuation
that are allowed (for example, followed by an open parenthesis), but
we're not implementing the algorithm with anything near that level of
fidelity.
The long term fix is to really implement the algorithm. In the shorter
term, the easiest thing to do is to remove the special case altogether.
Change-Id: Ic4dc3216c2a4191fbb7cfa06e9dc038d1a56398c
Cherry-pick of I7f1b0d49a2ece957a7b9b5d65d48385bf2c2a668 from master.
I've also provided TextView.setTextLocale() for use in single-language
TextViews.
Change-Id: I5692859bfd2aafc284172454d943afc250b22535
The mPos field in the MeasuredText object is relative to the start of
the text (mTextStart), but the pos passed in by the caller of the
setPos() method is relative to the character sequence. When spans
overlap break boundaries and the paragraph doesn't start at 0, the
result is an out of bounds error. This fix uses the correct offset.
Change-Id: I64ef06df0eb06f75aedd25de97e9f347eeb52979
The mPos field in the MeasuredText object is relative to the start of
the text (mTextStart), but the pos passed in by the caller of the
setPos() method is relative to the character sequence. When spans
overlap break boundaries and the paragraph doesn't start at 0, the
result is an out of bounds error. This fix uses the correct offset.
Change-Id: I12c7a2311a9bdbbea7ab21554a922b7f665a17bf
Skipping spaces at ends of line used to be done only when ok != here
(a potential line break was found).
Moved this logic up one level to handle all cases.
Also moved maxLine test in the block that actually adds a new line.
Updated the unit tests accordingly.
Change-Id: Ib10bc838b1ffa5b8a60259ea4b622d9fecb2ec70
Bug 6598784
The algorithm uses three imbricated loops:
- paragraphs
- span regions (called "blocks" in that description) in these
- characters in these
We can ignore the paragraphs and assume paraStart==0.
The span region loop cuts the text into blocks of text which share
the same set of MetricAffectingSpan spans applied to them. Note that
spanStart and spanEnd represent such a range, and not necessarily an
actual span range.
The third loop then iterates over the characters of these blocks, and creates
a new line (calling out() as soon as the width has been reached.
The core of the problem comes from the 'nextSpanStart' variable.
It is used to restart the block loop from a previous position in case
a line has been created that does not intersect with the current block.
However, in case the current block is larger than the width of the text,
the character loop is going to create other lines of text before we exit the
j-loop. Going back to the block loop, we reset spanStart to the nextSpanStart,
which may be too far back in the text. As a result, the same range of characters
is measured again.
The (spanStart == spanEnd) test was used to handle the case where
nextSpanStart was indeed assigned to a value different than spanEnd.
This fix simplifies this logic and removes the nextSpanStart variable:
When the created line ends before the current block (here < spanStart), we
immediately exit the character loop, re-starting the block loop from the
current position.
Patch 4: added a fix in measured to handle overlapping character ranges.
Change-Id: Ie71b3cf4018b332e335ea916fef08acb43a6679e
Bug 6642222
Using setMaxLines(0) and setMinHeight(30) causes a crash
because Layout#getLineRangeForDraw() returns a [0,0] interval
in that case.
Accessing the Direction in draw causes a NPE.
Change-Id: If50f9b554e3cdc598a721b623992e9196982838c
This change is analogous to Ic0e9f1bbd8cae9fdd3a6d1d015bb9224c8be545c
in WebView, and depends upon the same Skia change that that CL makes
use of.
This flips the "fake bold" flag on for bold fonts in
TextView.setTypeface(), with the expectation that Skia will ignore
the flag if the final typeface used to render the glyphs is already
bold. It also does the same for StyleSpans, TextAppearanceSpans,
TypefaceSpans, and the Switch widget.
With this, fake bold should work uniformly across all scripts - if
fake bold works for a primary typeface, it should also work for all
fallback typefaces.
Bug: 6629786
Change-Id: Id3b8639ab0df83052ffd82809cb12adaacc1d46b
Make clearer how the platform is handling key events following some
unfortunate uses by third party applications. Also highlight the
changes in Jelly Bean default keyboard.
Bug: 6566711
Change-Id: Ibcdaf54c6d629fd0733529bfe2fffc82f555f084
Bug 5763685
To improve performance, preventively cut the the into display
list of 3-10 lines of text. Further updates to small parts of
the text (such as adding an underline on a word) will only
invalidate and redraw the affected sub display list.
DLs are aligned with paragraphs, just like they will be during
text edition.
Change-Id: I0d60debc7fdaea8b29080a6eacb2d60205e7d547
