The keyboard key-press haptic feedback should follow the user
settings for "Touch feedback".

Bug: 185351540
Test: manual
Change-Id: I718d3bf15b1ef841a869a898038d0eca1eca78f0

With CL[1],[2] to migrate InputMethodService as the subclass of the new
introduced class WindowProviderService in S_V2, IME context resources
can be managed by associating the window container of IME window when
its display/window configuration changed.

So we can get rid of createDisplayContext logic from S_V2 with gated
by SDK version and refining the method of get IME context with
documentation to make it clear.

[1]: Ie565e30ed5dd3f2cfe27355a6dded76dc3adc14b
[2]: I64a1614f32d097785915f6105b1813a929e0fe32

Bug: 213118079
Bug: 133825283
Test: manual with below steps
 1) adb install -r EditTextVariations.apk
 2) tapas LatinIME
 3) make
 4) adb install -r out/target/product/generic/system/app/LatinIME/\
        LatinIME.apk
 5) adb shell ime enable com.android.inputmethod.latin/.LatinIME
 6) adb shell ime set com.android.inputmethod.latin/.LatinIME
 5) Enable screen auto-rotation
 7) Launch EditTextVariations from launcher's shortcut
 8) Tap the first EditText field to show IME
 9) Rotate the device to the landscape mode
 10) Expect the IME should not be shrunk

Change-Id: If2cc1c5bdb257a9c0af653fa7157cf781a90bf1d

As CL[1] introduces diplayContext to address
IME service context's Resources / DisplayMetrics update when
switching IME window to another display after onConfigurationChange.

In LatinIME#onInitializeInterface, we only update keyboard theme context
and displayContent when the displayId is changed, but overlooked even
the displayId is the same, the display context's resource configuration
might changed like the device orientation changd.

It leads getDefaultKeyboardHeight will get wrong config_max_keyboard_height
fraction value when rotating to landcape because the context resources
didn't get updated.

Add a check to update keyboard theme context when the current display
configuation is changed accordingly.

[1]: I0ed6a079af1ed90c75fee1d36d5ce3ef3c41f8ed

Fix: 186507147
Test: manual as issue steps
    1) Turn on auto-rotate
    2) Open Settings
    3) Rotating the device to landscape mode
    4) Tap “Search settings", verify if the soft-keyboard shown and the
       size is expected.
Change-Id: I288a31baf04fa2e63d6b4a14ad81b401cb36ece5
Merged-In: I288a31baf04fa2e63d6b4a14ad81b401cb36ece5

As CL[1] introduces diplayContext to address
IME service context's Resources / DisplayMetrics update when
switching IME window to another display after onConfigurationChange.

In LatinIME#onInitializeInterface, we only update keyboard theme context
and displayContent when the displayId is changed, but overlooked even
the displayId is the same, the display context's resource configuration
might changed like the device orientation changd.

It leads getDefaultKeyboardHeight will get wrong config_max_keyboard_height
fraction value when rotating to landcape because the context resources
didn't get updated.

Add a check to update keyboard theme context when the current display
configuation is changed accordingly.

[1]: I0ed6a079af1ed90c75fee1d36d5ce3ef3c41f8ed

Fix: 186507147
Test: manual as issue steps
    1) Turn on auto-rotate
    2) Open Settings
    3) Rotating the device to landscape mode
    4) Tap “Search settings", verify if the soft-keyboard shown and the
       size is expected.
Change-Id: I288a31baf04fa2e63d6b4a14ad81b401cb36ece5

See https://source.android.com/setup/contribute/respectful-code for reference

Bug: 162536543
Change-Id: I5df9e60ec6caa2e1e3253532c2b59b74adfc1749

See https://source.android.com/setup/contribute/respectful-code for reference

Bug: 161896447
Change-Id: I171bc299e660f96f20041a67a3052bd8a2ed781c

See https://source.android.com/setup/contribute/respectful-code for reference

Bug: 161896447
Test: tapas LatinIME && m
Change-Id: I2ffb39ff70f61e579b62761d3da526a545dead1f

To address IME service context's Resources / DisplayMetrics update
when switching IME window to another display after onConfigurationChange.

We use Context#createDisplayContext to create display specific context when
display changed, to ensure soft keyboard can re-layout with correct resources.

