Fixed
Status Update
Comments
[Deleted User] <[Deleted User]> #2
Could you please provide a sample project that reproduces your issue?
You are right about restoring the request codes, but under normal usage of the API, that should not cause this failure.
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #3
Unfortunately I'm unable to reproduce the issue neither in a sample nor in the real project.
These crashes are received from the users of production app. I'll try to add more logs for better understanding what users do before the crash.
jb...@google.com <jb...@google.com> #4
Project: platform/frameworks/support
Branch: androidx-master-dev
commit b2a3eca325760e3686411e619048e2bc52befda8
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Sep 16 16:55:46 2020
Ensure request code start is consistent after restore
When the ActivityResultRegistry is recreated due to either config change
or process death, the next request code is started at the number of
current request codes without including the initial offset.
We should make sure to include the initial offset on restore to remain
consistent.
Relnote: "When restoring the ActivityResultRegistry, the request codes
are now properly started from their previous value instead of the value
of the number of existing request codes."
Test: all ActivityResultRegistryTest pass
Bug: 168374000
Change-Id: I463711fe19233877f1b534e4a7a3325fcfd8f983
M activity/activity/src/main/java/androidx/activity/result/ActivityResultRegistry.java
https://android-review.googlesource.com/1428862
Branch: androidx-master-dev
commit b2a3eca325760e3686411e619048e2bc52befda8
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Sep 16 16:55:46 2020
Ensure request code start is consistent after restore
When the ActivityResultRegistry is recreated due to either config change
or process death, the next request code is started at the number of
current request codes without including the initial offset.
We should make sure to include the initial offset on restore to remain
consistent.
Relnote: "When restoring the ActivityResultRegistry, the request codes
are now properly started from their previous value instead of the value
of the number of existing request codes."
Test: all ActivityResultRegistryTest pass
Bug: 168374000
Change-Id: I463711fe19233877f1b534e4a7a3325fcfd8f983
M activity/activity/src/main/java/androidx/activity/result/ActivityResultRegistry.java
Description
Component used: Fragment Version used: 1.3.0 Devices/Android versions reproduced on: Android 10, 11
This is happen on our product code, but, sorry, I could not create sample project to reproduce this issue.
If we update fragment from 1.2.5 to 1.3.0, onResume is not called on one Fragment of our project. This is very similer to https://issuetracker.google.com/issues/177154873
Our Fragment has custom enter/exit transition. If we remove these custom transition, onResume is called as expected. But we can't do that. We need custom transition animation. The difference to above issue (177154873) may that our Fragment is "Fragment on Fragment".
We tried to call
https://medium.com/androiddevelopers/fragments-rebuilding-the-internals-61913f8bf48e
to disable new state manager.
FragmentManager.enableNewStateManager(false)
written inonResume becomes to be called !! BUT, it cause ConcurrentModificationException.
This is similar to following issues. https://issuetracker.google.com/issues/178460675
https://issuetracker.google.com/issues/152337205
But this is happen on 1.3.0.
Summary: