Status Update
Comments
ma...@gmail.com <ma...@gmail.com> #2
Can you include a sample project that crashes in release mode?
ma...@gmail.com <ma...@gmail.com> #3
For us this is only happening in places where LifecycleEventEffect
is used. Example stacktrace:
Fatal Exception: java.lang.IllegalStateException
CompositionLocal LocalLifecycleOwner not present
androidx.lifecycle.compose.LocalLifecycleOwnerKt$LocalLifecycleOwner$1$1.invoke (LocalLifecycleOwner.android.kt:63)
androidx.lifecycle.compose.LocalLifecycleOwnerKt$LocalLifecycleOwner$1$1.invoke (LocalLifecycleOwner.android.kt:62)
kotlin.SynchronizedLazyImpl.getValue (LazyJVM.kt:74)
androidx.compose.runtime.LazyValueHolder.getCurrent (LazyValueHolder.java:29)
androidx.compose.runtime.LazyValueHolder.getValue (LazyValueHolder.java:31)
androidx.compose.runtime.CompositionLocalMapKt.read (CompositionLocalMap.kt:90)
androidx.compose.runtime.ComposerImpl.consume (Composer.kt:2135)
androidx.lifecycle.compose.LifecycleEffectKt.LifecycleEventEffect (LifecycleEffect.kt:748)
com.freeletics.feature.profile.ProfileUiKt$ProfileUi$1.invoke (ProfileUi.kt:62)
This is also on Lifecycle 2.8.2 with Compose 1.6.
br...@gmail.com <br...@gmail.com> #4
Here is a sample project
- Checkout repository
- Build release apk with ./gradlew :app:assembleRelease -PenableReleaseSigning=true
- App starts without crash
- Comment or remove line 14 in
https://github.com/nilsjr/Koncept/blob/develop/app/proguard-rules.pro - Build release apk with ./gradlew :app:assembleRelease -PenableReleaseSigning=true
- App crashing on start
FATAL EXCEPTION: main (Ask Gemini)
Process: de.nilsdruyen.koncept, PID: 5880
java.lang.IllegalStateException: CompositionLocal LocalLifecycleOwner not present
...
br...@gmail.com <br...@gmail.com> #5
Thank you for sharing the sample project. I can confirm that I was able to reproduce the issue, and that
jo...@google.com <jo...@google.com> #6
It appears that the custom ProGuard rule was not working as intended across all projects.
However, using public static *** getLocalLifecycleOwner();
(with the wildcard type ***
) seems to work consistently in the sample project and our internal experiments:
-if public class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt {
public static *** getLocalLifecycleOwner();
}
-keep public class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt {
public static *** getLocalLifecycleOwner();
}
We are investigating further, and we will be working on a fix for the issue.
jo...@google.com <jo...@google.com> #7
Branch: androidx-main
commit 79f5644cb937d950318c3c5ef2aca70ab1413119
Author: Marcello Galhardo <mgalhardo@google.com>
Date: Fri Jun 14 16:34:11 2024
Fix Lifecycle 2.8 custom ProGuard rule
* The custom ProGuard rule was not working as intended across all projects.
* Replacing by `public static *** getLocalLifecycleOwner();` (with the wildcard type `***`) seems to work consistently in all projects.
Fixes:
Test: manual
Change-Id: I4cfdecc0bbfc0be02d66efcee2c63bb5b025dca2
M lifecycle/lifecycle-runtime-compose/proguard-rules.pro
ex...@gmail.com <ex...@gmail.com> #8
Could you please make an immediate patch release as 2.8.2 crashes with the above exception?
ma...@gmail.com <ma...@gmail.com> #10
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.lifecycle:lifecycle-runtime-compose:2.8.3
androidx.lifecycle:lifecycle-runtime-compose-android:2.8.3
androidx.lifecycle:lifecycle-runtime-compose-desktop:2.8.3
uc...@google.com <uc...@google.com>
jo...@google.com <jo...@google.com> #11
ma...@gmail.com <ma...@gmail.com> #12
There was a mix-up, and the Lifecycle 2.8.3 artifacts won't be available until Monday. Sorry for the false alarm.
ma...@gmail.com <ma...@gmail.com> #13
Seems to be good now. Thanks!
an...@supercell.com <an...@supercell.com> #14
Lifecycle 2.8.3 is now available on
ex...@gmail.com <ex...@gmail.com> #15
I'm still getting "java.lang.IllegalStateException: CompositionLocal LocalLifecycleOwner not present" with 2.8.3 in release builds (with obfuscation enabled). Adding
-keep class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt { *; }
to my ProGuard rules fixes the issue. Any advice?
In my setup I have an app that's using the lifecycle dependencies directly, but some other dependencies of mine also include the same (and these libraries are obfuscated too) - not sure if this makes a difference.
jo...@google.com <jo...@google.com> #16
I'm unable to offer advice since I can't replicate the issue you're experiencing -- but based on your message, it appears Lifecycle "should" be working correctly.
Would you please
ar...@google.com <ar...@google.com>
np...@gmail.com <np...@gmail.com> #17
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.lifecycle:lifecycle-runtime-compose:2.9.0-alpha01
androidx.lifecycle:lifecycle-runtime-compose-android:2.9.0-alpha01
androidx.lifecycle:lifecycle-runtime-compose-desktop:2.9.0-alpha01
tg...@google.com <tg...@google.com> #18
np...@gmail.com <np...@gmail.com> #19
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.
[Deleted User] <[Deleted User]> #20
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.
an...@supercell.com <an...@supercell.com> #21
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.
jo...@google.com <jo...@google.com> #22
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.
an...@supercell.com <an...@supercell.com> #23
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)
74...@gmail.com <74...@gmail.com> #24
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?
qu...@gmail.com <qu...@gmail.com> #25
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.
tg...@google.com <tg...@google.com>
jo...@google.com <jo...@google.com>
ma...@gmail.com <ma...@gmail.com> #26
ar...@google.com <ar...@google.com> #27
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
Thanks!
ro...@gmail.com <ro...@gmail.com> #28
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?
ar...@google.com <ar...@google.com> #29
And if it's open source, where we can try to repro it ourselves, that would be even better.
[Deleted User] <[Deleted User]> #30
ro...@gmail.com <ro...@gmail.com> #31
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.
tg...@google.com <tg...@google.com> #32
Also, do you by any chance use Android Studio to open the generated gradle file in step
ho...@gmail.com <ho...@gmail.com> #33
ar...@gmail.com <ar...@gmail.com> #34
vi...@gmail.com <vi...@gmail.com> #35
Same behaviour. Same setup. OS X, c++
Found SO question that describes this as well on 4.1.
Description
There was also svn error, that said that my home folder was not in svn. Not sure if it tries to index my whole home folder now..
Everything works fast if I use experimental use active configuration only setting, but then I cant see my cpp files :(
Build: 3.3, AI-182.5107.16.33.5199772, 201812250239,
AI-182.5107.16.33.5199772, JRE 1.8.0_152-release-1248-b01x64 JetBrains s.r.o, OS Mac OS X(x86_64) v10.14.1 unknown, screens 2560x1440; Retina
Android Gradle Plugin: 3.3.0
Gradle: 4.10.2
NDK: from local.properties: 18.1.5063045; latest from SDK: 18.1.5063045;
LLDB: LLDB 3.1 (revision: 3.1.4508709)
CMake: from local.properties: (not specified); latest from SDK: 3.6.0-rc2; from PATH: (not found);
Source: user_sentiment_feedback
IMPORTANT: Please read