Previously, hasTransientState returned true even when TextView has a
selection that hasn't been created by the user. This unnecessarily
prevents the TextView from being recycled.
This issue was introduced by Ib454b0fbbc2c2f8d198, which fixes that
setHasTransientState(true) is not always coupled with
setHasTransientState(false).
With this CL:
hasTransientState will get true when selection action mode is started.
hasTransientState will get false when selection is removed.
Note that hasTransientState intentionally continues to be true when
selection action mode is terminated with preserving selection.
Bug: 27913323
Change-Id: I960ddfd7221caeb676c23926af06a8a415dec288
ERROR_CANNOT_RESUME is the correct code for one, and relative paths
are supported by the RFC, so change the test to check for success.
Bug: 27580939
Change-Id: Ife99c22a44dd71232466e35d38a2441c16a558f7
This service connects through the print manager to the print spooler:
PrintSpooler.AddPrintersActivity <-> PrintManager <-> PrintManagerService <-> UserState <-> RemotePrintServiceRecommendationService <-> PrintRecommendationService <-> PrintRecommendationServiceImpl
Hence there is a lot of mindless plumming.
The actual changes are only in the AddPrintersActivity which is extended
to show another list of services: The recommended services.
The PrintServiceRecommendationService is based on the experimenal print
service stubs provider. This provider was contributed the Android by
Mopria. As this services uses Android own network discovery service most
code from the experimental provider goes away. In fact the only logic
left over is the selections of mdns-txt fields to look at and the
printer vendor configuration.
This relies on the Android MDNS to get fixed (Bug: 27696905). This also
does not deal with how to update the recommendation service.
Bug: 24533249
Change-Id: I6edc6e25fc08a50d478b61c71bb8ea158b08624c
Previously it was assumed that one Resources object per Activity would be fine.
This proved to be incorrect, as methods like Context#createConfigurationContext()
expect to create a new Resources object that gets updated whenever the Activity Resources
get updated.
To fix this issue, there exists a master override configuration for each Activity. Subsequent
Resources created for an Activity will be based off that master override configuration, and
will be updated accordingly.
Bug:27644297
Bug:27604953
Change-Id: Idb3d851f55ee7981eec4e3fe28e2ea8d55f1192d
Re-enable TextViewActivityMouseTest#testContextMenu that was disabled
by I459f1ab1c6d2d3119fc50166.
Bug: 27765262
Change-Id: I986ec239324d2d65a14be3fb2981777583471c68
Now that CE data isn't available until after a user is unlocked, we
need to delay the PRE_BOOT_COMPLETED broadcasts. This is done by
adding a new RUNNING_UNLOCKING user state to the UserController
lifecycle.
We now track the last fingerprint a user was logged in under, and we
dispatch PRE_BOOT receivers when that fingerprint changes. To work
around battery pull issues, we only persist the updated fingerprint
once all PRE_BOOT receivers have finished. This is less granular
than the original solution, but it's still correct. We only consider
a user as "logged in" once it transitions into the RUNNING_UNLOCKED
state.
When starting a process, track if the user was "unlocked" when
started, so that we only spin up unaware providers in processes
started before user unlock.
Add generic IProgressListener to communicate PRE_BOOT progress and
strings up to lock screen. For now, LockSettingsService just blocks
until finished, but it could display these strings in the future.
Bug: 27220885
Change-Id: I349439776b885acd32f6a578d8951ffd95640be2
This test is causing failures which are blocking other test results.
Disabled until a fix can be submitted.
Bug: 27765262
Change-Id: I459f1ab1c6d2d3119fc50166e8de0d1259801e2a
A point on a direction boundary can be mapped to two offset and
one offset on a direction boundary can be mapped to two points.
Previously, paragraph's primary direction is always used for deciding
offset and coordinates; thus, handle movement around a direction
boundary is often nonintuitive.
With this CL:
1. For selection end handle, direction of character at offset - 1 is
used for deciding handle shape and position.
2. For getting offset from coordinates, previous offset is used to
minimize the offset delta and primary .
3. For getting coordinates form offset, new logic chooses primary or
secondary horizontal coordinate depending on the current run
direction and paragraph direction.
4. When a handle passes another one because it passes a direction
boundary, new logic keeps the handle at the run boundary instead of
minimizing the selection.
Bug: 19199637
Bug: 21480356
Bug: 21649994
Change-Id: I2a7e87ad08416f4bd01a5f68e006240f77d9036b
When hint text is used for cursor positioning, the cursor may end up
in opposite direction when the locale and the hint text directions are
different. This CL uses the main text layout and discards the hint
layout while deciding on the position of those three views. The change
also includes fix for cursor and floating popup not displaying for
some cases after the change.
Bug: 22358087
Change-Id: I083d17b06273bc1d9b67656c5e12d4ff1231219c
With Ic025c109539c3b5963, selection action mode is created always
when selection is made. It causes distraction in some cases.
This CL fixes this issue. This CL stops starting selection action
mode when action mode is currently not active and not intended to
restart.
Bug: 27536744
Bug: 27551819
Change-Id: I94ee66864000934a21ef0d18c1d71429c67114fa
Implementation can choose the support of ZWJ and Emoji modifier, so move
them back to CoreTests.
Bug: 27553165
Change-Id: Ief9ae64c8c731b927295f54d09512256449b5a88
Due to I20a86c1bdeb361686, SuggestionsPopup was not shown when there
is a suggestion span that has misspelled flag and doesn't has any
suggestions. This CL makes SuggestionHelper#getSuggestionInfo return
misspelled span info separately.
Bug: 27534987
Change-Id: Ib76588f9388287a04f1f6c9d9067ae439e493a95
With this CL, we expand the target of Bug 27129703 and Bug 27348943 to
non-keyboard subtypes.
Suppose there is a handwriting IME (mode == "handwriting") that supports
the following 5 subtypes.
- en-US
- en-GB
- fr
- sr-Cyrl
- sr-Latn
Also suppose the system languages are configured as follows.
1. sr-Latn-RS
2. ja-JP
3. fr-FR
4. en-GB
5. en-US
In this case we want to enable [sr-Latn, fr, en-GB] by default when
"use system language" is checked in the subtype enabler.
See previous commits [1][2] about how we addressed those issues for
keyboard subtypes.
[1]: Iaf179d60c12b9a98b4f097e2449471c4184e049b
e985c240e3feb62ea38d5b4e386be083ca0f215b
[2]: I8fc774154f5175abff2f16e8f12a4847bf5f5b7c
072a95a3094af2ced4f009ad62c4553c28e3f830
Bug: 27560993
Change-Id: I416b5671602c550805ed6267dd210968aa1de83c
When there are not enough number of suggestions, previously used
suggestions was continue to be used. This fixes it and simplifies code
by always allocating SuggestionInfo array.
Bug: 27602619
Change-Id: I9378315b8c810f126f65fade96ce9f6ff5271957
This CL addresses a regression introduced by a recent CL [1] that
non-keyboard subtypes are no longer implicitly enabled based on the
system language (a.k.a. "use system language" in the subtype enabler)
due to a type mismatch in comparison.
Here is the original logic:
if (language.equals(systemLanguage) && systemLocale.startsWith(locale))
And here is the logic replaced by [1]:
if (locale != null && locale.equals(systemLanguage)) {
The new logic is simply broken, because locale is a Locale object while
systemLanguage is a String object. It never matches.
With this CL we will compare the system language with the locale
language again, with several test cases that should have been included
in [1], as a temporary solution until we start relying on
LocaleUtils#filterByLanguage() for non-keyboard subtypes.
[1]: Iaf179d60c12b9a98b4f097e2449471c4184e049b
e985c240e3feb62ea38d5b4e386be083ca0f215b
Bug: 27560993
Change-Id: If2d1710174853180465832e6ecbbb91235b76210
Each Activity has a Resources object whose underlying state changes
when a configuration change occurs, both global and for that activity only (multi-window).
Views and other clients of the Resources object can safely cache it knowing that
they always have a reference to the most up-to-date resources.
This applies to Resources.Theme objects as well.
Bug:26854894
Change-Id: Ifd3da5a1086e17f747dfc265a447fe92a3a5c692