IssueTracker

Project: platform/frameworks/support
Branch: androidx-main

commit cd77b4bbe312dd8892dfbb3c662344d13a96c82d
Author: Julia McClellan <juliamcclellan@google.com>
Date:   Thu Apr 14 15:31:46 2022

    Deep link in activity destination in navigation lint
   
    Test: Included tests of API version and the lint rule
    Bug: 178403185
   
    Change-Id: Ic15a5ec165620b7ef5b3f03538cc83b5576add8d

A       navigation/navigation-runtime-lint/src/main/java/androidx/navigation/runtime/lint/DeepLinkInActivityDestinationDetector.kt
A       navigation/navigation-runtime-lint/src/test/java/androidx/navigation/runtime/lint/ApiLintVersionsTest.kt
M       settings.gradle
A       navigation/navigation-runtime-lint/build.gradle
M       navigation/navigation-runtime/build.gradle
A       navigation/navigation-runtime-lint/src/main/java/androidx/navigation/runtime/lint/NavigationRuntimeIssueRegistry.kt
A       navigation/navigation-runtime-lint/src/test/java/androidx/navigation/runtime/lint/DeepLinkInActivityDestinationDetectorTest.kt
A       navigation/navigation-runtime-lint/src/main/resources/META-INF/services/com.android.tools.lint.client.api.IssueRegistry

https://android-review.googlesource.com/2064176

Any chance someone has a repro project they can share?
@brigham, are you saying deleting those folders help with your issue?

@tianyu, just a heads up, this may be related to the configuration cache issue you've been looking at.

I am facing the exact same issues here. I have two projects where I build native code outside of Android Studio (Cygwin shell + ndk-build.cmd) and that goes fine in AS 3.3. But one project where I use externalNativeBuild in the gradle file has the same issues as described here. The native library part is not that big (couple of .cpp and ..h files). It is like it is scanning the entire NDK. Switching back to AS 3.2 solves it.

Update: if I use Process Monitor I can see it scan my entire disk: studio64.exe accesses even my Pictures folder!

Thanks Jomo and everyone. We recently identified a bug that could be related to this.

Hi Davy, can you share the directory structure of your project. Where is the NDK located with respect to the project? Also where are your cpp files with respect to the rest of the project files?

