Fixed
Status Update
Comments
ma...@google.com <ma...@google.com> #2
It could easy to reproduce when turning on "Don't keep activities".
le...@google.com <le...@google.com>
ap...@google.com <ap...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-master-dev
commit ba0c19707915ff87d9cac2089fcd166bb5cca17d
Author: Ian Lake <ilake@google.com>
Date: Wed Nov 14 16:20:28 2018
Set the correct FragmentManager on active Fragments
All active Fragments should have the correct
FragmentManager set instead of always using the
Activity's FragmentManager.
While added Fragments have their FragmentManager
set correctly in moveToState(), active Fragments
weren't being set correctly, causing issues when
attempting to save the state of the FragmentManager.
Test: new FragmentLifecycleTest
BUG: 119256498
Change-Id: I830f729d93f00859509a0844fae19752342e6ccc
M fragment/src/androidTest/java/androidx/fragment/app/FragmentLifecycleTest.java
M fragment/src/main/java/androidx/fragment/app/FragmentManagerImpl.java
M fragment/src/main/java/androidx/fragment/app/FragmentState.java
https://android-review.googlesource.com/826954
https://goto.google.com/android-sha1/ba0c19707915ff87d9cac2089fcd166bb5cca17d
Branch: androidx-master-dev
commit ba0c19707915ff87d9cac2089fcd166bb5cca17d
Author: Ian Lake <ilake@google.com>
Date: Wed Nov 14 16:20:28 2018
Set the correct FragmentManager on active Fragments
All active Fragments should have the correct
FragmentManager set instead of always using the
Activity's FragmentManager.
While added Fragments have their FragmentManager
set correctly in moveToState(), active Fragments
weren't being set correctly, causing issues when
attempting to save the state of the FragmentManager.
Test: new FragmentLifecycleTest
BUG: 119256498
Change-Id: I830f729d93f00859509a0844fae19752342e6ccc
M fragment/src/androidTest/java/androidx/fragment/app/FragmentLifecycleTest.java
M fragment/src/main/java/androidx/fragment/app/FragmentManagerImpl.java
M fragment/src/main/java/androidx/fragment/app/FragmentState.java
Description
CAMERAX VERSION: 1.0.0-beta06 CameraView Version: 1.0.0-alpha13
ANDROID OS BUILD NUMBER: QQ3A.200605.001
DEVICE NAME: Pixel 4
DESCRIPTION:
mCameraControlInternal.setActive(true);
is called immediately upon receiving a request to attach use cases.On the other hand
mCameraControlInternal.setActive(false);
is called only once all use cases have been detached.This causes a race condition if the
CameraRepository
is set from Inactive to Active very quickly. The result of this race condition is that controls on the camera are disabled, but the camera use cases are successfully attached (ie. zoom functionality does not work).STEPS TO REPRODUCE:
I am able to reproduce this by using a custom lifecycle observer that registers the
ON_STOP
lifecycle event when media is captured and the preview is shown. Then I register theON_START
event when the media is dismissed.This is so that we do not continue to run the camera while the view finder is covered by our media preview.
OBSERVED RESULTS:
If a user captures media then dismisses it quickly enough, the race condition observed above can occur. This results in a state where the camera is functioning properly but controls are disabled.
REPRODUCIBILITY: 5 of 5
I have attached a screen shot where you can see that
tryDetachUseCases (773)
is called afterattachUseCases (648)
. The line numbers are slightly different from the Android source I link above but this is the effect I am describing,Camera2CameraControl.setActive(false)
is called afterCamera2CameraControl.setActive(true)
incorrectly.