Bug: 126930163
Test: manual with AOSP IME as below steps:
     1) Settings > Developer options > enable "Simulated Display" & "Force desktop mode".
     2) Reboot device
     3) Launch app (i.e. Contacts) with bluetooth or usb mouse in Simulated display.
     4) Tap EditText on app to see see if IME window layout correctly on simulated display.
     5) Launch app (i.e Files) on primary display.
     6) Tap EditText on app to see if IME window layout correctly on primary display.

Change-Id: I0ed6a079af1ed90c75fee1d36d5ce3ef3c41f8ed
Merged-In: I0ed6a079af1ed90c75fee1d36d5ce3ef3c41f8ed

To address IME service context's Resources / DisplayMetrics update
when switching IME window to another display after onConfigurationChange.

We use Context#createDisplayContext to create display specific context when
display changed, to ensure soft keyboard can re-layout with correct resources.

Bug: 126930163
Test: manual with AOSP IME as below steps:
     1) Settings > Developer options > enable "Simulated Display" & "Force desktop mode".
     2) Reboot device
     3) Launch app (i.e. Contacts) with bluetooth or usb mouse in Simulated display.
     4) Tap EditText on app to see see if IME window layout correctly on simulated display.
     5) Launch app (i.e Files) on primary display.
     6) Tap EditText on app to see if IME window layout correctly on primary display.

Change-Id: I0ed6a079af1ed90c75fee1d36d5ce3ef3c41f8ed

Remove EXTENDED_TOUCHABLE_REGION_HEIGHT from LatinIME#onComputeInsets
to prevent keyboard touch region covered navigation bar
when in split-window mode with display density < 240 case.

Fix: 134893742
Test: manual as below steps:
1) Set window density as 240 with "adb shell wm density 240"
2) Launch a app (i.e. Messages) from recents activity, set as split-screen mode.
3) Tap Search bar to show IME keyboard.
4) Press home / back / recents key if it works, expect it works.

Change-Id: I596b7276041fecc50d2bc095c7e51664f632368d

This CL demonstrates how an IME can show an Activity on the display
where the IME is shown.  The key points are:

 * The current display ID can be obtained as follows.

    final int curentDisplayId = inputMethodService
            .getSystemService(WindowManager.class)
            .getDefaultDisplay()
            .getDisplayId();

 * When launching an Activity, specify the target display ID as
   follows.

    inputMethodService.startActivity(intent, ActivityOptions
            .makeBasic()
            .setLaunchDisplayId(curentDisplayId)
            .toBundle());

Fix: 131718879
Test: Manually verified as follows.
  1. Build aosp_blueline-userdebug and flash it.
  2. adb shell settings put global force_desktop_mode_on_external_displays 1
  3. adb shell settings put global overlay_display_devices 1920x1080/320
  4. adb reboot
  5. With a mouse, launch any application that has input field
     in the secondary display.
  6. Click that input field to bring up AOSP Keyboard.
  7. Long click the comma key then select the gear icon.
  8. Select "Android Keyboard Settings (AOSP)"
  9. Make sure that the AOSP Keyboard Settings is launched in
     the secondary display, not in the default display.
 10. Go back to the step 7.
 11. Select "Languages"
 12. Subtype Enabler for AOSP Keyboard is shown in the secondary
     display, not in the default display.
Change-Id: I9f89f371c38d9a7b5a06d018d4b41aa09815ea24

This CL partially reverts
  - Id88b02b74bdfe4ca05b08181ceb6b34d5652fc0c
  - I05c7d8429e8d9a26139456763c77997340fea8c2
And followup (remove shortcut support)
  - I73b7dc008a5acaf75a31a36a2d332b5afabd82d0

Bug: 28255684
Test: make -j10 dicttool_aosp
Change-Id: I2e01ed86b9517a1141aee35ea6d8ef39258981d1

PersonalDictionaryLookup has never been used.  Usually proguard can
remove this class but it also makes it difficult to run unit tests.

We should just remove this unused class.

Bug: 111164993
Test: compile
Test: No new test failure
Change-Id: I732db94cb3aac4ed9c6b5954679b896334a12a9c

Bug: 76692459
Test: mmma packages/inputmethods/LatinIME/
Change-Id: Ib76af6f6db1a0dd5cf64a06a4ea56151712e9692

This CL a logical revert of a previous CL [1], which separated Java
files into common ones and overridable ones.  Now that that overriding
concept is no longer used, there is no need to keep having separate
directory structure.

 [1]: Ic734bd4d20aa050c688a3158b1a382ae0ac18991
      fb74ab15

