IssueTracker

This happens when fragments use animation whereby it doesn't wait for animations to complete and moves directly to RESUMED state.

The entry's listener to Fragment state does not get attached because it was attaching only if Fragment was in CREATED / STARTED state.

This has been fixed internally and will be available in navigation 2.6.0-alpha07

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.navigation:navigation-fragment:2.6.0-alpha07

NavBackStackEntry is still not triggering RESUMED on androidx.navigation:navigation-fragment:2.6.0-alpha09 in certain cases, where after a locale or uiMode change with

AppCompatDelegate.setApplicationLocales
AppCompatDelegate.setDefaultNightMode

Issue can be reproduced with attaching LifecycleObserver to the currentBackStackEntry of a Home fragment like so:

       findNavController().currentBackStackEntry?.lifecycle?.let {
            if (it.currentState.isAtLeast(Lifecycle.State.RESUMED)) {
                Timber.d(Constants.LOG_INFO, "lifecycle.currentState", "resumed")
            } else {
                val testLifecycleObserver = object : DefaultLifecycleObserver {
                    override fun onResume(owner: LifecycleOwner) {
                        Timber.d(Constants.LOG_INFO, "lifecycle.currentState", "onResumed")
                        it.removeObserver(this)
                    }
                }
                it.addObserver(testLifecycleObserver)
            }
        }

After performing a config change as mentioned above on a Settings fragment, upon performing a popBackStack/navigateUp to Home fragment, the DefaultLifecycleObserver's onResume will not be triggered. Issue does not occur if a config change is not performed.

I believe this was actually addressed as part of the Navigation 2.6.0-beta01 release. Can you try that out and see if you can still reproduce?

Project: r8
Branch: 8.9
Author: Rico Wind <ricow@google.com>
Link:      https://r8-review.googlesource.com/103286

Fix index for feature split dex code in legacy resource shrinking

Fix index for feature split dex code in legacy resource shrinking 
 
This would always be zero, causing us to only trace the dex code for the 
last feature split entry in legacy mode. 
 
Add regression test for both optimized(already passing) and 
legacy(failing without the fix here). 
 
Bug: b/404745556 
Change-Id: Ia7f0e149a1c0d0c556f1c8bee7c3968fc0649cce

Project: r8
Branch: 8.10
Author: Rico Wind <ricow@google.com>
Link:      https://r8-review.googlesource.com/103285

Fix index for feature split dex code in legacy resource shrinking

Fix index for feature split dex code in legacy resource shrinking 
 
This would always be zero, causing us to only trace the dex code for the 
last feature split entry in legacy mode. 
 
Add regression test for both optimized(already passing) and 
legacy(failing without the fix here). 
 
Bug: b/404745556 
Change-Id: Ia7f0e149a1c0d0c556f1c8bee7c3968fc0649cce

updating to r8 version 8.9.35 should solve this for you (or 8.10.21)

The fix appears to be working using the newly released tag 8.9.35. One confusing thing is that the resources are still tagged as reachable=false in the r8 resources.txt output. Is that per spec?

@com.squareup.cash.beta.debug.app:id/local_views_local : reachable=false @com.squareup.cash.beta.debug.feature:string/local_views_local : reachable=false

I added explicit log testing of multi feature case here:

https://r8-review.git.corp.google.com/c/r8/+/103380

but that does not show any issues. Is it possible for you to share a compiledumpe (https://r8.googlesource.com/r8/+/refs/heads/main/doc/compilerdump.md) or another repro of this, if not publicly then with ricow@google.com

Project: r8
Branch: main
Author: Rico Wind <ricow@google.com>
Link:      https://r8-review.googlesource.com/103380

Add resource shrinker log testing for multiple features

Add resource shrinker log testing for multiple features 
 
Add utility class for testing the log output. 
 
This does not show any issues, but based on b/404745556 we might have 
issues here in more complicated cases. 
 
Bug: b/404745556 
Change-Id: I883629a33ccf7aa649bae1c8fdbe2688547f3456

Ok, I tested again this morning with 8.9.35 on both our app and on the attached repo and the fix is working correctly. Very sorry for the false alarm, I made a mistake in my initial testing which led us to believe there might be another issue since the resources were still marked as unreachable but everything is working as expected now. Thanks again for the quick fix. I saw AGP 8.9.1 was just release yesterday, would this fix qualify for a 8.9.2 release?

re #15 I have already made a patch for AGP 8.9, so if a 8.9.2 is cut it should hopefully make that.

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Meerkat Feature Drop | 2024.3.2 RC 1
• Android Gradle Plugin 8.10.0-rc01

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

We are also hitting this exception in our dynamic features. Would be great if there was an 8.9.2 release, in case there are other changes/issues with 8.10 we need to account for.

As mentioned in comment #16 this fix has been checked into the 8.9 branch. If a 8.9.2 version is released it will be mentioned on this issue with a comment like comment #17. Until that please update R8 separately to 8.9.35 or higher as described in Replacing R8 in Android Gradle plugin.

re #19 Let me also just mention that you can set android.r8.integratedResourceShrinking false in your settings until you can upgrade to either 8.9.2 or 8.10 stable

This should not have any effect on the output size (it should give you the same) - this flag will eventually be removed though