Status Update
Comments
ya...@google.com <ya...@google.com>
bo...@google.com <bo...@google.com>
ke...@netflix.com <ke...@netflix.com> #2
Is this specific to navigation? Or can this be reproduced with another other Composable component?
bo...@google.com <bo...@google.com> #3
It only happens inside of a NavHost. So, yes, it seems to be specific to navigation.
zh...@google.com <zh...@google.com> #4
This was caused by the fix to 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
.
sy...@syntezzz.ru <sy...@syntezzz.ru> #5
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
bo...@google.com <bo...@google.com> #6
This has been fixed internally and will be available in Navigation 2.7.0-beta01.
bo...@google.com <bo...@google.com> #7
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
ja...@google.com <ja...@google.com> #8
ki...@gmail.com <ki...@gmail.com> #9
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
}
}
ki...@gmail.com <ki...@gmail.com> #10
wh...@gmail.com <wh...@gmail.com> #11
ch...@gmail.com <ch...@gmail.com> #12
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.
ch...@gmail.com <ch...@gmail.com> #13
ch...@gmail.com <ch...@gmail.com> #14
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.
ch...@gmail.com <ch...@gmail.com> #15
Re
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.
Description
Android Studio Version: Giraffe | 2022.3.1
Emulator Version (Emulator--> Extended Controls--> Emulator Version): 32.1.14-10330179
HAXM / KVM Version: HVF 13.5.0
Android SDK Tools: 26.1.1
Host Operating System: macOS 13.5
CPU Manufacturer: Other CPU:
64-bit CPU
RAM: 16384 MB
GPU:
Build Fingerprint:
AVD Details: Name: Pixel_C_Tablet_API_33
CPU/ABI: arm64
Path: /Users/tomas/.android/avd/Pixel_C_API_33.avd
Target: google_apis [Google APIs] (API level 33)
Skin: 2560x1800
SD Card: 512 MB
AvdId: Pixel_C_Tablet_API_33
PlayStore.enabled: false
avd.ini.displayname: Pixel C Tablet API 33
avd.ini.encoding: UTF-8
disk.dataPartition.size: 6G
fastboot.chosenSnapshotFile:
fastboot.forceChosenSnapshotBoot: no
fastboot.forceColdBoot: no
fastboot.forceFastBoot: yes
hw.accelerometer: yes
hw.arc: false
hw.audioInput: yes
hw.battery: yes
hw.camera.back: virtualscene
hw.camera.front: emulated
hw.cpu.ncore: 4
hw.dPad: no
hw.device.hash2: MD5:b6f369a5174fab4bbf46015b0d842ec6
hw.device.manufacturer: Google
hw.gps: no
hw.gpu.enabled: yes
hw.gpu.mode: auto
hw.initialOrientation: landscape
hw.keyboard: yes
hw.lcd.density: 320
hw.lcd.height: 1800
hw.lcd.width: 2560
hw.mainKeys: no
hw.ramSize: 1536
hw.sdCard: yes
hw.sensors.orientation: yes
hw.sensors.proximity: yes
hw.trackBall: no
image.sysdir.1: system-images/android-33/google_apis/arm64-v8a/
runtime.network.latency: none
runtime.network.speed: full
showDeviceFrame: no
skin.dynamic: yes
skin.path.backup: /Users/tomas/Library/Android/sdk/skins/pixel_c
tag.display: Google APIs
vm.heapSize: 192
Steps to Reproduce Bug:Call PackageManager.hasSystemFeature(PackageManager.FEATURE_SENSOR_HINGE_ANGLE) and this method returns true on Pixel C tablet.
Expected Behavior:
Returns false on Pixel C tablet.
Observed Behavior: