Deprecate private AsciiCapable protocol

The concept "AsciiCapable InputMethodSubtype" was initially introduced
as a private protocol based on a magic keyword "AsciiCapable"
specified in "imeSubtypeExtraValue" attribute in API level 15 [1],
then became a public API "isAsciiCapable" attribute in API 19 [2].

However, it turns out that there remains one place in InputMethodUtils
where the previous private protocol is still used.

With this CL, InputMethodUtils stop relying on the previous private
AsciiCapable.

 [1]: I1a83b227498073c47567f73566043c273809adc9
      c36905673a
 [2]: Ic3ace4b6e0432d56696bcbc0be336aec1dc744a5
      dc8abf6cee

Fix: 78537996
Test: make doc-comment-check-docs -j
Test: atest InputMethodPreferenceTest InputMethodUtilsTest
Change-Id: I56c0c19878657a41882c2d784e1ac96a52ab33f6
This commit is contained in:
Yohei Yukawa
2018-04-24 18:36:23 -07:00
parent 88363dfc70
commit b1845f317c
3 changed files with 9 additions and 12 deletions

View File

@@ -67,7 +67,6 @@ public class InputMethodUtils {
private static final String NOT_A_SUBTYPE_ID_STR = String.valueOf(NOT_A_SUBTYPE_ID);
private static final String TAG_ENABLED_WHEN_DEFAULT_IS_NOT_ASCII_CAPABLE =
"EnabledWhenDefaultIsNotAsciiCapable";
private static final String TAG_ASCII_CAPABLE = "AsciiCapable";
// The string for enabled input method is saved as follows:
// example: ("ime0;subtype0;subtype1;subtype2:ime1:ime2;subtype0")
@@ -539,7 +538,7 @@ public class InputMethodUtils {
final int numApplicationSubtypes = applicableSubtypes.size();
for (int i = 0; i < numApplicationSubtypes; ++i) {
final InputMethodSubtype subtype = applicableSubtypes.get(i);
if (subtype.containsExtraValueKey(TAG_ASCII_CAPABLE)) {
if (subtype.isAsciiCapable()) {
hasAsciiCapableKeyboard = true;
break;
}