Fixed

Bug

Status Update

No update yet.

Description

[Deleted User]

created issue #1

Apr 21, 2023 06:57PM

Versions

Component used: Navigation

Version used: 2.5.3

Devices/Android versions reproduced on: any

Description

According to the documentation of [BackHandler], nested BackHandlers(https://developer.android.com/reference/kotlin/androidx/activity/compose/package-summary#top-level-functions) should take priority:

If this is called by nested composables, if enabled, the inner most composable will consume the call to system back and invoke its lambda. The call will continue to propagate up until it finds an enabled BackHandler.

However, this doesn't work correctly if the activity is paused and then resumed.

Steps to reproduce

Start the app
Click back button
Toast "Button clicked" shows
Minimize the app (by pressing home button)
Bring app to foreground (via recent apps menu)
Click back button Expected behavior: Toast "Button clicked" shows Actual behavior: Toast "This should never ever show!!!" shows

Code to demonstrate the issue

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            MaterialTheme {
                Surface(Modifier.fillMaxSize()) {
                    val context = LocalContext.current
                    BackHandler {
                        Toast.makeText(context, "This should never ever show!!!", Toast.LENGTH_SHORT).show()
                    }
                    SampleApp()
                }
            }
        }
    }
}

@Composable
fun SampleApp() {
    val navController = rememberNavController()
    NavHost(navController, "first") {
        composable("first") { Screen() }
    }
}

@Composable
fun Screen() {
    val context = LocalContext.current
    BackHandler {
        Toast.makeText(context, "Back clicked", Toast.LENGTH_SHORT).show()
    }
    Column {
        Text("First screen")
    }
}

A sample project is attached.

MyApplication.zip

29 MB

Download

Comments

jb...@google.com <jb...@google.com> #2Apr 25, 2023 11:08PM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019

Change the way to detect mismatch between POJO and query

This fixes cursor mismatch warnings with expandProjection.

Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8

M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt

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

https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1

[Deleted User] <[Deleted User]> #3Apr 25, 2023 11:16PM

The following changes were cherrypicked through Coastguard (

https://android-build.googleplex.com/coastguard/)
Release Track: (

https://android-build.googleplex.com/coastguard/dashboard/6093116828680192/#/cherrypickHistory/all)
Created: 2019-10-14 17:23:42.610596+00:00
Changes: aosp/1123258

il...@google.com <il...@google.com> Apr 26, 2023 11:44PM

Assigned to jb...@google.com.

jb...@google.com <jb...@google.com> #4Apr 27, 2023 12:26AM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020

Re-factor how errors are dismissed when query is re-written

This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (

b/140759491

).
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.

This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.

Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f

M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt

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

ap...@google.com <ap...@google.com> #5Jun 1, 2023 12:50AM

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

commit d2c5efe67531a30fb9f1a129d52beb1e9ece0b29
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed May 31 23:09:54 2023

Integrate BackHandler into NavHost

Instead of NavHost taking over the onBackPressedDispatcher from the
Activity, we should just make it use a BackHandler. This will ensure
that it interacters with the other BackHandlers in Compose correctly.

RelNote: "`NavHost` now correctly intercepts system back calls even
after the Activity has been `STOPPED` and `RESUMED`."
Test: modified tests
Bug: 279118447

Change-Id: Icb6deab996d122487243f0d3d775af8c15fc7c25

M navigation/navigation-compose/src/androidTest/java/androidx/navigation/compose/NavHostTest.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt

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

il...@google.com <il...@google.com> #6Jun 1, 2023 05:00PM

Marked as fixed.

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

pr...@google.com <pr...@google.com> #7Jun 8, 2023 01:31AM

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

an...@daresay.co <an...@daresay.co> #8Jun 26, 2023 12:35PM

Comment has been deleted.

Message last modified on Jun 26, 2023 12:35PM

li...@gmail.com <li...@gmail.com> #9Jun 26, 2023 12:38PM

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
        }
    }

Message last modified on Jun 26, 2023 12:40PM

ho...@gmail.com <ho...@gmail.com> #10Jul 17, 2023 01:51PM

Comment has been deleted.

Message last modified on Jul 17, 2023 03:43PM

ho...@gmail.com <ho...@gmail.com> #11Jul 17, 2023 02:31PM

Comment has been deleted.

Message last modified on Jul 17, 2023 03:43PM

