Fixed
Status Update
No update yet.
Comments
rm...@google.com
Thank you for your feedback. Team may reach out for more feedback in reproducing or triaging this issue.
tg...@google.com
tg...@google.com
Hi Ales, thank you for your feedback and we are very sorry for your bad experience. We actually found several bugs that contribute to this issue. We are actively working on resolving the issues and will try to get the fixes into future releases ASAP.
If you still want to give a try to 3.3, unchecking "Settings" -> "Experimental" -> "Only sync the active variant" should be able to get 3.3 working.
If you still want to give a try to 3.3, unchecking "Settings" -> "Experimental" -> "Only sync the active variant" should be able to get 3.3 working.
om...@gmail.com
Hi,
considering that Android Studio is an awesome tool that covers a huge area and brings together so many tools and weaves together masses of code underneath your apology is really not needed. An occasional problem is bound to pop up. And what really makes up for the issue is that we went from a "hopeless situation for me" to a "problem solved" state in 6 days. Thank you!
I look forward to testing the fix - if there is a canary I can play with somewhere so I can verify the solution, please let me know.
I am really glad I could be of assistance and that the time I invested will help create a better tool for all.
There were some other issues relating to native development, so I have been experimenting in the background a bit in my virtual machine... See: AS_vmware_snapshots.png
As it turns out I was just really unlucky with the initial upgrade of my AS 3.2.1 to 3.3. Pretty much any other deployment path worked. So a clean install of AS 3.3 appears to be working OK (at first glance - with cmake build directly injected in the app).
The only thing that really doesn't work is a clean install of AS 3.2.1 and then any upgrade to a higher version doesn't work either. And since 3.2.1 was the last version that worked for me... I was laboring under the assumption that it is the last known good version of AS.
Had I directly done a clean install of 3.3 it would be a lot better. Or even 3.2 and then upgraded to 3.3 (even via 3.2.1). To me it looks like that when doing a clean install of 3.2.1, some sort of value/setting gets hidden in the .AndroidStudio.3.2 file structure somewhere that poisons all upgrades.
What I cannot explain is why my system went sideways initially... As I am pretty sure I transitioned through AS 3.2 as well. And in my vmware tests those upgrades worked OK. But from a blackbox perspective there is just so much I can tell.
I will try a side-by-side copy of AS 3.3 on my main system after I commit my work in the next days.
Since we are already talking... And you may be intimately familiar with cmake integration... I am currently using what appears to be a more-or-less functional copy of AS 3.2.1 that I pulled from a backup of my system and I cannot say I am entirely certain it is trustworthy due to its provenance. The development experience is "somewhat reduced" by AS thinking that the cpp files I am working on are not part of the project (See: AS-CMake-sync.png) and this impacts the code editor (cannot open header files, cannot go to function declarations, doesn't offer function or variables autocomplete)... No amount of syncing helps and neither does "Refresh linked C++ projects". So a thought keeps nagging me... That my project structure is a little out of the ordinary... And that such a structure may not be an expected case and thus may not be properly handled.
Long story short, I need to have a bit of code outside of the AS project filestructure. Are relative paths like the one I use for SHARED_SOURCES valid and anticipated? Perhaps the "This file is not part of the project..." message is related to my project file structure... See: AS-CMake_source.png
I sincerely hope that is not the case (or that you are willing/able to fix it) since this is pretty much the only way I found to fit things together without using filesystem links. :)
Thank you for your time.
considering that Android Studio is an awesome tool that covers a huge area and brings together so many tools and weaves together masses of code underneath your apology is really not needed. An occasional problem is bound to pop up. And what really makes up for the issue is that we went from a "hopeless situation for me" to a "problem solved" state in 6 days. Thank you!
I look forward to testing the fix - if there is a canary I can play with somewhere so I can verify the solution, please let me know.
I am really glad I could be of assistance and that the time I invested will help create a better tool for all.
There were some other issues relating to native development, so I have been experimenting in the background a bit in my virtual machine... See: AS_vmware_snapshots.png
As it turns out I was just really unlucky with the initial upgrade of my AS 3.2.1 to 3.3. Pretty much any other deployment path worked. So a clean install of AS 3.3 appears to be working OK (at first glance - with cmake build directly injected in the app).
The only thing that really doesn't work is a clean install of AS 3.2.1 and then any upgrade to a higher version doesn't work either. And since 3.2.1 was the last version that worked for me... I was laboring under the assumption that it is the last known good version of AS.
Had I directly done a clean install of 3.3 it would be a lot better. Or even 3.2 and then upgraded to 3.3 (even via 3.2.1). To me it looks like that when doing a clean install of 3.2.1, some sort of value/setting gets hidden in the .AndroidStudio.3.2 file structure somewhere that poisons all upgrades.
What I cannot explain is why my system went sideways initially... As I am pretty sure I transitioned through AS 3.2 as well. And in my vmware tests those upgrades worked OK. But from a blackbox perspective there is just so much I can tell.
I will try a side-by-side copy of AS 3.3 on my main system after I commit my work in the next days.
Since we are already talking... And you may be intimately familiar with cmake integration... I am currently using what appears to be a more-or-less functional copy of AS 3.2.1 that I pulled from a backup of my system and I cannot say I am entirely certain it is trustworthy due to its provenance. The development experience is "somewhat reduced" by AS thinking that the cpp files I am working on are not part of the project (See: AS-CMake-sync.png) and this impacts the code editor (cannot open header files, cannot go to function declarations, doesn't offer function or variables autocomplete)... No amount of syncing helps and neither does "Refresh linked C++ projects". So a thought keeps nagging me... That my project structure is a little out of the ordinary... And that such a structure may not be an expected case and thus may not be properly handled.
Long story short, I need to have a bit of code outside of the AS project filestructure. Are relative paths like the one I use for SHARED_SOURCES valid and anticipated? Perhaps the "This file is not part of the project..." message is related to my project file structure... See: AS-CMake_source.png
I sincerely hope that is not the case (or that you are willing/able to fix it) since this is pretty much the only way I found to fit things together without using filesystem links. :)
Thank you for your time.
tg...@google.com
Hi Ales, thank you for the detailed explanation on the issue! It sounds very much like one of our known issues that I discovered a couple of days ago. Basically we screwed up after invoking cmake and passing the compiler settings (working directory, flags, etc) to Jetbrains' C++ engine for nonstandard project structure.
A partial fix is in the 3.3.1 release. Depending on how atypical the project structure is, this fix may still be insufficient. Another fuller fix is still being rolled out. We are hoping to get that into release 3.3.2 if possible.
Again, thank you for all the support you have kindly provided to us!
A partial fix is in the 3.3.1 release. Depending on how atypical the project structure is, this fix may still be insufficient. Another fuller fix is still being rolled out. We are hoping to get that into release 3.3.2 if possible.
Again, thank you for all the support you have kindly provided to us!
om...@gmail.com
Hi!
Awesome. It is good to hear that there is hope for my project structure as well. I am looking forward to the new releases. Will give 3.3 and 3.3.1 another shake.
It is my pleasure. Thank you for your support as well and making development a pleasurable experience.
Awesome. It is good to hear that there is hope for my project structure as well. I am looking forward to the new releases. Will give 3.3 and 3.3.1 another shake.
It is my pleasure. Thank you for your support as well and making development a pleasurable experience.
om...@gmail.com
Hi again!
I just wanted to say thank you for the "Only sync the active variant" tip. AS 3.3 works like a charm in a side-by-side scenario with the "Only sync the active variant" option disabled. AS 3.3 has a lot of nice Lint features and even my atypical project structure seems to work correctly.
Just in case I didn't import the old configuration from AS 3.2 and started from scratch. Tests in VMWare showed that a clean install of AS 3.3 worked OK with a CMake native build project. Uh... I find myself tempted to do an actual upgrade... :D
Have a great day!
I just wanted to say thank you for the "Only sync the active variant" tip. AS 3.3 works like a charm in a side-by-side scenario with the "Only sync the active variant" option disabled. AS 3.3 has a lot of nice Lint features and even my atypical project structure seems to work correctly.
Just in case I didn't import the old configuration from AS 3.2 and started from scratch. Tests in VMWare showed that a clean install of AS 3.3 worked OK with a CMake native build project. Uh... I find myself tempted to do an actual upgrade... :D
Have a great day!
tg...@google.com
Thank you Ales for your support! You have a nice day, too!
om...@gmail.com
In case it is useful to anyone struggling with CMake and AS... I noticed that in AS 3.3 (as well as 3.2.1) CMake 3.6.0 is the way to go. I have both CMake versions installed and I was under the impression that (by default) the newest version is being used. It turns out I was wrong.
I was modifying my gradle file and was trying to find all acceptable parameters in the externalNativeBuild (outside of the defaultConfig block). And found the version parameter is acceptable in that block... So I gave it a try.
externalNativeBuild {
cmake {
// version "3.10.2"
version "3.6.0"
// buildStagingDirectory
path file('CMakeLists.txt')
}
}
It turns out that if I use CMake version 3.10.2 the basic C++ includes (stuff like <vector>, <iostream>, ...) were not found and were marked in red in the source code. Only when I explicitly use CMake 3.6.0 and "Refresh linked C++ projects" things get back to normal.
I am guessing this is normal and that CMake is intended for higher versions of AS from the beta / canary branches? Could maybe Lint detect and warn about such version issues? I have seen a lot of wonderful tips and hints (especially love it when the fix option is available) and this might be a good fit as well.
I was modifying my gradle file and was trying to find all acceptable parameters in the externalNativeBuild (outside of the defaultConfig block). And found the version parameter is acceptable in that block... So I gave it a try.
externalNativeBuild {
cmake {
// version "3.10.2"
version "3.6.0"
// buildStagingDirectory
path file('CMakeLists.txt')
}
}
It turns out that if I use CMake version 3.10.2 the basic C++ includes (stuff like <vector>, <iostream>, ...) were not found and were marked in red in the source code. Only when I explicitly use CMake 3.6.0 and "Refresh linked C++ projects" things get back to normal.
I am guessing this is normal and that CMake is intended for higher versions of AS from the beta / canary branches? Could maybe Lint detect and warn about such version issues? I have seen a lot of wonderful tips and hints (especially love it when the fix option is available) and this might be a good fit as well.
to...@gmail.com
One part of this problem is that the cmake version configuration in build.gradle is broken when multiple cmake versions are installed.
So if both CMake 3.6.0 and 3.10.2 are installed, the newer one is selected even though 3.6.0 is configured in build.gradle.
See more information here:
https://issuetracker.google.com/issues/123572341
So if both CMake 3.6.0 and 3.10.2 are installed, the newer one is selected even though 3.6.0 is configured in build.gradle.
See more information here:
om...@gmail.com
Ha, interesting. I am using a slightly different setup (now using 3.3 in side-by-side mode):
Gradle version: 4.10.1
Android Plugin Version: 3.3
Module Compile Sdk Version: 19
Module Build Tools Version: 28.0.3
Android SDK Tools version: 26.1.1
I don't think I am experiencing the problem as described in 123572341. My system is also slightly different than the one reported in 123572341 (AS 3.3 vs AS 3.2.1).
The version parameter had an obvious impact on my environment. I had problems when I specified version "3.10.2" and the problems went away when I used version "3.6.0". So the parameter is not ignored on my system.
This is further supported by Process Monitor. See: AS_cmake_version.png
We can see gradle takes a sniff at the package info of both cmake versions (one or twice :D) and then gradle decides to use cmake 3.6 as configured.
So the problem is likely fixed in newer versions of gradle.
Gradle version: 4.10.1
Android Plugin Version: 3.3
Module Compile Sdk Version: 19
Module Build Tools Version: 28.0.3
Android SDK Tools version: 26.1.1
I don't think I am experiencing the problem as described in 123572341. My system is also slightly different than the one reported in 123572341 (AS 3.3 vs AS 3.2.1).
The version parameter had an obvious impact on my environment. I had problems when I specified version "3.10.2" and the problems went away when I used version "3.6.0". So the parameter is not ignored on my system.
This is further supported by Process Monitor. See: AS_cmake_version.png
We can see gradle takes a sniff at the package info of both cmake versions (one or twice :D) and then gradle decides to use cmake 3.6 as configured.
So the problem is likely fixed in newer versions of gradle.
tg...@google.com
Thanks tokohone! We will follow up on
Hi Ales, so we believe the problem you are encountering with cmake 3.10 is related to the bug that handles irregular project structure. Basically we rewrote the cmake integration if cmake 3.10 is used and a generic bug there is causing various weird behaviors with cmake 3.10. Android Studio 3.3.1 should have a partial fix to that and 3.3.2 will have the fuller fix. A future 3.4 preview will also have the fuller fix. Hopefully they will indeed address your problem. If not, please definitely let us know and we are very grateful for your help!
Hi Ales, so we believe the problem you are encountering with cmake 3.10 is related to the bug that handles irregular project structure. Basically we rewrote the cmake integration if cmake 3.10 is used and a generic bug there is causing various weird behaviors with cmake 3.10. Android Studio 3.3.1 should have a partial fix to that and 3.3.2 will have the fuller fix. A future 3.4 preview will also have the fuller fix. Hopefully they will indeed address your problem. If not, please definitely let us know and we are very grateful for your help!
om...@gmail.com
Awesome! Looking forward.
My pleasure. Will report if fix is working for my scenario.
Have a great day!
My pleasure. Will report if fix is working for my scenario.
Have a great day!
tg...@google.com
om...@gmail.com
I tried AS 3.3.1 and it works really well. The bug seems to be gone. Will report if I see any issues come back.
Also... My CPU load used to be around 60-70% all the time and now it is for the first time under 10%! Great work!
Also... My CPU load used to be around 60-70% all the time and now it is for the first time under 10%! Great work!
ka...@gmail.com
Disconnected everything
Description
AI-182.5107.16.33.5199772, JRE 1.8.0_152-release-1248-b01x64 JetBrains s.r.o, OS Windows 10(amd64) v10.0 , screens 1920x1080, 2560x1440, 1920x1080
Android Gradle Plugin: 3.3.0
Gradle: 4.10.1
NDK: from local.properties: 19.0.5232133; latest from SDK: 19.0.5232133;
LLDB: LLDB 3.1 (revision: 3.1.4508709)
CMake: from local.properties: (not specified); latest from SDK: 3.10.2; from PATH: (not found);
Source: user_sentiment_feedback
After upgrade to Android Studio 3.3 CMake integration no longer works properly on an Android Library module.
When opening a project with a module that has CMake integration AS throws an excpetion (see bottom of message) and gets stuck on:
Build: Sync
Project Setup: reading from cache...
(See attachment)
The only way to make AS load the project again is to remove the externalNativeBuild part in the gradle file for the library module that is referring to a cmake build file. Or to remove the library as dependency from the application project.
Partial workaround:
After AS loads the project, the externalNativeBuild block can be re-enabled or the "Link C++ project with Gradle" can be used on the module to re-introduce the externalNativeBuild block.
After a sync project with Gradle files the cpp folder appears in the Android View of the project, however it remains empty and no cpp source files are displayed (See attachment: AS-CMake_re-insert.png). Build will however include the C++ files in the build and produce an APK that works.
This needs to be done every time the project is opened.
Notes:
Removing the .externalNativeBuild and build folders for the project did not help with restoring functionality.
If a new "Android Library" module is added and the same CMake file is added to the build, AS will consistently load and show the project. However only as long as the library is not a dependency of any other module.
Recreating the entire project from scratch in AS 3.3 with a mobile project and shared library project produced same load failure.
Sample:
See attached sample TestApp.zip.
Emotional remark:
After wasting an entire day on this issue (before a looming deadline) and pulling out "wires" one by one I must say that this release is not worthy of "stable release" status. I am ready to scream here... It is completely unusable for my scenario and I suspect many people will be suffering from this problem. Please extend the testing scenarios to include a library module with native code as a dependency of an app module.
A lot of the new added features look interesting though... I suppose it is now time to revert to the older version of AS and waste a few more hours on that....
-------- Exception: --------
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at com.android.tools.idea.gradle.project.model.NdkModuleModel.initializeSelectedVariant(NdkModuleModel.java:197)
at com.android.tools.idea.gradle.project.model.NdkModuleModel.setSelectedVariantName(NdkModuleModel.java:298)
at com.android.tools.idea.gradle.project.sync.setup.module.ndk.NdkFacetModuleSetupStep.configureFacet(NdkFacetModuleSetupStep.java:51)
at com.android.tools.idea.gradle.project.sync.setup.module.ndk.NdkFacetModuleSetupStep.doSetUpModule(NdkFacetModuleSetupStep.java:45)
at com.android.tools.idea.gradle.project.sync.setup.module.ndk.NdkFacetModuleSetupStep.doSetUpModule(NdkFacetModuleSetupStep.java:31)
at com.android.tools.idea.gradle.project.sync.setup.module.ModuleSetupStep.setUpModule(ModuleSetupStep.java:35)
at com.android.tools.idea.gradle.project.sync.setup.module.common.BaseSetup.setUpModule(BaseSetup.java:41)
at com.android.tools.idea.gradle.project.sync.ng.ModuleSetup.setupModuleModels(ModuleSetup.java:137)
at com.android.tools.idea.gradle.project.sync.ng.CachedProjectModelsSetup.setUpModules(CachedProjectModelsSetup.java:116)
at com.android.tools.idea.gradle.project.sync.ng.ProjectSetup$ProjectSetupImpl.setUpProject(ProjectSetup.java:82)
at com.android.tools.idea.gradle.project.sync.ng.SyncResultHandler.onSyncSkipped(SyncResultHandler.java:164)
at com.android.tools.idea.gradle.project.sync.ng.NewGradleSync.trySyncWithCachedGradleModels(NewGradleSync.java:219)
at com.android.tools.idea.gradle.project.sync.ng.NewGradleSync.sync(NewGradleSync.java:165)
at com.android.tools.idea.gradle.project.sync.ng.NewGradleSync.access$000(NewGradleSync.java:59)
at com.android.tools.idea.gradle.project.sync.ng.NewGradleSync$2.run(NewGradleSync.java:151)
at com.intellij.openapi.progress.impl.CoreProgressManager$TaskRunnable.run(CoreProgressManager.java:736)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$1(CoreProgressManager.java:157)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:580)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:525)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:85)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:144)
at com.intellij.openapi.progress.impl.CoreProgressManager$4.run(CoreProgressManager.java:395)
at com.intellij.openapi.application.impl.ApplicationImpl$1.run(ApplicationImpl.java:314)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)