The default NavHost animation is being applied inconsistently instead of the custom composable animation [353294030]

Fixed

Bug

Status Update

No update yet.

Description

il...@gmail.com

created issue #1

Jul 15, 2024 05:45PM

Component used: Navigation Compose

Version used: 2.8.0-beta05

Devices/Android versions reproduced on: Emulators, Pixel 8 Pro

Hello!

We occasionally encounter an issue where the NavHost randomly applies a default transition animation instead of the one specified for a particular composable/route. Please take a look at the sample project and screen recording I've attached. Even though composable<DefaultRoute> consistently defines slideInHorizontally/slideOutHorizontally transitions, you may sometimes observe a scale/fade animation instead. This bug is inconsistent and may require multiple attempts to reproduce. One observation is that this issue occurs more frequently when a new transition is requested just as the enter animation of a previous one is nearing completion.

Sample project: https://github.com/smelfungus/NavHostAnimationIssue

Screen recording: https://drive.google.com/file/d/1FPZavURTkuPmnAWJ49pFhIWvz3Qq-M7x/view?usp=sharing

Comments

jb...@google.com <jb...@google.com> #2Jul 15, 2024 09:28PM

Assigned to ti...@google.com.

A link to another sample project demonstrating that the leak only happens when using: LocationServices.FusedLocationApi.requestLocationUpdates but does not happen using a deprecated method: googleMap.setOnMyLocationChangeListener.

https://github.com/fernandospr/android-maps-userlocation

ti...@google.com <ti...@google.com> #3Jul 22, 2024 10:30PM

Hello, I'm also experiencing the memory leak in my activity responsible for the location service.

The implementation of my project is not different from the example project attached by fernando.

il...@gmail.com <il...@gmail.com> #4Jul 23, 2024 01:47AM

FYI this memory leak also seems to exist when using the new FusedLocationProviderClient. I took Fernano's sample from

comment #2

and hacked it up to use the FusedLocationProviderClient and was still able to observe the leak upon exiting the activity.

ti...@google.com <ti...@google.com> #5Jul 24, 2024 09:00PM

Reassigned to jb...@google.com.

Leak still present in 2019 on latest play-services-location 16.0.0. 3+ years since first reported via linked Github issue, no fix or hint of acknowledgment. Clown college grade software engineering.

ti...@google.com <ti...@google.com> #6Jul 24, 2024 09:08PM

I am also still experiencing this!

al...@gmail.com <al...@gmail.com> #7Aug 19, 2024 12:01PM

Still present in 'com.google.android.gms:play-services-location:17.0.0'

As an alternative I am using FusedLocationProviderClient with PendingIntent:

IntentFilter intentFilter = new IntentFilter(ACTION_LOCATION);
registerReceiver(locationReceiver, intentFilter);
mFusedLocationClient.requestLocationUpdates(mLocationRequest, locationPendingIntent);
and
unregisterReceiver(locationReceiver);
mFusedLocationClient.removeLocationUpdates(locationPendingIntent)

Here is forked LocationUpdates repo with LeakCanary installed and an option to switch between LocationCallback and PendingIntent. LeakCanary not reporting anything when using PendingIntent.

https://github.com/dejandobnikar/location-samples/tree/master/LocationUpdates

ho...@gmail.com <ho...@gmail.com> #8Oct 15, 2024 03:51PM

Thank you for your feedback. We assure you that we are doing our best to address all issues reported. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with the bug report here

https://goo.gl/TbMiIO and reference this bug for context.

es...@gmail.com <es...@gmail.com> #9Nov 11, 2024 12:18AM

Comment #8

, the one thing that would matter to address is how to *actually* get this issue fixed. It appears pointless to file a new issue, and unclear where to do so, as this issue has not received attention from Google's side throughout the years despite quite a few people starring it and bug reports in different places. The continued existence of the bug was confirmed not long ago in prior comments by different people. I've just confirmed it again myself on R Beta 3.

pr...@gmail.com <pr...@gmail.com> #10Nov 12, 2024 05:42PM

According to some Google DevRel it might soon be fixed, see the answer (from 8 days ago) here:

https://github.com/googlecodelabs/while-in-use-location/issues/7

al...@gmail.com <al...@gmail.com> #11Nov 12, 2024 05:52PM

This issue still exists, how can this be prioritized?

cl...@gmail.com <cl...@gmail.com> #12Dec 3, 2024 08:27PM

There is an issuetracker Component available these days for Play Services Location: https://issuetracker.google.com/components/1065160

Maybe move this issue to that Component to track it better?

ap...@google.com <ap...@google.com> #13Dec 6, 2024 12:40AM

I can't move it right now, but I think it's ok to stay here.

As I wrote in the code lab issue, I misunderstood when the rewrite went out (which should fix the issue).

It goes live in version 20 (current version location 19.0.1). The engineer who wrote the rewrite checked and wasn't seeing the same issue, i.e., it should be resolved.

However, that does mean we have to wait until 20 is released. I can check in again here when it's live for you to double check.

ap...@google.com <ap...@google.com> #14Dec 6, 2024 07:50PM

8 ram

jb...@google.com <jb...@google.com> #15Dec 6, 2024 09:54PM

Marked as fixed.

I haven't been on location in awhile, but I wanted to follow up on this.

The issue should be resolved with the play-services-location:20.0.0 release from my understanding.

pr...@google.com <pr...@google.com> #16Dec 11, 2024 06:27PM

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

androidx.navigation:navigation-compose:2.8.5

cl...@gmail.com <cl...@gmail.com> #17Dec 11, 2024 06:43PM

Seems solid on my end

na...@google.com <na...@google.com> #18Jan 29, 2025 06:11PM