ho...@gmail.com <ho...@gmail.com> #12Jul 18, 2023 12:10PM

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.

Message last modified on Jul 18, 2023 03:45PM

gi...@gmail.com <gi...@gmail.com> #13Sep 22, 2023 12:43PM

I can confirm this is still happening as mentioned in <li...@gmail.com> #9

va...@zedge.net <va...@zedge.net> #14Oct 11, 2023 02:25PM

Still reproduces.
In my case it works fine when the app is first ran, but my custom callback calls navController.popBackStack internally if it can't handle back press on its own. So, when I run the app and click back, everything works, but after I pop up all the Composables from the stack and return to the app, the custom callback is not called anymore.

il...@google.com <il...@google.com> #15Oct 11, 2023 04:45PM

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.

ja...@gopuff.com <ja...@gopuff.com> #16Oct 30, 2023 07:13PM

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.

ja...@sense.com <ja...@sense.com> #17Nov 14, 2024 05:36PM

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

IssueTracker

BackHandler not working correctly after activity resumes after being paused

Status Update

Description

Versions

Description

Steps to reproduce

Code to demonstrate the issue

Comments

jb...@google.com <jb...@google.com> #2Apr 25, 2023 11:08PM

[Deleted User] <[Deleted User]> #3Apr 25, 2023 11:16PM

il...@google.com <il...@google.com> Apr 26, 2023 11:44PM

jb...@google.com <jb...@google.com> #4Apr 27, 2023 12:26AM

ap...@google.com <ap...@google.com> #5Jun 1, 2023 12:50AM

il...@google.com <il...@google.com> #6Jun 1, 2023 05:00PM

pr...@google.com <pr...@google.com> #7Jun 8, 2023 01:31AM

an...@daresay.co <an...@daresay.co> #8Jun 26, 2023 12:35PM

li...@gmail.com <li...@gmail.com> #9Jun 26, 2023 12:38PM

ho...@gmail.com <ho...@gmail.com> #10Jul 17, 2023 01:51PM

ho...@gmail.com <ho...@gmail.com> #11Jul 17, 2023 02:31PM

ho...@gmail.com <ho...@gmail.com> #12Jul 18, 2023 12:10PM

gi...@gmail.com <gi...@gmail.com> #13Sep 22, 2023 12:43PM

va...@zedge.net <va...@zedge.net> #14Oct 11, 2023 02:25PM

il...@google.com <il...@google.com> #15Oct 11, 2023 04:45PM

ja...@gopuff.com <ja...@gopuff.com> #16Oct 30, 2023 07:13PM

ja...@sense.com <ja...@sense.com> #17Nov 14, 2024 05:36PM

Issue 279118447

Description

Versions

Description

Steps to reproduce

Code to demonstrate the issue

Issue summary

Comments

jb...@google.com <jb...@google.com> #2Apr 25, 2023 11:08PM

[Deleted User] <[Deleted User]> #3Apr 25, 2023 11:16PM

il...@google.com <il...@google.com> Apr 26, 2023 11:44PM

jb...@google.com <jb...@google.com> #4Apr 27, 2023 12:26AM

ap...@google.com <ap...@google.com> #5Jun 1, 2023 12:50AM

il...@google.com <il...@google.com> #6Jun 1, 2023 05:00PM

pr...@google.com <pr...@google.com> #7Jun 8, 2023 01:31AM

an...@daresay.co <an...@daresay.co> #8Jun 26, 2023 12:35PM

li...@gmail.com <li...@gmail.com> #9Jun 26, 2023 12:38PM

ho...@gmail.com <ho...@gmail.com> #10Jul 17, 2023 01:51PM

ho...@gmail.com <ho...@gmail.com> #11Jul 17, 2023 02:31PM

ho...@gmail.com <ho...@gmail.com> #12Jul 18, 2023 12:10PM

gi...@gmail.com <gi...@gmail.com> #13Sep 22, 2023 12:43PM

va...@zedge.net <va...@zedge.net> #14Oct 11, 2023 02:25PM

il...@google.com <il...@google.com> #15Oct 11, 2023 04:45PM

ja...@gopuff.com <ja...@gopuff.com> #16Oct 30, 2023 07:13PM

ja...@sense.com <ja...@sense.com> #17Nov 14, 2024 05:36PM

Add comment

Issue metadata