kotlin android.os.Handler removeCallbacks Runnable [376498180]

Fixed

Bug

Status Update

No update yet.

Description

al...@gmail.com

created issue #1

Oct 31, 2024 06:24AM

kotlin always let ()->Unit as Runnable. But android Handler cannot removeCallbacks. Ex:

    private val connectRunnable:()->Unit = {
        //xxxx
    }

    fun test() {
        handler.postDelayed(connectRunnable, 100)
        handler.removeCallbacks(connectRunnable)
    }

Above code will be compiled into:

   public final void test() {
      Function0 var1 = this.connectRunnable;
      this.handler.postDelayed(A::test$lambda$0, 100L);
      var1 = this.connectRunnable;
      this.handler.removeCallbacks(A::test$lambda$1); //diff from postDelay
   }

   private static final void test$lambda$0(Function0 $tmp0) {
      Intrinsics.checkNotNullParameter($tmp0, "$tmp0");
      $tmp0.invoke();
   }

   private static final void test$lambda$1(Function0 $tmp0) {
      Intrinsics.checkNotNullParameter($tmp0, "$tmp0");
      $tmp0.invoke();
   }

The ()->Unit function has be wrapped by diff lambda, it's not same one. So, the android Handler can't removeCallback.

We have to replace with Runnable statement.

Could you please add some warning message just like SharedPreferences' commit() to removeCallback when using kotlin?

deleted

Restricted

0 B

deleted

Restricted

0 B

Comments

gg...@google.com <gg...@google.com> #2Oct 31, 2024 11:23PM

Assigned to vi...@google.com.

Note: I know alpha-02 has a fix for a biometric related leak: https://android-review.googlesource.com/c/platform/frameworks/support/+/1382564/

However that change did not fix the leak reported here, as BiometricViewModel is still tied to the activity lifecycle no matter what and will hold the clientCallback reference until the activity is destroyed.

vi...@google.com <vi...@google.com> #3Nov 10, 2024 06:57AM

Any news/possible for this issue?

al...@gmail.com <al...@gmail.com> #4Nov 11, 2024 02:39AM

Can confirm that it still happens in 1.1.0-beta01

ra...@google.com <ra...@google.com> Nov 13, 2024 11:46PM

Reassigned to an...@google.com.

pa...@google.com <pa...@google.com> Nov 14, 2024 01:23PM

Status: New

tn...@google.com <tn...@google.com> #5Nov 19, 2024 12:58AM

Marked as fixed, reassigned to tn...@google.com.

Project: platform/frameworks/support
Branch: androidx-main

commit fcbbd9368d75b736de4b92d067be84421376b294
Author: Curtis Belmonte <curtislb@google.com>
Date: Wed Jan 20 15:54:34 2021

Reset BiometricViewModel callback in Fragment#onDestroy()

Currently, the client callback reference held by BiometricViewModel is
retained for the lifecycle of the hosting activity. In the (likely) case
that a client is using a fragment within that activity to host
BiometricPrompt and passes an AuthenticationCallback with a reference to
that fragment, this will cause the fragment to leak.

This commit applies a minimal fix for the issue by resetting the
callback reference held by the view model when the host fragment is
destroyed (via a LifecycleObserver). This shouldn't affect the prompt's
behavior across configuration changes such as device rotation, since the
callback should be reinitialized by the client in onCreate() or similar.

Test: Biometric integration test app on API 27-30.
Test: ./gradlew biometric:biometric:test
Test: ./gradlew biometric:biometric:connectedAndroidTest
Test: ./gradlew biometric:integration-tests:testapp:connectedAndroidTest

Bug: 167014923
Change-Id: I7086460fac3921a490f4e2abf0671adec5c146bd

M biometric/biometric/src/main/java/androidx/biometric/BiometricPrompt.java
M biometric/biometric/src/main/java/androidx/biometric/BiometricViewModel.java

https://android-review.googlesource.com/1555701

an...@google.com <an...@google.com> #6Nov 22, 2024 12:04AM

I don't use Fragments and use a View-based solutions instead. I create prompt like this:

BiometricPrompt(requireActivity, myAuthCallback)

So it is tied to the activity and it still leaks my view-based screens (1.2.0-alpha02). Ideally there would be a way to reset this callback. Latest commit fixes this leak only for Fragments (sadly).

Is there any workaround maybe? Dirty (but working) ones would do too ;)