Fix: 79323502
Test: make -j aosp_taimen-userdebug && make -j
Test: tapas LatinIME && make -j
Change-Id: I2090bc25d18e6d4f24e91c2cbfe832755cbb4e8f

This CL introduces a custom intent action for apps to ask AOSP Keyboard to
close its software keyboard with guarding it with a signature-protected
permission.

Any app that is signed with the same signature as AOSP Keyboard can have
the following line in AndroidManifest.xml

  <uses-permission
          android:name="com.android.inputmethod.latin.HIDE_SOFT_INPUT"/>

to request AOSP Keyboard to close its software keyboard as follows.

  sendBroadcast(new Intent("com.android.inputmethod.latin.HIDE_SOFT_INPUT")
          .setPackage("com.android.inputmethod.latin"));

Test: Manually verified with a test app.
Fixes: 65270710
Change-Id: I4fd2e3a7336ec66c70582a2f274a200cbf035a7f

LatinIME checks hardware keyboard presence and software keyboard
visibility to decide whether to start full screen mode.
This doesn't work well with the recent update on "Show input method"
(Bug: 22517687, Id4d332e3909590c68345e).

On the first tap, software keyboard is not shown and hardware keyboard
is connected; so full screen mode is not started. However,
onEvaluateInputViewShown may return true ant software keyboard may be
brought up.
In this care, on the second tap, software keyboard is visible so full
screen mode will be started regardless of hardware keyboard presence.

This CL checks onEvaluateInputViewShown to decide whether to start
full screen mode.

Bug: 27234709
Change-Id: I587262cc36e5fccc59620b4bd2d2c3c05c72232f

We want to expose Serbian (Latin) layout as "sr-Latn" to the system,
while our internal logic may not be ready to deal with "sr-Latn" yet.

As a temporary workaround, we remap "sr-Latn" into "sr_ZZ" for our
internal use.

Bug: 27348943
Change-Id: I93ff0c75b3687bb1b913f451b9eb5f2820beefbc

This is a follow up CL to the previous CL [1], in which we started
calling Window#setNavigationBarColor(int) when the window visibility is
changed.

One thing we missed is that calling Window#setNavigationBarColor(int) on
KitKant or prior devices would result in a runtime crash.  Hence with
this CL we do not call that method unless the OS version is N or leter,
because specifying Color.TRANSPARENT would make sense on N+ devices.

  [1]: I14d9490e00caa852035a05830e76114cbe6af8f2
       6c04339c

Bug: 22564251
Bug: 27302540
Change-Id: Ib7299dd8c3dad4271f8fac453e690c83bda4a954

With this CL, LatinIME switches the current subtype from its enabled
subtypes based on the first locale in EditorInfo#hintLocales.

This functionality is still experimental, and will be triggered only
when EditorInfo#hintLocales is specified by the application.

Bug: 22859862
Change-Id: Ibd0559b370d8aa0d50d1bada8ecfdac0ed8db898

With this CL, RichInputMethodSubtype#getLocale() starts returning
a Locale object that is initialized with "languageTag" when it is
specified.  No behavior change is intended when "languageTag" attribute
is not available or specified.

Bug: 22858221
Change-Id: I23f2e479b8e284ce589c6950b071ba84c5dd8ce1

The opaque navigation bar guard view does not make much sense when the
IME does not show software keyboard at all.  LatinIME does not show
any UI when the hardware keyboard is connected.

With Iea77915ecc55eedaf19899e72c44f704ba9d852c, input method can change
the navigation bar visibility.  This CL changes navigation bar invisible
when the hardware keyboard is connected.

Bug:22564251
Change-Id: I14d9490e00caa852035a05830e76114cbe6af8f2

Change the way we decide whether we want to show on-screen keyboard by
not only paying attention to modifiers, but also keeping track whether
the key sequence started in the right state.

We are still misfiring if user presses a non-modifier key and then our
modifier hot-key, but such sequence is unlikely. Given the fact that we
do not want to store too much state I believe this deficiency is
acceptable.

Bug: 25087681
Bug: 24142161

Change-Id: I1a6b5e8e903c27a87134a6c9a7cd474a0607d5c8
(cherry picked from commit 7c513455918a52bd28c1c8181cb2880db0973b4b)

Out of the box, we want Alt-Left to toggle Emojis, while Alt-Right
toggles the shifted symbols layout.

Bug: 23954008
Bug: 24369173

