Following up on https://github.com/square/curtains/issues/3

The API largely continues what OnContentChangedListener established.

Tests check that the callback isn't invoked immediately with a current value (I don't think we know it anyway). Tests check that activity focus changes after being resumed and before being paused. There isn't a test case for activity gaining focus after a dialog is dismissed. At this point we're just testing the framework instead of the library, I think. I ran tests locally on AOSP AVDs API 19 and 21-29.

I tried to use it on a new project:

window.touchEventInterceptors += TouchEventInterceptor { event, dispatch ->
  Log.d("AppLog", "touch")
  dispatch(event)
}

But it doesn't seem to do anything.

See attached:

RecordAppSample.zip

Hi, I'm trying to use OnTouchEventListener like this:

class PingDispatcherLifecycleCallback : Application.ActivityLifecycleCallbacks {
    private val pingDispatcher = OnTouchEventListener { motionEvent ->
        if (motionEvent.action == KeyEvent.ACTION_DOWN) {
            Log.d("ping", "send")
        }
    }

    override fun onActivityResumed(activity: Activity) {
        activity.window.touchEventInterceptors += pingDispatcher
    }

    override fun onActivityPaused(activity: Activity) {
        activity.window.touchEventInterceptors -= pingDispatcher
    }
    ...
}

if put Fragment into Activity and add child Fragment into root Fragment It stop to receive onTouch events

it become works after adding this callback into PingDispatcherLifecycleCallback in onActivityResumed callback

class PingDispatcherLifecycleCallback : Application.ActivityLifecycleCallbacks {
    ...
    private val fragmentOnAttachListener = object : FragmentManager.FragmentLifecycleCallbacks() {
        override fun onFragmentResumed(fm: FragmentManager, f: Fragment) {
            window.touchEventInterceptors -= pingDispatcher
            window.touchEventInterceptors += pingDispatcher
        }
    }

    override fun onActivityResumed(activity: Activity) {
        supportFragmentManager.registerFragmentLifecycleCallbacks(fragmentOnAttachListener, true)
    }
    ...
}

is it bug or legal behaviour of Android?

Gradle 7.3.2 adds dependency constraints to the build classpath to reject known-bad versions of log4j.

See also https://blog.gradle.org/log4j-vulnerability.

Can we switch to using the androidx components so that consumers can drop jetifier? Since this leakcanary is dependant on this, so consumers cannot drop the jetifier.

Currently it seems the class in question is

android.support.v7.view.WindowCallbackWrapper

Hi, unless you're already working on it, i'd like to start working on a PR for onWindowFocusChanged callback.

One question, do we leverage DispatchState (like touch events) or not (like content changed, my favorite)?

Copied over from https://github.com/square/leakcanary/issues/2280 by @mlilienberg

Description

My app is crashing when showing Dialog Fragments while R8 is turned on and with latest version 2.8.1. I think the issue is that curtains dependency does not provide correct proguard rules. curtains.internal.WindowCallbackWrapper is accessing WindowCallbackWrapper from androidx and android.support via reflection. Adding proguard rules to app level solves the issue for me but it would be better if leakcanary or curtains could define those rules.

-keep class androidx.appcompat.view.WindowCallbackWrapper { *; }
-keep class android.support.v7.view.WindowCallbackWrapper { *; }

See https://github.com/square/curtains/pull/30#issuecomment-1005422341 for details

View.windowType should return TOOLTIP if the window was created by androidx.appcompat.widget.TooltipPopup

We need to do this without having a direct bytecode reference to androidx.appcompat.widget.TooltipPopup or adding a transitive dependency, as curtains needs to remain android x free.

Because of i18n, the title may be not "Tooltip" in some country. For example, "提示" in Chinese.

And the unit test tooltip_view_has_TOOLTIP_type failed.

com.squareup.curtains:curtains:1.2.1 androidx.appcompat:appcompat:1.3.0 R8 mapping.txt: androidx.appcompat.view.WindowCallbackWrapper -> impl.g1: android.view.Window$Callback mWrapped -> c

