Program: 192295
Project: 192295
Buggy source:
/** 
 * Take care of handling configuration changes.  Subclasses of InputMethodService generally don't need to deal directly with this on their own; the standard implementation here takes care of regenerating the input method UI as a result of the configuration change, so you can rely on your   {@link #onCreateInputView} andother methods being called as appropriate due to a configuration change. <p>When a configuration change does happen, {@link #onInitializeInterface()} is guaranteed to be called the nexttime prior to any of the other input or UI creation callbacks.  The following will be called immediately depending if appropriate for current  state:  {@link #onStartInput} if input is active, and{@link #onCreateInputView} and {@link #onStartInputView} and relatedappropriate functions if the UI is displayed.
 */
@Override public void onConfigurationChanged(Configuration newConfig){
  super.onConfigurationChanged(newConfig);
  boolean visible=mWindowVisible;
  int showFlags=mShowInputFlags;
  boolean showingInput=mShowInputRequested;
  CompletionInfo[] completions=mCurCompletions;
  initViews();
  mInputViewStarted=false;
  mCandidatesViewStarted=false;
  if (mInputStarted) {
    doStartInput(getCurrentInputConnection(),getCurrentInputEditorInfo(),true);
  }
  if (visible) {
    if (showingInput) {
      if (onShowInputRequested(showFlags,true)) {
        showWindow(true);
        if (completions != null) {
          mCurCompletions=completions;
          onDisplayCompletions(completions);
        }
      }
 else {
        doHideWindow();
      }
    }
 else     if (mCandidatesVisibility == View.VISIBLE) {
      showWindow(false);
    }
 else {
      doHideWindow();
    }
    boolean showing=onEvaluateInputViewShown();
    mImm.setImeWindowStatus(mToken,IME_ACTIVE | (showing ? IME_VISIBLE : 0),mBackDisposition);
  }
}

Fixed version (ground truth):
/** 
 * Take care of handling configuration changes.  Subclasses of InputMethodService generally don't need to deal directly with this on their own; the standard implementation here takes care of regenerating the input method UI as a result of the configuration change, so you can rely on your   {@link #onCreateInputView} andother methods being called as appropriate due to a configuration change. <p>When a configuration change does happen, {@link #onInitializeInterface()} is guaranteed to be called the nexttime prior to any of the other input or UI creation callbacks.  The following will be called immediately depending if appropriate for current  state:  {@link #onStartInput} if input is active, and{@link #onCreateInputView} and {@link #onStartInputView} and relatedappropriate functions if the UI is displayed.
 */
@Override public void onConfigurationChanged(Configuration newConfig){
  super.onConfigurationChanged(newConfig);
  boolean visible=mWindowVisible;
  int showFlags=mShowInputFlags;
  boolean showingInput=mShowInputRequested;
  CompletionInfo[] completions=mCurCompletions;
  initViews();
  mInputViewStarted=false;
  mCandidatesViewStarted=false;
  if (mInputStarted) {
    doStartInput(getCurrentInputConnection(),getCurrentInputEditorInfo(),true);
  }
  if (visible) {
    if (showingInput) {
      if (dispatchOnShowInputRequested(showFlags,true)) {
        showWindow(true);
        if (completions != null) {
          mCurCompletions=completions;
          onDisplayCompletions(completions);
        }
      }
 else {
        doHideWindow();
      }
    }
 else     if (mCandidatesVisibility == View.VISIBLE) {
      showWindow(false);
    }
 else {
      doHideWindow();
    }
    boolean showing=onEvaluateInputViewShown();
    mImm.setImeWindowStatus(mToken,IME_ACTIVE | (showing ? IME_VISIBLE : 0),mBackDisposition);
  }
}