Fixed
Status Update
No update yet.
Comments
so...@gmail.com
Thank you for your submission. Can you provide the idea.log file from (help> show log > idea.log). Also provide the addition information like Android Studio version & OS (Android Studio menu > About) along with additional steps to replicate the issue (if any?)
This will help ensure the team can correctly triage and reproduce your issue.
If we do not get an update in the next 30 days we will close this issue.
This will help ensure the team can correctly triage and reproduce your issue.
If we do not get an update in the next 30 days we will close this issue.
so...@gmail.com
This has so far only happened on CI using AGP 3.2.0 so there are no Android Studio logs.
so...@gmail.com
Hello, is there any update on this issue?
il...@google.com
il...@google.com
ap...@google.com
Yigit: FYI compiling seems to be busted with parallel compilation?
Jerome: Anything we should be doing special for parallel compilation?
Jerome: Anything we should be doing special for parallel compilation?
il...@google.com
thats weird, jetifier fails to read its own resources. :/.
ch...@gmail.com
I presume that the parallel execution makes it to choke on the same stream (= file descriptor) when loading the config from multiple threads.
I'm looking at the usage in databinding where I can see this:
private val typeRewriter by lazy(LazyThreadSafetyMode.NONE) {
val config = ConfigParser.loadDefaultConfig()
}
I presume that LazyThreadSafetyMode.NONE might be the issue? As that might probably trigger multiple accesses to the same config file at the same time?
I'm looking at the usage in databinding where I can see this:
private val typeRewriter by lazy(LazyThreadSafetyMode.NONE) {
val config = ConfigParser.loadDefaultConfig()
}
I presume that LazyThreadSafetyMode.NONE might be the issue? As that might probably trigger multiple accesses to the same config file at the same time?
il...@google.com
we don't really do multi threading so it is lazy because we don't want to pre-allocate it until needed.
pi...@gmail.com
I don't understand what you mean by not doing multithreading. Gradle build indeed does multhithreading as you can se above on the parallel build.
pi...@gmail.com
Comment has been deleted.
Description
Version used: 1.0.0-alpha11
I'm seeing some strange behaviour when pressing back button and transistion back to a fragment from a fragment of the same id.
My app uses some generic fragment structures that are driven by args passed in, as such there are places like:
FragmentA -> FragmentB -> FragmentB -> FragmentC
However if the back button is pressed on the second instance of FragmentB, FragmentA is replaced in the navhost while the navgraph correctly displays in the toolbar. Forward navigation from this point however is missing from the navgraph and results in an IllegalStateException with the action 'not found' in the graph, unless the back button is pressed again (pushing the navgraph destination back to FragmentA)
Is this intended behaviour? If so is there a way to declare FragmentB as 'stackable'?