Fixed
Status Update
No update yet.
Comments
on...@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.
xa...@google.com
is...@google.com
ga...@google.com
This has so far only happened on CI using AGP 3.2.0 so there are no Android Studio logs.
pa...@google.com
Hello, is there any update on this issue?
pa...@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?
pa...@google.com
thats weird, jetifier fails to read its own resources. :/.
al...@google.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?
am...@google.com
we don't really do multi threading so it is lazy because we don't want to pre-allocate it until needed.
fl...@google.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.
bo...@gmail.com
We just looked into it with Hung and the solution should be to have the config file as a singleton in the LibTypes. Right now the parallel build makes it load several configs in parallel which causes that it chokes on the file stream.
fl...@google.com
I just submitted a fix for this (Change-Id: I2675640875bcae7e5f1346de8c12acb3a0379902).
The fix will be available in AGP 3.5.0-alpha05. Please try it out when it's released, and let us know if you still run into this issue.
The fix will be available in AGP 3.5.0-alpha05. Please try it out when it's released, and let us know if you still run into this issue.
al...@gmail.com
Is there any chance of this being backported to AGP 3.4 or even 3.3? This is pretty painful for our CI environment today and I'm guessing AGP 3.5 stable is still far out.
Description
Android Plugin Version: 4.0.0-alpha08
Module Compile Sdk Version: 29
Module Build Tools Version: <blank>
Android SDK Tools version: 29.0.2
I upgraded my project from AGP 4.0.0-alpha06 to 4.0.0-alpha08 and the assemble task started to report the following compilation error:
e: Supertypes of the following classes cannot be resolved. Please make sure you have the required dependencies in the classpath:
class android.support.wearable.complications.ComplicationHelperActivity, unresolved supertypes: android.support.v4.app.ActivityCompat.OnRequestPermissionsResultCallback
The error appears also in 4.0.0-alpha07.
You can find an example project to reproduce the issue at