bug(android): Keyboard is blinking in the background during the Keyboard changes using globe key

[bharanidharanj]

Describe the bug

I noticed that while changing the keyboards using globe key, the Keyboard running in the Keyman application is blinking.

Reproduce the bug

1. Install Keyman 17.0.78-alpha build in a Mobile device / emulator.
2. Open Keyman application.
3. Install additional keyboards like Khmer Angkor and sil_cameroon_azerty keyboards.
4. Long press the globe key.
5. Verify that the Language menu list opens.
6. Change the language from the default keyboard to sil_cameroon_azerty keyboard.
7. Here, the Keyboard running behind the language list menu blinks.
8. Change the language from sil_cameroon_azerty keyboard to default keyboard.

Here, the Keyboard running behind the language list menu is blinking for a while.

I have attached the video(keyboardblinking.mp4) file for reference.

keyboardblinking.mp4

Expected behavior

Keyboard blinking should not happen If the keyboard changes using globe key.

Related issues

No response

Keyman apps

• Keyman for Android
• Keyman for iPhone and iPad
• Keyman for Linux
• Keyman for macOS
• Keyman for Windows
• Keyman Developer
• KeymanWeb
• Other - give details at bottom of form

Keyman version

17.078-alpha

Operating system

Android 11.0

Device

Redmi Note 8 Pro

Target application

No response

Browser

No response

Keyboard name

No response

Keyboard version

No response

Language name

No response

Additional context

No response

[mcdurdin]

Relates to keyboard resizing and banner during keyboard switching, made more complex by async. Probably need to have a 'begin change' and 'end change' lock on refresh.

[darcywong00]

From Sprint A17S11 sprint plan triage, we would've closed this one if dupe on #7161, but I don't see it, so moving to 17.0

[darcywong00]

The blinking seems to mostly happen when going from a keyboard w/o suggestions to keyboard w/ suggestions.

Maybe from #6559 where toggleSuggestionBanner occurs on
prepareKeyboardSwitch and
setKeyboard

[mcdurdin]

Noting for reference, so it isn't missed: in #9622, based on the video, the OSK temporarily goes to a desktop form-factor default when only sil_euro_latin is installed and it's reselected from the language picker.

[jahorton]

See https://github.com/keymanapp/keyman/pull/9696/files/68f2661e1f118cfc105c2ef131d7f4c1477e90f9#r1395117451 for some likely contributing factors.

[jahorton]

Diving into something else we noticed: this block hasn't been changed since #1842, for version 14.0:

keyman/android/KMEA/app/src/main/java/com/keyman/engine/KeyboardPickerActivity.java

Lines 267 to 276 in 8ebb725

	protected void onPause() {
	super.onPause();
	if (KMManager.InAppKeyboard != null) {
	KMManager.InAppKeyboard.loadKeyboard();
	}
	if (KMManager.SystemKeyboard != null) {
	KMManager.SystemKeyboard.loadKeyboard();
	}
	}

Before that, the loadKeyboard calls were wrapped in a conditional - they'd only activate if a keyboard download or update was triggered. (if (didUpdate) ...) This was back when keyboard updates were managed through the picker - in fact, this commit was part of said transition. git blame does point to me here; there's a strong chance that we can remove the calls and that I had simply been overcautious back then.