Status Update
No update yet.
Comments
il...@google.com
Branch: androidx-main
commit 16c5a4617aa5d0709ffe27cef015e001b31de79b
Author: George Mount <mount@google.com>
Date: Mon Apr 10 13:31:49 2023
Fix leak from ReportFullyDrawnExecutor
Fixes: 277434271
The runnable was not being removed immediately after the activity
was destroyed. This removes it when it becomes destroyed so that
it can be collected without delay.
Test: new test, exemplar test
Change-Id: Id2ff2311e16d89fc7309a6e99f302cf3e8d9d595
M activity/activity/src/androidTest/java/androidx/activity/ComponentActivityReportFullyDrawnTest.kt
M activity/activity/src/main/java/androidx/activity/ComponentActivity.java
ru...@gmail.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.activity:activity:1.7.1
ru...@gmail.com
ru...@gmail.com
il...@google.com
ap...@google.com
Branch: androidx-main
commit ffe68e0a3be1da83217fadd4e40c5abad4f72b82
Author: Ian Lake <ilake@google.com>
Date: Tue Apr 06 12:40:35 2021
Use FragmentOnAttachListener in DialogFragmentNavigator
Rather than having the NavHostFragment
explicitly look for the DialogFragmentNavigator
to forward the fragment attach callback,
have DialogFragmentNavigator use the
Fragment 1.3 FragmentOnAttachListener API
to fully contain that logic within the
DialogFragmentNavigator.
Relnote: "`NavHostFragment` now supports custom
Navigators that use the same `@Navigator.Name(\"dialog\")`
as the default `DialogFragmentNavigator`."
Test: existing tests still pass
BUG: 175979140
Change-Id: Ib1c2cc38e7a621d133be1f4c3692e62913450dda
M navigation/navigation-fragment/api/public_plus_experimental_current.txt
M navigation/navigation-fragment/src/main/java/androidx/navigation/fragment/DialogFragmentNavigator.kt
M navigation/navigation-fragment/src/main/java/androidx/navigation/fragment/NavHostFragment.kt
il...@google.com
In the upcoming Navigation 2.4.0-alpha01, we've updated our Fragment dependency such that we can use the 1.3.0FragmentOnAttachListener to handle the case where previously the NavHostFragment needed to be involved. Thus, NavHostFragment no longer needs to cast the Navigator returned by the dialog name to DialogNavigator.
As a workaround, your custom Navigator can use any name other than dialog (say, singleDialog) and it'll work just fine if you use that instead of dialog.
ru...@gmail.com
Thank you for fixing this. Would singleDialog have to be also used in the navigation resources files? I didn't know we could create custom navigation targets with different names outside of dialog, fragment and activity
il...@google.com
The default DialogFragmentNavigator, FragmentNavigator, and ActivityNavigator use the exact same @Navigator.Name API as is available to every custom Navigator (there's no special casing on the Navigation library side), so yes, it can also be used from XML.
Description
Version used: 2.3.2
Caused by:
- NavHostFragment looks up a DialogFragmentNavigator in "onAttachFragment" and no null check is done
- A custom Dialog fragment navigator can't extend from DialogFragmentNavigator as it's a final class
Commit that introduced this:
Can the new API be used instead to fix this issue in the next alpha/beta release?
In alternative, do you suggest other workaround or should we wait and stay in 2.3.1 until this is fixed?