Status Update
No update yet.
Comments
uc...@google.com
rp...@google.com
Thanks for the report and all the details. Are you only seeing these build speed issues on CI? What's the build speed like in local development?
It would be great if you could share the compiler dump file with
du...@google.com
Are you only seeing these build speed issues on CI? What's the build speed like in local development?
Hi, we usually don't run minified builds on our local environments, mainly because of the time it takes to run it and the amount of ram it would require.
I don't want to complain even more about it, but I'm sure you are already aware of the constraints that Android has. We already have the IDE taking +10GB, the Kotlin Compiler daemon (1-6GB depending on the compilation work needed), the Gradle daemon (usually around 14G at the end of the build). If we were to enable R8 on local builds, this would render local machines (even our beefy M1s) unable to use for minimum 15 minutes each time we would want to run the app. Devs will turn this off immediately.
A good starting point would be to check if there are any passes that take up an unusual amount of time.
Do you mean running the compiledump.py? Is this what the dump will be used for? If so, can I do that locally without any external tool? I'd rather not share the dump if I can test it myself. If there is more to it, then I'll try to upload it somewhere safe.
sa...@gmail.com
Do you mean running the compiledump.py? Is this what the dump will be used for? If so, can I do that locally without any external tool? I'd rather not share the dump if I can test it myself. If there is more to it, then I'll try to upload it somewhere safe.
Running compiledump.py --print-times can give some insights into whether an unusual amount of time is spent in some compiler pass. It may be necessary to manually dig deeper into where time is spent in a given pass. If compilation time is spread evenly across the various compilation stages then the issue may be due to the sheer size of the input, but this is difficult to tell without access to the dump.
./tools/compiledump.py -d dump.zip --disable-assertions --print-times --java-opts "-Dcom.android.tools.r8.printtimes.minvalue=0"
If you can share the stdout of running the above command that would be great.
du...@google.com
I will (I'm currently downloading/installing the necessary toolchain).
Should this be run on the same host, or can it be run on a local environement. I'm wondering if this depends on the host architecture, JDK version, etc?
Description
Attach a device while android studio is running. Watch logcat. Observer this over and over again:
07-24 11:59:39.434 W/MessageQueue( 8492): Handler (android.os.Handler) {506b8aa} sending message to a Handler on a dead thread
07-24 11:59:39.434 W/MessageQueue( 8492): java.lang.IllegalStateException: Handler (android.os.Handler) {506b8aa} sending message to a Handler on a dead thread
07-24 11:59:39.434 W/MessageQueue( 8492): at android.os.MessageQueue.enqueueMessage(MessageQueue.java:545)
07-24 11:59:39.434 W/MessageQueue( 8492): at android.os.Handler.enqueueMessage(Handler.java:662)
07-24 11:59:39.434 W/MessageQueue( 8492): at android.os.Handler.sendMessageAtTime(Handler.java:631)
07-24 11:59:39.434 W/MessageQueue( 8492): at android.os.Handler.sendMessageDelayed(Handler.java:601)
07-24 11:59:39.434 W/MessageQueue( 8492): at
07-24 11:59:39.434 W/MessageQueue( 8492): at android.os.ResultReceiver$MyResultReceiver.send(ResultReceiver.java:57)
07-24 11:59:39.434 W/MessageQueue( 8492): at com.android.internal.os.IResultReceiver$Stub.onTransact(IResultReceiver.java:58)
07-24 11:59:39.434 W/MessageQueue( 8492): at android.os.Binder.execTransact(Binder.java:697)
07-24 11:59:39.755 D/AndroidRuntime( 8503): >>>>>> START com.android.internal.os.RuntimeInit uid 0 <<<<<<
07-24 11:59:39.866 I/app_process( 8503): The ClassLoaderContext is a special shared library.
07-24 11:59:39.908 D/AndroidRuntime( 8503): Calling main entry
07-24 11:59:39.930 I/app_process( 8503): System.exit called, status: 0
07-24 11:59:39.931 I/AndroidRuntime( 8503): VM exiting with result code 0.
07-24 11:59:39.931 W/MessageQueue( 8503): Handler (android.os.Handler) {506b8aa} sending message to a Handler on a dead thread
07-24 11:59:39.931 W/MessageQueue( 8503): java.lang.IllegalStateException: Handler (android.os.Handler) {506b8aa} sending message to a Handler on a dead thread
07-24 11:59:39.931 W/MessageQueue( 8503): at android.os.MessageQueue.enqueueMessage(MessageQueue.java:545)
07-24 11:59:39.931 W/MessageQueue( 8503): at android.os.Handler.enqueueMessage(Handler.java:662)
07-24 11:59:39.931 W/MessageQueue( 8503): at android.os.Handler.sendMessageAtTime(Handler.java:631)
07-24 11:59:39.931 W/MessageQueue( 8503): at android.os.Handler.sendMessageDelayed(Handler.java:601)
07-24 11:59:39.931 W/MessageQueue( 8503): at
07-24 11:59:39.931 W/MessageQueue( 8503): at android.os.ResultReceiver$MyResultReceiver.send(ResultReceiver.java:57)
07-24 11:59:39.931 W/MessageQueue( 8503): at com.android.internal.os.IResultReceiver$Stub.onTransact(IResultReceiver.java:58)
07-24 11:59:39.931 W/MessageQueue( 8503): at android.os.Binder.execTransact(Binder.java:697)
07-24 11:59:40.323 D/AndroidRuntime( 8518): >>>>>> START com.android.internal.os.RuntimeInit uid 0 <<<<<<
07-24 11:59:40.433 I/app_process( 8518): The ClassLoaderContext is a special shared library.
07-24 11:59:40.475 D/AndroidRuntime( 8518): Calling main entry
07-24 11:59:40.493 I/app_process( 8518): System.exit called, status: 0
07-24 11:59:40.494 I/AndroidRuntime( 8518): VM exiting with result code 0.
07-24 11:59:40.502 W/MessageQueue( 8518): Handler (android.os.Handler) {7a95313} sending message to a Handler on a dead thread
07-24 11:59:40.502 W/MessageQueue( 8518): java.lang.IllegalStateException: Handler (android.os.Handler) {7a95313} sending message to a Handler on a dead thread
07-24 11:59:40.502 W/MessageQueue( 8518): at android.os.MessageQueue.enqueueMessage(MessageQueue.java:545)
07-24 11:59:40.502 W/MessageQueue( 8518): at android.os.Handler.enqueueMessage(Handler.java:662)
07-24 11:59:40.502 W/MessageQueue( 8518): at android.os.Handler.sendMessageAtTime(Handler.java:631)
07-24 11:59:40.502 W/MessageQueue( 8518): at android.os.Handler.sendMessageDelayed(Handler.java:601)
07-24 11:59:40.502 W/MessageQueue( 8518): at
07-24 11:59:40.502 W/MessageQueue( 8518): at android.os.ResultReceiver$MyResultReceiver.send(ResultReceiver.java:57)
07-24 11:59:40.502 W/MessageQueue( 8518): at com.android.internal.os.IResultReceiver$Stub.onTransact(IResultReceiver.java:58)
07-24 11:59:40.502 W/MessageQueue( 8518): at android.os.Binder.execTransact(Binder.java:697)
It seems android studio is executing commands on my device in a loop and generating all this noise.
Commands based on running PS appear to be:
17254 root 9632 S /system/bin/sh -c stat -c %u /proc/6336 | xargs -n 1 pm list packages --uid
17257 root 11296 S xargs -n 1 pm list packages --uid
17268 root 9632 S /system/bin/sh -
17275 root 3976m S {main} app_process /system/bin
It seems to be looking for associated applications by uid or something? Please make this quieter, it's very annoying to see all this junk coming out of logcat. This did not used to happen with older versions Android Studio.