Merge pull request #561 from Countly/fix_background_inputs_flow_contents

fix: direct key events to background view for contents

Author: arifBurakDemiray

CHANGELOG.md

@@ -2,6 +2,8 @@
 * Added gradle configuration cache support to upload symbols plugin.
 * Improved user properties auto-save conditions to flush event queue with every user property call.
 
+* Mitigated an issue where content overlays and feedback widgets prevented keyboard input on the underlying activity's text fields while displayed.
+* Mitigated a memory retention issue where content overlays and feedback widgets could be briefly held in memory after closing, surfacing under repeated open/close cycles.
 * Mitigated a memory leak where the content overlay retained the activity it was first opened in across subsequent activity transitions.
 
 ## 26.1.2

sdk/src/main/java/ly/count/android/sdk/ContentOverlayView.java

@@ -15,6 +15,7 @@
 import android.util.Log;
 import android.view.Gravity;
 import android.view.KeyEvent;
+import android.view.MotionEvent;
 import android.view.View;
 import android.view.ViewGroup;
 import android.view.ViewTreeObserver;
@@ -196,6 +197,50 @@ public boolean dispatchKeyEvent(KeyEvent event) {
         return super.dispatchKeyEvent(event);
     }
 
+    @Override
+    public boolean dispatchTouchEvent(MotionEvent ev) {
+        // Dynamically transfer IME focus between the overlay and the host activity:
+        //   - ACTION_OUTSIDE (delivered because of FLAG_WATCH_OUTSIDE_TOUCH): user
+        //     touched outside the overlay's bounds; the touch already passed through
+        //     to the activity via FLAG_NOT_TOUCH_MODAL, but we additionally restore
+        //     FLAG_NOT_FOCUSABLE so the activity's EditText can claim IME focus.
+        //   - ACTION_DOWN (touch inside the overlay's bounds): clear FLAG_NOT_FOCUSABLE
+        //     so the WebView's form fields can bring up the keyboard.
+        // Consumes nothing; existing touch handling (WebView, etc.) continues normally.
+        if (ev.getAction() == MotionEvent.ACTION_OUTSIDE) {
+            setWindowFocusable(false);
+            return true;
+        }
+        if (ev.getAction() == MotionEvent.ACTION_DOWN) {
+            setWindowFocusable(true);
+        }
+        return super.dispatchTouchEvent(ev);
+    }
+
+    private void setWindowFocusable(boolean focusable) {
+        if (!isAddedToWindow || windowManager == null) {
+            return;
+        }
+        try {
+            WindowManager.LayoutParams lp = (WindowManager.LayoutParams) getLayoutParams();
+            if (lp == null) {
+                return;
+            }
+            boolean alreadyFocusable = (lp.flags & WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE) == 0;
+            if (alreadyFocusable == focusable) {
+                return;
+            }
+            if (focusable) {
+                lp.flags &= ~WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE;
+            } else {
+                lp.flags |= WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE;
+            }
+            windowManager.updateViewLayout(this, lp);
+        } catch (Exception e) {
+            Log.w(Countly.TAG, "[ContentOverlayView] setWindowFocusable, failed to update flags", e);
+        }
+    }
+
     private TransparentActivityConfig getCurrentConfig() {
         if (currentOrientation == Configuration.ORIENTATION_LANDSCAPE) {
             return configLandscape;
@@ -219,9 +264,19 @@ private WindowManager.LayoutParams createWindowParams(@NonNull Activity activity
             }
         }
 
+        // FLAG_NOT_FOCUSABLE: overlay does NOT grab IME focus by default, so the
+        //   underlying Activity's EditText can receive keyboard input even while the
+        //   overlay is shown. Toggled off in dispatchTouchEvent on inside touches so
+        //   the WebView's <input>/<textarea> can still bring up the keyboard.
+        // FLAG_WATCH_OUTSIDE_TOUCH: deliver an ACTION_OUTSIDE event to the overlay
+        //   when the user touches outside its bounds, so we can return focus to the
+        //   non-focusable state. The actual touch still passes through to the host
+        //   activity via FLAG_NOT_TOUCH_MODAL.
         int flags = WindowManager.LayoutParams.FLAG_LAYOUT_IN_SCREEN
             | WindowManager.LayoutParams.FLAG_LAYOUT_INSET_DECOR
-            | WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL;
+            | WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL
+            | WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE
+            | WindowManager.LayoutParams.FLAG_WATCH_OUTSIDE_TOUCH;
 
         if (!isContentLoaded) {
             flags |= WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE;
@@ -367,6 +422,25 @@ private void enableTouchInteraction() {
 
     private void removeFromWindow() {
         if (isAddedToWindow && windowManager != null) {
+            // Expedite any pending scrollbar-fade Runnables: scrolling inside the WebView
+            // schedules a ScrollabilityCache fade Runnable on the main MessageQueue. If
+            // the View is detached before that Runnable fires, the pending Message keeps
+            // ViewRootImpl alive (and through it, this overlay) for ~550ms — visible as
+            // a transient leak under repeated show/close cycles. Calling awakenScrollBars(0)
+            // re-schedules the existing fade with zero delay, so the Message drains on the
+            // next message-loop iteration (~16ms) and the View becomes GC-eligible promptly.
+            // No-op if mScrollCache wasn't created (no scrolling occurred).
+            try {
+                // CountlyWebView#expediteScrollbarFade exposes protected View#awakenScrollBars(int)
+                // (only callable through inheritance, hence the wrapper on the subclass).
+                if (webView instanceof CountlyWebView) {
+                    ((CountlyWebView) webView).expediteScrollbarFade();
+                }
+                awakenScrollBars(0);
+            } catch (Exception ignored) {
+                // Public API, but defensive against any edge-case throws during teardown.
+            }
+
             try {
                 // Use removeViewImmediate for synchronous removal to prevent WindowLeaked.
                 // WindowManager.removeView() is async (posts MSG_DIE), so the view may still

sdk/src/main/java/ly/count/android/sdk/CountlyWebView.java

@@ -15,4 +15,14 @@ public CountlyWebView(Context context) {
     public boolean onCheckIsTextEditor() {
         return true;
     }
+
+    /**
+     * Expedites any pending scrollbar-fade Runnable by re-scheduling it with zero delay.
+     * Used by ContentOverlayView before detach to drain MessageQueue entries that would
+     * otherwise hold the ViewRootImpl alive for ~550ms (transient leak under stress).
+     * No-op if no scroll cache exists. Calls protected View#awakenScrollBars(int).
+     */
+    void expediteScrollbarFade() {
+        awakenScrollBars(0);
+    }
 }