This change fixes the context menu trigger behavior while
the user is selecting via touch. How if a user is selecting
text via dragging their finger, to trigger the context menu
they will have to lift their finger up, then issue a
longpress. This is consistent with the behavior of selecting
via the trackball.
This change allows the user to select-n-scroll. While a user
is in select mode, and they try to scroll, the textbox will
scroll in the direction of the selection, and expand the selection.
With this change, when a user is in "text select" mode, they
can swipe any part of the text. This changes the behavior of
the touch-based select in 2 ways (behavior for cursor-based
select remains the same):
1. You can now indicate where your select will start. Before
this change, the select always started at the last cursor
position.
2. Selection will respect word boundaries. Before this
change the selection would be character to character. Since
users don't have a fine grain level of control over touch
events, this would often lead to incomplete selections.
Merge commit '8693f82d02fd9b3a805e076fa1eafacd1737446d' into eclair-mr2
* commit '8693f82d02fd9b3a805e076fa1eafacd1737446d':
Some work on issue #2286804: sometimes text field doesn't accept input
This doesn't really fix the problem being brought up here, but fixes a
related issue I found while investigating it -- if you tap a text view
enough to cause it to try to scroll, this will cause the touch to become
a scroll instead of a click, even if there is nothing to scroll. So
often quick taps to bring up the IME would be canceled because they
became a non-scroll.
Unfortuntately after syncing the latest build, I was having a lot of
trouble reproducing the original problem. I think I need to punt it to
MR2 at this point.
Change-Id: If1f0bf33de1b4d71c9f677cdad07639b7a3fb772
but can also be used by unbundled apps. Move android.text.util.Regex there as
a starting example, renamed to a more sensible (?) com.android.common.Patterns.
Set up a corresponding test package, and move RegexTest (to PatternsTest).
Update clients.
Merge commit '04a0e969c6ae4c81a187ce70fdcee3f026eee7ec' into eclair-mr2
* commit '04a0e969c6ae4c81a187ce70fdcee3f026eee7ec':
Add vertical bar to the alt-space character picker for the hardware keyboard.
This change is likely incomplete and perhaps not right in other ways.
The gist of the change is that the span can return the number of lines
to which to apply the "leading margin".
Some specific things that should be looked at:
1) if the user has nested multiple
LeadingMarginSpans then they will inherit the "line count" feature.
This is wrong but I didn't want to spend time fixing it until it
was clear that this overall approach was acceptible.
2) The units for how many lines should indented is "lines" rather than
something like dips.
3) I wasn't sure what our strategy was for binary compatibility so
I didn't want to modify the methods in LeadingMarginSpan. Instead I
made another interface with extends LeadingMarginSpan that has the
extra method to return the line count.
Add a hidden public method to text/method/Touch.java that
computes the maximum scroll amount for a text field.
Remove 'faketouch' code; it causes a crash and is
no longer required.
Pass the percentage of the current scroll from the UI
thread to webkit. One additional fix is to allow very
small movements which are currently disallowed because
they are smaller than 'smallerSlop' in WebTextView.java.
Companion fix is in external/webkit.
Fixes http://b/issue?id=2133049
Add API to skip the animation for a particular start activity, so that
a latter better one can be used.
Fix Theme.NoDisplay to actually work.
Fiddle with various animations: don't do a different animation for task
switching, try a scale animation for switching in/out of the wallpaper.
Adjust the animation duration so that at normal speed we have something
more like the slower animation option (so slow is now the default).
Change-Id: Ieba9f3db0bd9a762a19b327a3ecccbc7b547893d
Merge commit '56205fea879543a50bb797016832416a8b48cabb' into eclair
* commit '56205fea879543a50bb797016832416a8b48cabb':
Fix an emoji-measuring bug that caused an exception when editing a contact.
It was measuring the text to try to determine the size that it needed to
scale the emoji character to. Unfortunately it was accidentally trying
to measure the character under the cursor instead of the emoji character
itself, which is wrong, but more seriously doesn't work at all when the
cursor is at the end of the line.
This was already fixed before in change 144474, but that change never got
merged over to donut. So this merges it now.
Bug 2087915
Change-Id: Ib4804d330a029a966207b3b07271f84e6b2652c0
BoringLayout assumes it doesn't have to do any work to calculate the
line height. In this case, though, there may actually be work to be
done, so have it fall back to StaticLayout to do the more thorough job.
Bug 2051050
This unfortunately requires API changes because the existing text markup
classes had no access to the screen density.
TextPaint gains a "density" field so that TextView can pass the density
along. AbsoluteSizeSpan gains a new flag to indicate that its argument
is in dip instead of in physical pixels. LineHeightSpan gains an inner
interface whose chooseHeight() method includes a TextPaint argument so
it can get at the density. And when StringBlock creates the markup
objects, it now uses the density-aware versions.
Bug 1976971, Bug 2031746
Merge commit '11ea33471e1a14a8594f0b2cd012d86340dd3bd8'
* commit '11ea33471e1a14a8594f0b2cd012d86340dd3bd8':
Allow for screen density drawables in compatibility mode.
Merge commit '7c187de14f6b5ec6d90bc8e26265a2ca2824e39a'
* commit '7c187de14f6b5ec6d90bc8e26265a2ca2824e39a':
Make the DatePicker respect the date format setting if the date is numeric.
This change allows us to use drawables that match the current screen
density even when being loaded in compatibility mode. In this case,
the bitmap is loaded in the screen density, and the bitmap and
nine-patch drawables take care of accounting for the density difference.
This should be safe for existing applications, for the most part, since
they shouldn't really be pulling the bitmap out of the drawable. For
the small rare chance of them breaking, it worth getting the correct
graphics. Also this will only happen when there is actually a resource
of the matching density, and no existing apps should have resources for
anything besides the default density (though of course all of the
framework resources will be available in the native density).
As part of this, the bitmap density API has been changed to a single
integer provider the DPI unit density.
In some locales, there are no abbreviated month names; the abbreviated
date formats are essentially numeric. If the user is in such a locale,
have the DatePicker respect the date format setting so that the order
of the fields will match other numeric-only dates.
In locales that have abbreviated month names, continue to use the order
that is normal in spelled-out dates.
And update the order in updateDate() so that the new order is reflected
if you change the order setting and immediately go to change the date
without leaving and returning to the Date & Time settings in between.
At the same time, change DateFormat.getDateFormatOrder() back to working
the way it did in cupcake (prioritizing the date order preference over
the locale), even though the DatePicker no longer calls the method.
Bug 1805085
Apparently it can sometimes miss a touch release, which would prevent
the longpress menu from appearing if the location of the new touch was
too far from the location of the previous touch.
Bug 1673223
DateUtils.formatDateRange is using String.format which isn't efficient for
formatting large number of strings. I have added the Formatter parameter which
allows the caller to reuse the formatter of subsequent calls for faster
performance.
It is only used for numeric dates -- spelled-out dates have such a complex
variety of formats that they can only be meaningfully formatted from
locale strings.
In addition, the preference is left null when initializing, on the assumption
that the locale will still specify a more useful numeric format than we can
guess as part of a build-wide configuration.
But if the user has specified a format, the date will be formatted in the
order they asked for, with locale-appropriate punctuation substituted in.
The format strings are newly generated from CLDR. The code is once again
the same as in cupcake: do the natural thing for the locale if the user
has never specified, but follow the checkbox if the user has ever set it.
Use a resource instead of a hardcoded string for the 24-hour format
since it is not exactly the same in every locale.
Make sure the 12-hour format is actually for a 12-hour clock, even in
locales where this is not a normal thing to do. In the cap_ampm version,
do not have it try to capitalize "am" and "pm" if these are non-ASCII
strings, since strftime() doesn't know about Unicode and will mess it up.
Add a comment so that people don't think the YEAR_IN_MILLIS constant is
actually the length of any real year.