retraced stack trace: java.lang.NullPointerException at curtains.internal.WindowCallbackWrapper$Companion.getJetpackWrapped(WindowCallbackWrapper.kt:112) at curtains.internal.WindowCallbackWrapper$Companion.unwrap(WindowCallbackWrapper.kt:147) at curtains.WindowsKt.getWrappedCallback(Windows.kt:247)

Using the plugin canISayByeByeJetifier to detect libraries using Android's deprecated Support Libraries, it accuses Leak Canary as a problem because it uses Curtains. This is the issue it gives:

curtains\internal\WindowCallbackWrapper$Companion$jetpackWrapperClass$2.class -> android.support.v7.view.WindowCallbackWrapper

I have found a screen to have multiple root views when using Jetpack Compose DropDownMenu and the DropDownMenu is visible. The first is a standard DecorView, the second is a PopupLayout.

When acquiring the window of the PopupLayout through rootView.phoneWindow, null is returned.

A nudge towards the right direction to acquire the window of the PopupLayout would be greatly appreciated.

java.lang.IllegalStateException: Cannot call removeOnDrawListener inside of onDraw
	at android.view.ViewTreeObserver.removeOnDrawListener(ViewTreeObserver.java:704)
	at curtains.internal.NextDrawListener$onDraw$1.run(NextDrawListener.kt:27)
	at android.os.Handler.handleCallback(Handler.java:790)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loop(Looper.java:164)
	at android.app.ActivityThread.main(ActivityThread.java:6523)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:857)

I noticed this issue when testing an app that uses fragments to set the toolbar.

MyFragment.kt

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
  super.onViewCreated(view, savedInstanceState)
  // This causes the activity's window callback to be reset to `mAppCompatWindowCallback`
  (requireActivity() as AppCompatActivity).setSupportActionBar(toolbar)
}

The root cause can be seen in AppCompatDelegateImpl.

AppCompatDelegateImpl.java

    @Override
   public void setSupportActionBar(Toolbar toolbar) {
      // Below the windowCallback is reset based on `mAppCompatWindowCallback` or some wrapped variant. Curtain's wrapper will be overridden.
       if (toolbar != null) {
           final ToolbarActionBar tbab = new ToolbarActionBar(toolbar, getTitle(),
                   mAppCompatWindowCallback);
           mActionBar = tbab;
           mWindow.setCallback(tbab.getWrappedWindowCallback());
       } else {
           mActionBar = null;
           // Re-set the original window callback since we may have already set a Toolbar wrapper
           mWindow.setCallback(mAppCompatWindowCallback);
       }

       invalidateOptionsMenu();
   }

Longer explanation:

Setting a toolbar in Activitity.onCreate() is not an issue since mWindow.setCallback(...) above runs well before the ActivityThread goes through the process of adding a new view to the global window manager.

Curtains relies on modifications of mViews in the window manager via the spy delegator list. If setSupportActionBar runs after the view is added to the window manager, Curtains can't attach its window callback. Curtains would have to wait until addView is called again (which is not the case for fragments).

Possible workarounds

1. Modify mAppCompatWindowCallback to be the Curtains callback wrapper, such that any subsequent setSupportActionBar() call retains the Curtains window callback.

2. In WindowCallbackWrapper.Companion add something to check if the callback is the Curtain's variant (or just invoke Window.listeners which does this refresh itself). Now the question is, when to best invoke this - perhaps from a fragment lifecycle listener via onFragmentStarted?

   fun Window.reapplyWindowCallbackWrapper(): Boolean {
     synchronized(listenersLock) {
       if (this.callback is WindowCallbackWrapper) return false
       val wrapperToApply = callbackCache[this]?.get() ?: WindowCallbackWrapper(this.callback)
       this.callback = wrapperToApply
       callbackCache[this] = WeakReference(wrapperToApply)
       return true
     }
   }

curtains.WindowsKt#getWrappedCallback currently supports unwrapping jetpack and curtains callbacks. We could add support for the AOSP WindowCallbackWrapper as well.