On my end, the files built into the native library are outside the project tree seen by Android Studio (they're accessed in the CMakeList file with eg. ../../../../folder/file.cpp). It sounds like this may trigger the issue

@Emmanuel, do you have only sources outside of the project tree or also CMakeLists.txt?

Only the sources; CMakeLists.txt is under "app" in the tree that is seen by Android Studio

Thanks for looking into this btw, much appreciated!

Common factor here seems to be that cpp files are located out of android studio/gradle directory structure.

In our case, we use separate android module/library to build cpp files. That module is not a subdirectory of the root project, but located ../../xxx/yyy location. cpp files that this module builds, are also located in multiple levels down from module root level. eg ../../xx/yy.  

I think there is a bug somewhere where it resolves the paths. I'm quite sure that it would work if I create enough empty dummy directories before android studio directory, so that it would not leak out from there, or a separate empty disk image for project :)

This "scanning files bug" has been there also in 3.3 preview. I reported that here https://issuetracker.google.com/issues/112927150 on August 2018.

@tg
The NDK is in a subfolder of F:\Android
CPP files are in subfolders of the project's src/main/jni folder (F:\Development\AS\USBTester\USBTester\src\main\jni)

I have a zip file with a project I can send to you if you contact me privately.

Thanks Davy, I'm emailing you privately

Same situation and same problem with 3.3: we've got cpp files outside of (C:\programs\projectName\src) our Android Studio project structure (C:\programs\projectName\build\android).  Android Studio indexes the entire drive and runs out of memory while "loading symbols" and crashes.

In the app.iml file, it looks like Android Studio has added C:\ as a sources root.  Manually changing that to C:\programs\projectName and restarting Android Studio causes the first round of indexing to complete quickly and behave normally for a few seconds, after which it overwrites the file almost immediately with the same C:\ sources root again, after which it enters the same indexing loop forever.

Hi Nicholas, do you use cmake or ndk-build for your native code? Can you provide more information on the structure of your project? Specifically how are the cpp files referenced? Thank you!

We use ndk-build.  This is on a Windows 8.1 machine.  Here are the (lightly sanitized) gradle and mk files: https://www.dropbox.com/s/wl826flzufuzldq/androidBuild.zip?dl=0  Importing those from scratch caused the same problem several times in a row.

There are a couple absolute paths in there.  I worried that might have been causing the "C:\" sources root, but even making them relative paths (and importing from scratch again) didn't fix it.

Same here, but on macOS High Sierra, Android Gradle Plugin 3.3.0, Gradle: 4.10.1, NDK 18.1.5063045, using ndk-build.

Scanning files to index was taking hours, so I left it overnight. In the morning I find the Android Studio process had read 185.35 GB from the disk and is now asking for more RAM. It either tries to read my whole disk (which is about 400 GB), or reads the same data over and over again. I'm not going to give this thing more RAM to do more of what it does now.

I never imagined that it can get any worse than Android Studio 3.2, but 3.3 is plain unusable.

I tried to create 5 levels of empty directories before the actual project directory, but it did not help. Still stuck on scanning files.

But, I discovered that creating a disk image (MacOS with Diskutility), copied project there and opened. Now the scanning phase completed. Tested with two projects that got stuck when working under home direcotry. Both worked this way.

Thank you for the repro case Nicholas it was extremely helpful. I have a change in flight for 3.3.1 that should fix it.
I don't have a workaround for you but this happens in the case that ndk-build is used and a target builds sources from NDK's android_app_glue along with sources in project folder. In this case, Android Studio incorrectly finds the common ancestor folder, C:\. There may be other ways to hit the bug but that's what's happening in your case.

Getting this stack trace also. Seems to be related.

java.lang.Throwable: The file '/' is not under content entry root '/Applications/Android Studio.app/Contents/bin'
        at com.intellij.openapi.diagnostic.Logger.error(Logger.java:126)
        at com.intellij.openapi.roots.impl.ContentEntryImpl.assertFolderUnderMe(ContentEntryImpl.java:378)
        at com.intellij.openapi.roots.impl.ContentEntryImpl.assertCanAddFolder(ContentEntryImpl.java:290)
        at com.intellij.openapi.roots.impl.ContentEntryImpl.assertCanAddFolder(ContentEntryImpl.java:285)
        at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:209)
        at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:216)
        at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:202)
        at com.intellij.openapi.roots.impl.ContentEntryImpl.addSourceFolder(ContentEntryImpl.java:195)
        at com.android.tools.ndk.GradleWorkspace.lambda$updateContentRoots$7(GradleWorkspace.java:399)
        at com.intellij.openapi.roots.ModuleRootModificationUtil.updateModel(ModuleRootModificationUtil.java:143)
        at com.android.tools.ndk.GradleWorkspace.updateContentRoots(GradleWorkspace.java:374)
        at com.android.tools.ndk.GradleWorkspace.lambda$null$0(GradleWorkspace.java:302)
        at com.intellij.openapi.roots.impl.ProjectRootManagerImpl.mergeRootsChangesDuring(ProjectRootManagerImpl.java:295)
        at com.android.tools.ndk.GradleWorkspace.lambda$null$2(GradleWorkspace.java:301)
        at com.intellij.openapi.application.impl.ApplicationImpl.runWriteAction(ApplicationImpl.java:1038)
        at com.android.tools.ndk.GradleWorkspace.lambda$updateGradleWorkspace$3(GradleWorkspace.java:297)
        at com.intellij.openapi.application.TransactionGuardImpl$2.run(TransactionGuardImpl.java:315)
        at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.doRun(LaterInvocator.java:447)
        at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.runNextEvent(LaterInvocator.java:431)
        at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.run(LaterInvocator.java:415)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:762)
        at java.awt.EventQueue.access$500(EventQueue.java:98)
        at java.awt.EventQueue$3.run(EventQueue.java:715)
        at java.awt.EventQueue$3.run(EventQueue.java:709)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:732)
        at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:817)
        at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:758)
        at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:394)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

