bug(keyboard): Android WindowInsetsAnimationCompat.Callback does not filter by Type.ime() — any inset animation re-emits keyboardWillShow/keyboardDidShow (or the hide pair) with the current IME state #2616

Plugin

Keyboard 8.0.6

Current Behavior

Keyboard.java L90–128: onStart(animation, bounds) (L90) and onEnd(animation) (L114) never inspect animation.getTypeMask(). For every WindowInsetsAnimation dispatched to the root view they read insets.isVisible(Type.ime()) and emit:

• keyboardWillShow + keyboardDidShow (with the current IME height) if the keyboard happens to be visible,
• keyboardWillHide + keyboardDidHide otherwise.

So an animation of the system bars (immersive mode toggling, navigation-bar hide/show, a status-bar animation triggered by an overlay) while the keyboard is open replays a full show sequence to JS although the keyboard did not move; with the keyboard closed it replays a hide sequence although nothing was open.

Observed on the Android 14 emulator (API 34, Pixel 6 profile, 1080×2400 @ 420 dpi, Gboard, 3-button navigation), app with @capacitor/keyboard 8.0.6 and @capacitor/status-bar 8.0.4, listeners on all four events, trigger = StatusBar.hide() followed 1.2 s later by StatusBar.show() (both animate the status-bar inset through WindowInsetsControllerCompat; the keyboard itself was not touched):

Keyboard open and settled (keyboardHeight: 336 had been reported once):

Keyboard closed:

Four keyboard events per status-bar round trip in both states, with nothing having changed about the keyboard. An app that animates its composer on keyboardWillShow/keyboardWillHide re-runs that animation each time (and, with the keyboard closed, runs a hide ride for a keyboard that was never open).

Expected Behavior

Keyboard events describe the keyboard: an animation of the status or navigation bars, with the keyboard not moving, produces none.