Rather than associate the keyboard layout solely with a specific
hardware model, we should also associate it with a given IME subtype.
This lets users switch between various languages and have the
keyboard change in unison with them so they can use the appropriate
layouts for each language.
This change adds initial support for associating IME subtypes and
keyboard layouts. We still need to:
- Remove support for the old style of layout association once the
Settings apps begins to use the new APIs
- Automatically select an appropriate layout based on the given
subtype (or set a reasonable universal default such as QWERTY)
Bug: 25752812
Change-Id: Ie88ce1ab77dbfe03ab51d89c1dc9e0a7ddbb3216
* Add support for determining script from language and region.
* Add support for determining special parents of locales.
* Add support for smart comparison of locales with only a difference
in region, using the locale parentage tree.
* Fix LocaleData.matchScore() to not fallback to old locale matching
behavior if we can't determine a script.
* Allow four-character variant codes. (Previously, only five- to
eight-character variant codes were allowed.)
Bug: 7296673
Bug: 26589793
Change-Id: Ibde0a48c0564ff383b41068095a5cbacfe7b94bc
- Reset and restore the visibility flags and hasSurface states when
surface is saved or restored. When the surface is in saved stated,
we have to make the rest of the system believe that the window has
no surface.
- Set app windows to 'mExiting' when we start a transistion because
window manager changes the visibility of the app. We can't rely on
receiving a relayoutWindow from the app to invisible. We need to
mark it exiting so that when the transition is done, the surfaces
get removed (or saved if possible) promptly.
- We need to save the surface if the app token is the last one in
a task, regardless of whether it's visible, this means the whole
task is going into background. But if the app has another visible
token on top of it, we don't need to save it. For example one
activity launches another activity, in this case we don't want to
save the surface of the activity on the bottom.
bug: 26573100
Change-Id: Id845f87b30cda1cebcc12ad2ac8dbf19a068a86e
During the initial attempt to support automatic language switching in
LatinIME, it turns out that the current EditorInfo#locales is difficult
to use and even confusing in some situations. Based on that
experience, this CL changes as follows:
* Rename EditorInfo#locales to EditorInfo#hintLocales:
This is mainly to avoid possible confusion when to set this. We want
to make it clear that having non-empty LocaleList there is a clear
signal that the user would switch to certain languages regardless of
the currently selected input method subtype.
* Make EditorInfo#hintLocales nullable:
Previously marshaling EditorInfor causes NPE when
EditorInfo#hintLocales is null. This CL relaxes such a restriction.
* Introduce TextView#{set, get}ImeHintLocales():
In the previous implementation [1], we just copied
TextView#getTextLocales() into EditorInfo. This is, however, does not
work well because it is no more or less than the default value. If
LatinIME supports automatic language switching, having the default
value in EditorInfo actually means that whenever you focus in a new
text field, the keyboard language is reset to the default locale.
In order to make this "hint" useful for IME developers, this "hint"
should be specified only when the application developers are confident
to do so.
[1]: I738ffaaf07091d8b980f8bfc6e16227fcb85a96a
0445fdf321e74044dc9f3719922fc8ff4923fdf4
Bug: 22859862
Change-Id: I0a730011874ea8d01e50624ed3f1ecd197d05f94
- Remove the gesture detector from the MultiSelectManager, and
consolidate gesture detection and event dispatch logic in
DirectoryFragment.GestureListener.
- Route single-tap events through the DocumentHolder, so that it can
apply view-specific logic, like making a tap on the item's icon
select rather than activate.
- Consolidate event handling logic in the ItemEventListener.
- Add new unit tests for DocumentHandler.
BUG=24326546
Change-Id: Id15cdd11b13e4c063c1baff95aa8ee09c190d6c3
Refactor Jobs to work with files from multiple providers.
Don't shut down threadpool until service#onDestroy is called.
Bug: 26696797, 26462789, 26567205, 25162803, 26714663
Change-Id: Id43e8e3dc2294cd07dcd6a3477b19efb298c260f
The libziparchive returns an error on empty zip files.
Work around this by checking for that error condition and
returning an empty ZipFileCollection.
Change-Id: I9edaf2e089456b6ccb4bb099b20ede10331bd352
* kill app when suspending
* block starting ONLY activities for suspended apps
* do not allow suspending the device admin package
Bug: 22776761
Change-Id: I3ee5fcb2d6828f363ce0f024dbc662ab29275192
Fragments contained within an activity are restored from instance
state in FragmentActivity.onCreate, but fragments contained within
another fragment were previously restored from instance state in
performCreate after onCreate returned. This meant that developers
couldn't consistently rely on being able to control when this happens
with a call to super.onCreate, and calls to findFragmentByTag to
reconnect with a restored child fragment would fail in ways that
succeed when the fragment is directly added to an activity.
Change child fragment instance state restore to happen during
Fragment.onCreate instead of in performCreate to be consistent with
activity behavior. Preserve the old behavior for apps targeting
an SDK version < N.
Change-Id: I9c88d5554da9a32219d64c70ca638f75ecb233ed
