Fixed
Status Update
Comments
uc...@google.com <uc...@google.com> #2
Can you try File>Invalidate caches and restart android studio
mi...@gmail.com <mi...@gmail.com> #3
Tested, and it didn't help.
Try yourself, delete some referenced cache folder.
While file in .idea/libraries references nonexisting folder, build fails.
And .idea/libraries can be fully reconstructed in project sync phase, so why not simply delete it when invalidating cache, or even better validate libraries cache paths and recover gracefully.
Try yourself, delete some referenced cache folder.
While file in .idea/libraries references nonexisting folder, build fails.
And .idea/libraries can be fully reconstructed in project sync phase, so why not simply delete it when invalidating cache, or even better validate libraries cache paths and recover gracefully.
uc...@google.com <uc...@google.com>
al...@google.com <al...@google.com>
ch...@google.com <ch...@google.com> #4
I think there are three parts of this problem.
1. AARs are exploded to different locations when previous cache are cleared.
2. IDE doesn't refresh the file system when there're new files in the cache.
3. "Invalidate caches" action doesn't reset the files in .idea/libraries.
I can fix problem 2 and 3 from IDE side.
But problem 1 looks wired to me, since the same AAR is always exploded to the same location on my machine (Linux). Add Hung to take a look at problem 1.
1. AARs are exploded to different locations when previous cache are cleared.
2. IDE doesn't refresh the file system when there're new files in the cache.
3. "Invalidate caches" action doesn't reset the files in .idea/libraries.
I can fix problem 2 and 3 from IDE side.
But problem 1 looks wired to me, since the same AAR is always exploded to the same location on my machine (Linux). Add Hung to take a look at problem 1.
hu...@google.com <hu...@google.com> #5
Regarding problem 1, AARs are exploded to a different location corresponding to the versions of the Android Gradle plugin and Gradle. If one of these versions changes, then the location will change. This is to guarantee the correctness of the contents and is controlled by Gradle, so I don't think we need to fix anything there.
I can reproduce the problem with these steps:
- In Project View, External Libraries, find the location of an aar (e.g., appcompat-v7).
- Delete that directory (e.g., .gradle/caches/transforms-1/files-1.1/appcompat-v7-26.1.0.aar/hash). There may be several other directories next to the deleted directory but as said above, they can be ignored.
- Notice that the IDE automatically detects deleted files in a few seconds, and imports to the AAR classes will be unresolved (red).
- Clicking Sync will bring back the exploded-aar files to the same exact previous location (given that the versions of the Android Gradle plugin and Gradle must stay the same). However, the imports are still red.
- Click File > Synchronize and everything will be back to normal.
It looks like the last two steps can be automated if we can hook onto the event that the IDE detects file changes.
@Michal Bačík: Please let us know if the above steps match with what you encounter and suggest fixing.
I can reproduce the problem with these steps:
- In Project View, External Libraries, find the location of an aar (e.g., appcompat-v7).
- Delete that directory (e.g., .gradle/caches/transforms-1/files-1.1/appcompat-v7-26.1.0.aar/hash). There may be several other directories next to the deleted directory but as said above, they can be ignored.
- Notice that the IDE automatically detects deleted files in a few seconds, and imports to the AAR classes will be unresolved (red).
- Clicking Sync will bring back the exploded-aar files to the same exact previous location (given that the versions of the Android Gradle plugin and Gradle must stay the same). However, the imports are still red.
- Click File > Synchronize and everything will be back to normal.
It looks like the last two steps can be automated if we can hook onto the event that the IDE detects file changes.
@Michal Bačík: Please let us know if the above steps match with what you encounter and suggest fixing.
mi...@gmail.com <mi...@gmail.com> #6
I can't repeat your last two steps, because it's unclear on which Sync to click. I tried to synchronize build.gradle, source file, entire project, Sync project with Gradle files, but nothing helped to recover from the failure. Imports remain in red, cached folder is not recreated, .idea/libraries/file.xml still points to nonexisting cache folder.
hu...@google.com <hu...@google.com> #7
By "Sync", I mean "Sync project with Gradle files", so you performed the right step.
I realized that I was experimenting with Android Studio and Android Gradle plugin 3.0.1 so the behavior and the menu text might be slightly different (e.g., "File > Synchronize" in 3.0.1 is actually "Sync with file system" in 3.1.0-rc01).
I tried again with 3.1.0-rc01 and found that step 4 above (Clicking "Sync project with Gradle files") is still required but step 5 ("Sync with file system") is *sometimes* optional. Sometimes "Sync with file system" is done automatically together with a Gradle sync, but when it doesn't, I need to click around in Android Studio to trigger it, or click "File > Sync with file system" manually). After that, things will come back to normal.
Note that the above behavior is for a brand new project.
I suspect the bug occurs because you upgrade your project from an older version of Android Studio/Android Gradle plugin/Gradle, then delete the AAR contents that were extracted by that earlier version. The newer version extracts the AAR contents to a different location but fails to correct the file paths in .idea/library/*.xml files.
Here are the simplified steps to reproduce this bug:
- Create a brand new project with Android Studio/Android Gradle plugin 3.1.0-rc01.
- Go to .idea/library/Gradle__com_android_support_appcompat_v7_27_1_0.xml, rename "appcompat-v7-27.1.0.aar" to "foo.aar" (or rename anything on the path, just to make it point to a non-existent file).
- Click File > Sync project with Gradle files. Observe that the incorrect file paths are not corrected.
- Delete the .xml file and sync again twice. Now the file will be recreated correctly. Note that we need to click Gradle sync twice (and this is probably another bug).
Also note that this behavior is a regression from 3.0.1. In 3.0.1, at step 3 above, if I click "Sync project with Gradle files" twice, then the file paths will be corrected (even though I still need to click Sync twice).
@Michal Bačík: Again, please let us know if you observe anything differently. We need to make sure we understand your use case first before fixing the issue. Thanks!
I realized that I was experimenting with Android Studio and Android Gradle plugin 3.0.1 so the behavior and the menu text might be slightly different (e.g., "File > Synchronize" in 3.0.1 is actually "Sync with file system" in 3.1.0-rc01).
I tried again with 3.1.0-rc01 and found that step 4 above (Clicking "Sync project with Gradle files") is still required but step 5 ("Sync with file system") is *sometimes* optional. Sometimes "Sync with file system" is done automatically together with a Gradle sync, but when it doesn't, I need to click around in Android Studio to trigger it, or click "File > Sync with file system" manually). After that, things will come back to normal.
Note that the above behavior is for a brand new project.
I suspect the bug occurs because you upgrade your project from an older version of Android Studio/Android Gradle plugin/Gradle, then delete the AAR contents that were extracted by that earlier version. The newer version extracts the AAR contents to a different location but fails to correct the file paths in .idea/library/*.xml files.
Here are the simplified steps to reproduce this bug:
- Create a brand new project with Android Studio/Android Gradle plugin 3.1.0-rc01.
- Go to .idea/library/Gradle__com_android_support_appcompat_v7_27_1_0.xml, rename "appcompat-v7-27.1.0.aar" to "foo.aar" (or rename anything on the path, just to make it point to a non-existent file).
- Click File > Sync project with Gradle files. Observe that the incorrect file paths are not corrected.
- Delete the .xml file and sync again twice. Now the file will be recreated correctly. Note that we need to click Gradle sync twice (and this is probably another bug).
Also note that this behavior is a regression from 3.0.1. In 3.0.1, at step 3 above, if I click "Sync project with Gradle files" twice, then the file paths will be corrected (even though I still need to click Sync twice).
@Michal Bačík: Again, please let us know if you observe anything differently. We need to make sure we understand your use case first before fixing the issue. Thanks!
ch...@google.com <ch...@google.com> #8
This problem will be fixed in Studio 3.2 - .idea/libraries folder will be removed by "Invalidate Caches" action.
Please try the next canary release of 3.2 when it's out.
Thanks again for the report!
Please try the next canary release of 3.2 when it's out.
Thanks again for the report!
Description
AI-173.4559767, JRE 1.8.0_152-release-1024-b02x64 JetBrains s.r.o, OS Windows 10(amd64) v10.0 , screens 2560x1440
Gradle plugin self creates library metadata under .idea/libraries/
But it can get itself to self-corrupted state from which it can't recover.
Here is how:
A library dependence is set in build.gradle:
dependencies{
implementation 'com.google.android.gms:play-services-location:11.8.0'
}
Studio makes file .idea/libraries/Gradle__com_google_android_gms_play_services_location_11_8_0.xml
pointing to cached library in .gradle/caches/transforms-1/files-1.1/play-services-location-11.8.0.aar/<uuid>/...
So far good. The <uuid> matches.
Now somehow something deleted cached folder .gradle/caches/transforms-1/files-1.1/play-services-location-11.8.0.aar/<uuid> (deleting cache should be recoverable right...), and Studio downloaded new cached version under different uuid.
Now problem: Studio still keeps old information in .idea/libraries/Gradle__com_google_android_gms_play_services_location_11_8_0.xml pointing to nonexisting cache folder, and no matter what I do (clean project, rebuild, restart), it doesn't notice the nonexisting cache folder, and keeps referencing it. Result is build failure as import com.google.android.gms.location.LocationServices doesn't find anything.
You can simulate this by deleting cached folder .gradle/caches/transforms-1/files-1.1/play-services-location-11.8.0.aar/<uuid> and restart Studio, you should see the problem.
I can recover only by deleting .idea/libraries/Gradle__com_google_android_gms_play_services_location_11_8_0.xml (or better entire .idea/libraries) and reloading project, in such case new correct Gradle__com_google_android_gms_play_services_location_11_8_0.xml file is created.
It's super-confusing to encounter similar failures, not knowing why build fails when it worked a while ago. Please fix.