IssueTracker

Upvote!

If I attempt to start debugging an app before indexing is complete, I get this very peculiar error message, shown in the attachment. Keep in mind that gradle sync did not fail.

Usually, the debug button is greyed-out so I can't click it, but sometimes it's not (another bug, perhaps?) and then I can click it and get the error in question.

Please add a zipped copy of the app/.cxx folder. I mainly need the compile_commands.json file.

I've attached only the compile_commands.json file, as the CMake binary folder contains some files that could be subjected to the IP of the company I work for.

Most notably, you can see that the file never mentions neither protobuf nor emscripten, however, Android studio took a long time to index those folders in my ~/.conan/data folder, as well as many other Conan packages in that folder that are not used by the project at all.

For those of you experiencing similar issues, please also attach your repro cases or compile_commands.json so I can take a look. This is one of those issues that manifests in many ways. Sometimes it's even 'by design' depending on how your project is configured.

Still happens with Android Studio Bumblebee beta 5 on macOS. Compile Commands are attached.

Still happens on Android Studio Bumblebee 2021.1.1 Patch 2 on macOS. This makes literally unusable as I cannot start neither my app nor junit tests. The configurations panel (where I should define run configurations) says that this view is not available until indexes are built and indexing never ends because indexer ends up in infinite recursion while scanning my emscripten folder (totally unrelated to Android app - but I do have emscripten SDK installed on my computer and AS feels the urge to scan it) - emscripten internally contains infinitely recursive folders (base folder containing a symlink to itself). This totally confuses Android Studio's indexer making it never stop, consume 20 GB of RAM and make the entire system unstable.

By temporarily deleting emscripten SDK from my computer I can get Android studio to work, but this is unacceptable - I need to work on different projects in parallel, some of which require developing Android apps and other web apps using emscripten. Android Studio needs to learn its boundaries and stop scanning the entire system like some crypto-ransomware.

Here is the zipped copy of app/.cxx folder to help you further with the debugging.

Still happens with Chipmunk and AGP 7.2.0-rc02. Fortunately, I've found a workaround: it's possible to add '-DCMAKE_EXPORT_COMPILE_COMMANDS=OFF' to my build.gradle and thus prevent CMake to generate compile_command.json in the first place so Android Studio has nothing to index then.

Yes, it does mean that code navigation for c++ doesn't work, but this is still better than IDE which consumes 20 GB of RAM and is totally unresponsive.

The issue was that folders of source files were like:

/u/d/Work/Microblink/core-android/android-studio/LibRecognizer/src/main/jni/Source/Ocr /u/d/.conan/data/VersionAndPaths/2.2.0/microblink/stable/package/5ab84d6acfe1f23c4fae0

These folders unified to:

/u/d

This was made into a content root and then IJ proceeds to index it, resulting in too many files indexed.

The fix I'm proposing is to not unify two folders if they exist on two different sides of any "barrier directory" which is defined as:

• Each folder containing CMakeLists.txt.
• The folder containing build.gradle or build.gradle.kts.
• The user's home directory.
• On Windows, the root drives C:, D:, etc.

This fix is submitted now and should appear first in Iguana canary 11 or 12. The internal change number in case I need it is Idf313e8d15fedc08002d93738607c92d9aa43157.

We decided to limit the above proposal to just use the user's home directory as a forbidden folder

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Iguana | 2023.2.1 Canary 12
• Android Gradle Plugin 8.3.0-alpha12

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!