This code structure causes a crash as rerported, better to extract
access to the settings to InputManagerService, who actually cares
about it.
Bug: 26196092
Change-Id: I4e0dbcc24ccf5d11681738ca3576b64471aa8cc4
We currently decide when to show the decor caption onConfigurationChanged
However, if the app handles configuration changes or the threshold isn't
big enough for the configuration change to be reported to the app, we don't
display the caption in some cases when transitioning from fullscreen mode
to freeform mode.
We now also use the onMultiWindowModeChanged call to also determine if
the caption should be visible.
Change-Id: I237437f04ad90f904912ebac0253245f547b0e3e
By default space should "click" the focused item. This behavior also
applies to GridView and ListView if the items are clickable, but will
continue the previous behavior of scrolling if it's just a list of
items you can't really interact with.
Change-Id: Ic3a0334614d1dc68ff98bc4b1fb1ae2f961f71af
In preparation for supporting replacement of child windows
we make replacement per window rather than per app.
Bug: 26070641
Change-Id: Ifa332086599c125611e430219c9497bae7e2ce31
The APIs are:
* setting a listener for the area of the caption where we display
control buttons; this is intended for apps that overlay the caption on
their content, so they don't display the content in that area and clash
with the buttons;
* specifying the color pallete of controls in the caption; by default we
try to infer the best color from the theme (dark buttons for light theme
and vice versa), but in case we get it wrong, we allow the developer to
overwrite it;
* specifying the caption background during the resizing; by default we
try to infer a good color from the theme, but in case we do it wrong, we
allow the developer to overwrite this.
The CL also includes merging of layouts decor_caption_dark and
decor_caption_light into a single one. Not only it reduces code
duplication, but also is necessary for allowing adjustment of the
controls color pallete after the layout was created.
Bug: 25486369
Bug: 25818398
Change-Id: Ib87fe849b07df341893ec7873982bf7ab932f6d5
With this CL, PhoneWindowManager starts monitoring Meta+Space to trigger
input method rotation.
Note that InputMethodManagerService currently supports only one way
rotation. Currently there is no difference in the behavior between
Meta+Space and Shift+Meta+Space. Reverse rotation will be supported in
a subsequent CL.
Bug: 25753404
Change-Id: I4005692215edfcf8bed3e86b1e07000148f986f5
This reverts commit c55d5072ac.
There were several bugs related to incorrect handling of various
layout issues (layout not being run on containers/views that needed
it), reverting to take another run at it outside of master.
Issue #25980198 requestLayout() sometimes doesn't result in measure/layout for view
Change-Id: Ic0e159cbcf6171652d8fd1bee9ae44a3977cea04
Previously the headers all had duplicate content, which is
now optimized to look visually more appealing.
Change-Id: I38ed8db1985fd8a9470888e1b7e1e6b0f2e23b19
The primary goal of this CL is to make it clear that BCP-47 is the
expected format to annotate locale information for each
{InputMethod, SpellCkecker}Subtype. In order to avoid possible
compatibility issues, this CL introduce a new "languageTag" attribute
instead of reusing existing "imeSubtypeMode" and "subtypeLocale"
attributes.
For IME developers, this CL changes nothing unless "languageTag"
attribute is specified. To summarize:
A: If only legacy locale-string is specified
(existing IMEs/Spell-Checkers fall into this category):
-> The system uses locale-string.
B: If only LanguageTag is specified:
-> The system uses LanguageTag.
C: If both locale-string and languageTag are specified:
-> The system uses LanguageTag. Legacy locale-string is ignored.
For application developers, there should be some follow-ups CLs because
even with this CL most likely they would still have to take care of
previous versions of Android where:
- Locale#forLanguageTag() (N/A in API Level 20 and prior)
- Locale#toLanguageTag() (N/A in API Level 20 and prior)
- InputMethodSubtype#getLocale() (Deprecated in N)
- SpellCheckerSubtype#getLocale() (Deprecated in N)
- InputMethodSubtype#getLanguageTag() (N/A in M and prior)
- SpellCheckerSubtype#getLanguageTag() (N/A in M and prior)
One idea would be is in the official support library to provide a utility
method that takes care of above tasks and just returns a Locale object.
If we had a utility method in the support library, probably not
returning a Locale object from #getLanguageTag() would make sense.
From performance point of view both existing legacy locale-string
attribute and new LanguageTag attribute are just String objects that
travel from XML manifest to system services to applications via IPCs.
Hence there are no performance implications except for having one more
String objects.
Bug: 22858221
Change-Id: I6db107ad2afc7709167f7c4e5d24bd589ac8bd70
A bug in recent layout optimizations was causing the framework to avoid
laying out containers with WRAP_CONTENT in one axis or the other.
This fix updates the logic in the code that finds dependent layout axes
to correctly account for this case.
Issue #25980198 requestLayout() sometimes doesn't result in measure/layout for view
Change-Id: Ie5f678beef5d8c4ba25291ffdcd59797d4697acc
What this CL actually does is just copying the existing concept
"subtypeId" from InputMethodSubtype to SpellCheckerSubtype.
To recap, the underlying problem is that the system has stored only the
return value of SpellCheckerSubtype#hashCode() to track the set of
enabled subtypes, and SpellCheckerSubtype#hashCode() has been
implemented as Arrays.hashCode(new Object[] {locale, extraValue}), which
is problematic because:
- Spell checker developers cannot change "locale" and/or 'extraValue'
if they want to keep enabled subtypes enabled.
- Android Framework developers cannot change the hash function even
when new fields are added if they want to keep enabled subtypes
enabled.
InputMethodSubtype has had the same issue, and what we did was
introducing a concept "subtypeId", which allows IME developers to
specify the return value of #hashCode().
For instance, suppose that a subtype X has already been used in
production with the following attributes:
- locale: "tl_PH"
- extraValues: "key1=value1,key2=value2"
With "subtypeId", you can change the attributes of subtype X without
losing the enabled state of subtype X on devices as follows.
- locale: "fil_PH"
- extraValues: "key1=value1,key2=value2,key3=value3"
- subtypeId: Arrays.hashCode(new Object[] {
"tl_PH", "key1=value1,key2=value2"})
This CL also deprecates existing public constructor of
SpellCheckerSubtype, which was probably published as a public API by
mistake. Note that the constructor of SpellCheckerInfo class is @hide.
Also there is no public API that receives SpellCheckerSubtype object
instantiated by developers with custom data. Making developers to be
able to instantiate SpellCheckerSubtype does not make sense right now.
Bug: 11736916
Bug: 22858221
Change-Id: I98f05c1e9421c47a93769bc4a6fe11b678bc2509
With following CLs, we already have a special rewrite rule of "tl" to
"fil" for IMEs that are targeting older versions of Android earlier than
Lollipop that did not support three letter language codes and used
"tl" (Tagalog) as the language string for "fil" (Filipino).
- 92280cd309 [1]
- ed65bc0c62 [2]
[1]: I94f203bddceb9c87710cb187cc3cc0ee6d9092a5
[2]: Ica9cd2baac002c406f92331aadd7725d7424046a
With this CL, we have the same rewrite rule for spell checker services.
Bug: 20696126
Change-Id: I0af0f520a15337e33973391c9965364e3ae1ee4c
This is the 2nd try of I39dc0c310158ad23ba6c987efce07deaf30ce693.
This is a mechanical refactoring with no behavior change.
With this CL, InputMethodSubtype and SpellCheckerSubtype have the same
getLocaleObject() hidden API, which makes it easy to share the logic in
subsequent CLs.
No behavior change is intended.
Bug: 11736916
Bug: 20696126
Bug: 22858221
Change-Id: I51be014c752b736a808e2b0d56e664941a218a2f
This is a mechanical refactoring with no behavior change.
With this CL, InputMethodSubtype and SpellCheckerSubtype have the same
getLocaleObject() hidden API, which makes it easy to share the logic in
subsequent CLs.
Bug: 11736916
Bug: 20696126
Bug: 22858221
Change-Id: I39dc0c310158ad23ba6c987efce07deaf30ce693
Restore exception throwing behavior on invalid arguments
for getLocationInWindow. This is tested by CTS.
Tweak some variable names to make the exception string readable.
Change-Id: I069d63b354d90ce74d156362b223765a5c2da2f0
This commit adds configurable support for lockscreen
behaviour when the user has a device cover/lid. This
is intended for lids with a viewing window so that the
user can see the time and interact with apps via the
window.
Change-Id: Id71883f66d1a180c4732912b3b59cabf9f4d7b6e
The primary goal of this CL is to enable application developers to
provide more context-based language (locale) information for IME
developers so that users can be benefited by more natural text input
experience.
As of API Level 23, there are several APIs that allow IMEs to retrieve
locale/country related information.
- Locale#getDefault()
- Configuration#locale
- LocaleSpan#getLocale()
- SubscriptionInfo#getCountryIso()
However, only LocaleSpan#getLocale() can be used to pass application
specific languge (locale) context from applications to IMEs. Also
LocaleSpan is not designed to be used per input-context. We want to
have something in EditorInfo and LocaleList would be the right thing.
Although default implementation of TextView#onCreateInputConnection()
starts filling EditorInfo#localeList with TextView#getTextLocales() by
this CL, application developers are encouraged to provide its own
LocaleList when they are confident that the user want to use a
certain (set) of language(s).
For instance, a chat application may be able to guess what language will
be used in the conversation before the user start typing. At least it
should be able to remember the last used language for each conversation.
Another instance would be "From" and "To" EditText fields in a
translation app. Those fields should have different LocaleList based on
the languages that the user want to translate from and to.
Bug: 22859862
Change-Id: I77db5b99a7cf745d800db75baf135bb60ad04820
So we don't have to implement crazy magic when one app requests
drawing the status bar by itself, and the other doesn't in split
mode.
Bug: 24365214
Change-Id: I1f6a0efd0865b784402055e008da2f31e626f163