Seems related to this issue https://issuetracker.google.com/123131649

Somehow the home directory is being added as a source root:

<component name="NewModuleRootManager" LANGUAGE_LEVEL="JDK_1_7">
    <output url="file://$MODULE_DIR$/build/intermediates/javac/debug/compileDebugJavaWithJavac/classes" />
    <output-test url="file://$MODULE_DIR$/build/intermediates/javac/debugUnitTest/compileDebugUnitTestJavaWithJavac/classes" />
    <exclude-output />
    <content url="file://$USER_HOME$">
      <sourceFolder url="file://$USER_HOME$" isTestSource="false" />  <------ Bad
    ....

Which forces the entire contents of the user's home directory to be scanned and indexed. We are using C++ libraries outside of the project's root - namely prebuilt Conan packages located in ~/.conan. Is there any workaround?

A workaround that I have found is that when I see that is indexing "C:\" in the "Project Source Files" pane. I go to the app.iml file and remove the content tag that has the "C:\" and save the file. That does that it stops the indexation of "C:\" and continue with the correct source directories.

But that makes that when the indexation "ends", it gets "stuck" (actually looks like is loading something, but never ends), in order to solve that I go to the Gradle pane and refresh the gradle project. When it is finally done, the indexing also ends and Android Studio allows me to build the project.

This particular issue is confirmed as fixed in 3.3.1. The scanning and indexing is still an order of magnitude slower  than 3.2.1 (as is Android Studio overall), but at least now it completes in minutes vs. hours and doesn't crash or run out of memory anymore as per this ticket.

Thanks for verifying!
Can you provide more context around the scanning and indexing slowness you observed with 3.3.1 compared to 3.2.1?
Is it the same as https://issuetracker.google.com/issues/121340427 or something else?
Thanks!

Although the bug is fixed, I still experiment the same problem in Android Studio 3.2.2 and 3.4.

When opening a project with a large amount of .h files (webrtc library), It takes around 10 mins in the indexing phase (long time but ok). The problem comes in the Building Symbols stage, it eats all the RAM avaiable and ends with a Low memory warning that makes the IDE unusable.
You can see in the attached screenshot where I configured the IDE to use 8Gb of RAM. If you increase the value it doesn't solve anything, it just does not stop consiming RAM until it hits the limit, no matter how high it is.

3.2 works ""ok"" (at least it doesn't freeze, but no code completion, syntax highlighting... )

Is there any workaround that could mitigate the issue?

Hi, can you give us some idea about the scale of the number of .h files in your library?
And if it's open source, where we can try to repro it ourselves, that would be even better.

This bug is still showing in 3.4......

To comment #29

Thanks for answering!

Our project has around 60.000 .h/.hpp files.
Unfortunately our project is not open source, however, our biggest dependency is webrtc which is.

I would say that if you create a project that depends on webrtc, you will see the same problem.

Hi, I tried downloading the WebRTC source code following instructions from https://webrtc.org/native-code/android/. There seems to be no CMakeLists.txt in the project and there are ~2300 headers in it. Do you create custom CMakeLists in order to include WebRTC as a dependency for your project?

Also, do you by any chance use Android Studio to open the generated gradle file in step https://webrtc.org/native-code/android/#using-android-studio?

Hello, I am experiencing the same problem on 3.4. My project has around 2,000 .h, .c, and .cpp files. They are located across many different paths on my hard drive. Is there any progress on this issue? Thank you.

Maybe this issue related to this one https://issuetracker.google.com/issues/131854856 ?

This bug is not fixed on Android Studio 4.1.
Same behaviour. Same setup. OS X, c++

Found SO question that describes this as well on 4.1.
https://stackoverflow.com/questions/64401439/

Yes, I have exactly the same issue happening also again with 4.1. With 4.2 it works again.

Exact same issue. It is paralyzing for all ndk c++ game developers. AS 4.1. Thanks

This is fixed in 4.2 and later