Transitions fail to return to original state after animateToStart() and beginDelayedTransition() [300157785]

Fixed

Bug

Status Update

No update yet.

Description

jb...@google.com

created issue #1

Sep 13, 2023 12:31AM

Component used: Transition Version used: 1.5.0-alpha02 Devices/Android versions reproduced on: API 34

If you do a gesture back in Fragments using transitions and cancel the gesture multiple times, after the first cancel, starting the gesture will result in the transition on the exiting view failing to run.

I believe the cause of this is that the beginDelayedTransition() called by with a 0 duration called by Fragment never triggers this onAnimatedEnd() callback in Visibility. That results in the visibility failing to be added removed from the overlay and so the subsequent transitions on the view do not run.

Here are logs synced with the calls from Fragment and Visibility. I would expect there to be an onAnimationEnd reversed=false log before the onTransitionEnd in Visibility.

 V  Animating to start (in Fragment)
 D  onAnimationEnd reversed=true (in Visibility)
 V  Calling beginDelayedTransition (in Fragment)
 D  onTransitionEnd (in Visibility)
 V  On transitionEnd of beginDelayedTransition (in Fragment)

The can be reproduced by patching in aosp/2748867 and doing the following in the navigation-integration app:

Launch App
Press the "Navigate Next" button 2 times to get to the "two" screen
Start a gesture back to the "one" screen and cancel it
Start another gesture back to the "one" screen and the "two" screen will immediately go blank

Comments

mo...@google.com <mo...@google.com> Sep 13, 2023 04:31PM

Accepted by mo...@google.com.

mo...@google.com <mo...@google.com> #2Sep 18, 2023 08:29PM

Assigned to jb...@google.com.

This is with the latest CameraX 1.1.0-beta03.

va...@google.com <va...@google.com> #3Sep 21, 2023 06:57PM

Thanks for reporting the issue. We will look into the bug and update here soon.

va...@google.com <va...@google.com> #4Sep 21, 2023 07:08PM

We will catch this exception while clarify what is going wrong in the meantime.

Hi Shuzen
We've got this public issue from developers where querying CameraCharacteristics.CONTROL_ZOOM_RATIO_RANGE seems to cause crash on some cheap devices in India.
Is this because these cheap devices do not pass CTS ?

jb...@google.com <jb...@google.com> #5Sep 26, 2023 08:12PM

Is it possible to get a bugreport from those devices?

jb...@google.com <jb...@google.com> #6Sep 26, 2023 08:46PM

One of our project members can potentially get their hands on one of these devices but we currently don't have access to one. It's probably a lot easier for you folks to get one since we can't really afford to buy phones.

Ideally you could get some of these cheap Indian/Chinese phones for the CameraX device lab.

This Jio device is Google certified but in my experience most non-Pixel phones are pretty far from genuinely passing the CTS and have a lot of failures that aren't just flaky tests. I'm not sure how they get their devices certified but apparently there are waivers. Google doesn't do the certification but rather third parties do, and it's possible they're simply cutting corners or acting in a corrupt way. Usually there are a lot of failing CTS Camera tests. It doesn't help that a lot of those CTS Camera tests are super flaky without a high quality device and a proper testing setup with proper lightning, etc. They can still fail from flakiness even with that setup. Probably why they can so easily skip meeting these requirements, since the certification companies are used to flaky / failing tests and aren't really doing their job properly.

ap...@google.com <ap...@google.com> #7Sep 26, 2023 08:56PM

We have a project member in India who could buy one of these phones and since they're so cheap (around $80 or something) I could cover that but in general I don't really want to be buying phones we don't really need.

jb...@google.com <jb...@google.com> #8Oct 25, 2023 12:42AM

Reassigned to mo...@google.com.

Hi ,

Thanks for the informations. You are right, it's possible that the devices are not genuinely passing the CTS.
Regardless, we will fix this in CameraX. (Thanks for letting us know BTW)
We will also try to get one of these device to test if there are other issues.

Scott

AnimateToStartAlpha03.zip

108 KB

Download

mo...@google.com <mo...@google.com> Nov 8, 2023 10:21PM

Accepted by mo...@google.com.

mo...@google.com <mo...@google.com> #9Nov 9, 2023 12:14AM

This crash looks similar to the one in b/216667482. We might want to do a similar workaround here.

mo...@google.com <mo...@google.com> #10Nov 9, 2023 06:18PM

It seems there are two approaches
1) Fix it generally
2) Have a quirk for this, only enable the fix when device has this quirk.

The problem with the quirk is that it is too easy to miss some other devices that have this issue too.
Having a general fallback that works reasonably can fix the issue for all problematic devices.
(In these two cases, they are both reasonable to return false if the key access failed)

But I do think it has benefits to have a quirk so that we know exactly what workaround we handled in CameraX.

Maybe , we can have a type of quirk or workaround that we apply generally for all devices ?

WDYT?

ap...@google.com <ap...@google.com> #11Nov 10, 2023 11:27PM

Marked as fixed.

I had similar considerations while adding the try-catch code (aosp/2092403). I want to have a quirk to document the workaround we made, but it would be a little weird that the quirk should always return true on the device quirk check. I was wondering if it is possible to have another type of quirk, e.g. a function with comment in quirk format.

pr...@google.com <pr...@google.com> #12Nov 29, 2023 09:39PM

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

commit 874ef5abba7929d0110fd54392ae9d8ee91003f0
Author: mingdatsai <mingdatsai@google.com>
Date: Mon May 09 20:32:42 2022

Catch CameraCharacteristicsBaseImpl exceptions

Some devices may throw AssertionError, which is not the expected
behavior, when failed to get CameraCharacteristic. When that happens,
we catch the error and return null to workaround it.

Bug: 231701345
Test: ZoomControlTest, ZoomControlDeviceTest &
Camera2CameraControlImplDeviceTest

Change-Id: Ia248ae5580b9d4a0949f4448ccbafcedd1ba7b9b

M camera/camera-camera2/src/test/java/androidx/camera/camera2/internal/ZoomControlTest.java
M camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/ZoomControl.java
M camera/camera-camera2/src/androidTest/java/androidx/camera/camera2/internal/Camera2CameraControlImplDeviceTest.java
M camera/camera-camera2/src/androidTest/java/androidx/camera/camera2/internal/ZoomControlDeviceTest.java

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