IssueTracker

Is this specific to navigation? Or can this be reproduced with another other Composable component?

It only happens inside of a NavHost. So, yes, it seems to be specific to navigation.

This was caused by the fix to b/182284739 which made BackHandler lifecycle aware. The problem here is that the NavController registers its lifecycle and added an observer to the Activity Lifecycle in composition while the BackHandler registers its observer on the Activity Lifecycle in a DisposbleEffect. This means that the NavController will always get Lifecycle callbacks before the BackHandler, so the components listening the the NavController's lifecycle (like the NavBackStackEntry) will always get their Lifecycle callbacks before the BackHandler as well.

This should be addressed by work coming in 2.7 to integrate the BackHandler into the NavHost.

This has been fixed internally and will be available in Navigation 2.7.0-beta01.

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

• androidx.navigation:navigation-compose:2.7.0-beta01

I wouldn't say this is fixed. If you add a back-callback in the activity which is lifecycle aware, and then background->foreground the app, the activity back-callback will be put on top of the callback pile. This leads to that any BackHandler in your composable will NOT be triggered.

The best workaround I have for now is to use the non-lifecycle aware function in the activity.

class MainActivity : FragmentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        
        // open fragment which hoists the composables
        ...

        if (savedInstanceState == null) {
             onBackPressedDispatcher.addCallback(onBackPressedCallback = someBackHandling())  
            // onBackPressedDispatcher.addCallback(owner = this, onBackPressedCallback = someBackHandling)  // not this one
        }
    }

https://developer.android.com/jetpack/androidx/releases/navigation#2.7.0-beta01 :

Bug Fixes : NavHost in Navigation Compose now correctly intercepts system back calls even after the Activity has been STOPPED and RESUMED.

It works fine for me.

Re comment#14 - please file a new issue with a project that reproduces your problem.

Note that you should never, ever be calling navController.popBackStack() in your own BackHandler as Navigation must be the only one handling its own back stack with the system back button so that Predictive Back works correctly in the future.

These changes broke our use case to override back handling in navigation library for closing the menu drawer. Please see more details in the issue I've reported.

I believe this is still an issue even without using NavHost like mentioned in comment #16. I filed a new issue here

Hi

I'm using MacBook Pro with Apple Silicon and macOS Ventura 13.0.1.

Steps are pretty straightforward:

1. Power adapter is plugged in. Energy mode is set to Automatic for both 'On battery' and 'On power adapter' options.
2. Run emulator.
3. Keep it running until macbook automatically goes to sleep.
4. Wake it up after ~10 minutes and observe the time in the emulator. It shows not the actual time but the time when macbook fell asleep.

I'm not sure that this happens all the time but often enough.

RE#18 Really appreciate it. I will start testing it.

#18

One more question: After step 4 Wake it up after ~10 minutes and observe the time in the emulator. It shows not the actual time but the time when macbook fell asleep., have you tried to move the emulator window? I think the time should be updated when you starting using the emulator.

I'm not sure that I've moved the emulator window but usually I install our app using Android Studio and see network errors due to time difference between the app and our servers. So it looks like the time isn't updated in this case.

RE#21 Another question, are you using the emulator in a tool window? I think it might be the specific scenario which still has bug.

I'm launching the emulator in a standalone window.

RE#24 Ok, I tried it myself and I could not reproduce unfortunately. With have you tried to move the emulator window? I think the time should be updated when you starting using the emulator. being said, would it be possible for you to try it again?

Sure, will try

Unfortunately, it happened again. Moving a window did not help.

Some additional info:

• I use a pair of external displays connected via Type-C, Bluetooth keyboard and mouse.
• Power adapter is plugged in. This way I can safely close a macbook lid and continue using it with the external displays. When macbook is sleeping I can wake it up by pressing a key on a keyboard or by clicking a mouse button.
• Today I left my workplace for 40-50 minutes. When I came back, external displays were in standby mode. After waking the macbook up, I've reproduced the issue.

RE#28 I realized what went wrong. My fix didn't merge into the 32 release. It's only available in the 31 release and the dev branch. Let me resolve that issue real quick and release a new version. Thanks for your input!

Thank you!

New CL merged. Will release a new version ASAP.

The fix is available in the next canary and stable release in June.

RE#36 To clarify, the bug is still reproducible for API 29 and API 30. Other APIs are working fine. We have an internal bug for tracking the API specific time update issue.

The new fix is merged

sivhuop@ Hi, the fix is not merge in (33.1.4-9936625). Would it be possible for you to upgrade your emulator the latest canary version or at least 33.3.14? Here is the link to the archived emualtor downloads.

RE#42 Thanks for the feedback on the emulator. To help us troubleshoot this issue further, we will need more information. Please share detailed reproduction steps as much as possible of the following information:

1, Run the emulator from command line with “$ANDROID_SDK_ROOT/emulator/emulator -avd <NameOfAVD> -verbose -wipe-data” and send the logs from terminal

2, Run adb bugreport and send the zip file.

I confirm 34.1.9 has no this issue anymore

https://developer.android.com/studio/releases/emulator#32-1-14