Change-Id: I93dd66fb469e5d0a831359ff3a786fe68e1d73ea
(cherry picked from commit 411841b374aa04e333ea5a438dfd539f49ec589a)

Bug 23900149.

Change-Id: Iff8a3892bb88f82736e5fa680c38d98cda4d2777
(cherry picked from commit e1641395e30de7b53b06fc5c820ea83bf04b3aad)

Bug: 23082844
Change-Id: I7baac5e5a0700280906fd0f5f9351fc8dfc4c2b3
(cherry picked from commit 990e9a75b6d88ba234131612f11eac6b69c1cf84)

This build has been compiled against API 23

This build is approved to go out with the M OTA, but may NOT be released
to the public until the Play Store has enabled API level 23 apps

Version: 4.1.2300x.build_id


1. Disable the settings.
2. Disable the feature.
3. Force reload the facilitator.

Bug: 22564048
Change-Id: Ic09742786c3e4efc034bceee836ae6a1e07307a1
(cherry picked from commit 031d04192080f0368f21c3371d1ec6af87375357)

This build has been compiled against API 23

This build is approved to go out with the M OTA, but may NOT be released
to the public until the Play Store has enabled API level 23 apps

Version: 4.1.2300x.build_id

1. Replaces the personalization is on information with the suggest
   contacts.
2. Enables "Use Contacts" only if the app has permission to read
   contacts.
3. Disables the contacts dictionary in the Facilitator.
4. Do not register/read the contacts in the contact observer.

Bug: 22236416
Change-Id: I9674e13d0d0f4a2014c5024fde0178de684c07e7

FileUtils is being used for other non android projects
and hence breaks when built. Instead use the log statements
at caller to record Log.e messages. Hence there is no side
effect here.

Bug:22042371
Change-Id: Ieb100006ff38e013bc30542637465f58bfc0f2f2

For JB and lower devices, the UI is surfaced by the IME.
Bug: 22200135
Change-Id: Icca08500ee0683e2ceb5357b0bc430cd1712220e

This will ensure that a new (or upgraded) keyboard instance will know which
dictionaries are available for download so it requests missing dictionaries.
In addition, we increment the database version number to ensure upgrades of
existing Fava instances start with a clean slate.

Bug 22069694.

Change-Id: Id71310412682543a3931f9c5c03cb0369fa7b9ac

Change-Id: Ibdf97726008c1f94c970461196ba445ce328a8cb

The initial reloadTextCache() operation needs to read 1k characters, and it
could be slow on low-end devices. Also, the initial load is not blocking key
strokes, so it can take a little longer.

Bug 22062102.

Change-Id: I134424e8910c0d6131c311a862bdc87eccd3af44

1. Add mechanism to detect a slow or non-resonsive InputConnection (IC)
2. When IC slowness is detected, skip certain IC calls that are known
   to be expensive (e.g., getTextAfterCursor).
3. Similarly, disables learning / unlearning on a slow IC.
4. IC slowness flag is reset when starting input on a new TextView or
   when a fixed amount of time has passed.

Note: These are mostly temporary workarounds. The permanent solution is
to refactor RichInputConnection so that it is less sensitive to IC
slowness in general.

Bug: 21926256
Change-Id: I383fab0516d3f3a8e0f71e5d760a8336a7730f7c

Users rarely tap on committed words, and the cost of sending the spans back
through the input connection, back and forth to the target app, is too high.

Bug 21926256.

Change-Id: I8e55b57ce2148ed313dc927425b6d9c958634958

This is causing issues we can't deal with in a safe and timely manner.
Furthermore, users who need downloaded dictionaries already have them by now.

Bug 21797386.

Change-Id: I97e5fd84edcf2b16f04db57b7ae4a13fa9ce993f

Bug: 21797386
Change-Id: Ic09698b28e31b4f16831898d7cb08853f4e5df4a

Also adds a hook to log using StatsUtils.
Proto change is coming in a separate CL.

Bug 22010482.

Change-Id: I08065fc7a5cd116e50ff84cb14bbbc44c4f14bc7

Bug: 21797386
Change-Id: I60f50a2fe890af46f5e847c34df2edf719d40ac4

We never delete text after the cursor, so constrain the API accordingly.
Define the number of characters to read before and after.
Set them to reasonable values.
The next CL will start caching text after the cursor.

Bug 21926256.

Change-Id: Idd58daf68614de4a69344aa3c8a4323720c5d3a0