Fix an off-by-one bug in EditableInputConnection#endBatchEdit() return value

This is a follow up CL to our previous CL [1], which had an off-by-one
bug when determining the return value of

   EditableInputConnection#endBatchEdit().

According to the API document of InputConnection#endBatchEdit(), the
following test should pass.

   EditText editText = new EditText(context);
   EditorInfo editorInfo = new EditorInfo();
   InputConnection editableInputConnection =
           editText.onCreateInputConnection(editorInfo);
   assertThat(editableInputConnection.beginBatchEdit()).isTrue();
   assertThat(editableInputConnection.beginBatchEdit()).isTrue();
   assertThat(editableInputConnection.endBatchEdit()).isTrue();
   assertThat(editableInputConnection.endBatchEdit()).isFalse(); // (*)
   assertThat(editableInputConnection.endBatchEdit()).isFalse();

However, the last assertion marked with (*) actually fails due to an
off-by-one bug.  This CL finally fixes it.

The risk of app compat breakages because of fixing this long standing
bug is supposed to be low, mainly because:

 * the system has not relied on this return value yet.
 * Widgets like WebView have correctly implemented this API.
 * IME has always received true no matter what the app returned, which
   is the same behavior as other async InputConnection APIs.

This CL adds several notes to InputConnection#endBatchEdit() document
to help developers correctly implement and use this API.

 [1]: I1ec5518fdc16fb0551fbce9d13f5d92eb4bc78c0
      c478c171e92b2f255e9699d9c9306b001368ac20

Fix: 209958658
Fix: 210165648
Test: atest -c CtsInputMethodTestCases:EditTextImeSupportTest
Change-Id: Ibc40072fa11a4d6e3c24b8d7860c914ccdbcbc8a

0 files changed, 0 insertions, 0 deletions