Assigned
Status Update
Comments
ch...@google.com <ch...@google.com> #2
I just attached a minimal test application with duplicated and multiline traces. Provided are a couple of logcat files and screenshots.
To me this isn'r really a big problem, since AS compiles my application and lets me debug it. That's what I use it for in my company. I just found it a bit annoying that something that worked one way in AS 2.x and 3.0, suddenly changed in 3.1. The new way results more time-consuming to me while debugging and reviewing the logs.
Could this be made configurable? Not necessarily in the UI, but editing some properties file. Thanks. :)
To me this isn'r really a big problem, since AS compiles my application and lets me debug it. That's what I use it for in my company. I just found it a bit annoying that something that worked one way in AS 2.x and 3.0, suddenly changed in 3.1. The new way results more time-consuming to me while debugging and reviewing the logs.
Could this be made configurable? Not necessarily in the UI, but editing some properties file. Thanks. :)
si...@adevinta.com <si...@adevinta.com> #3
I have the same problem.
ch...@google.com <ch...@google.com> #4
I also have the same problem.
si...@adevinta.com <si...@adevinta.com> #5
I also have the same problem.
ch...@google.com <ch...@google.com> #6
I also have the same problem.
si...@adevinta.com <si...@adevinta.com> #7
I also have the same problem.
si...@adevinta.com <si...@adevinta.com> #8
Was it fixed reverting to the old behavior, or was it fixed making the deduplication configurable?
What release version will include the fix?
What release version will include the fix?
g....@gmail.com <g....@gmail.com> #9
I still have the same problem on my version.
Android Studio 3.1.1
Build #AI-173.4697961, built on April 4, 2018
JRE: 1.8.0_152-release-1024-b02 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 8.1 6.3
Screenshot attached.
Is there any way to customize this kind of behavior?
Android Studio 3.1.1
Build #AI-173.4697961, built on April 4, 2018
JRE: 1.8.0_152-release-1024-b02 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 8.1 6.3
Screenshot attached.
Is there any way to customize this kind of behavior?
si...@adevinta.com <si...@adevinta.com> #10
@jose.aladro.jsc@gmail.com This change in behavior was inadvertent and I reverted it. The fix will go out in 3.2.
si...@adevinta.com <si...@adevinta.com> #11
how long before 3.2 is released? or should we just go back to 3.0 while we wait?
ch...@google.com <ch...@google.com> #12
The fix will go out in 3.2 Canary 13 (we're at 11 now). If you're willing to put up with some instability use the canaries. I can't comment on when future stable versions will land.
si...@adevinta.com <si...@adevinta.com> #13
canaries defeat the whole idea of wanting a bug fix. I'd get this bug fix plus I'll gain 50 new bugs, so no thanks. guess it's back to 3.0 since you say you aint gonna fix this in an update to 3.1
ch...@google.com <ch...@google.com> #14
got the same behaviour and i dislike it. I would prefer to always see the complete logcat line.
si...@adevinta.com <si...@adevinta.com> #15
I was preparing to submit a similar issue before coming across this one. Along with the problem originally described, I've noticed that the current version seems to be unable to properly filter logcat. For example, given the following log:
```
05-15 17:04:26.219 000-000/com.example.debug D/testing: onViewRecycled: CardAndTextViewHolder
onViewRecycled: SubtitleViewHolder
onViewRecycled: HeaderViewHolder
onBindViewHolder: 0
```
Each log statement here has the same tag ("testing"). If the term "onViewRecycled" is applied to the logcat filter, the line containing "onBindViewHolder: 0" (line 4) should not be shown, but it is. I assume this and the original issue are both caused by the same bug, and if so, should be fixed in an upcoming version as mentioned above.
```
05-15 17:04:26.219 000-000/com.example.debug D/testing: onViewRecycled: CardAndTextViewHolder
onViewRecycled: SubtitleViewHolder
onViewRecycled: HeaderViewHolder
onBindViewHolder: 0
```
Each log statement here has the same tag ("testing"). If the term "onViewRecycled" is applied to the logcat filter, the line containing "onBindViewHolder: 0" (line 4) should not be shown, but it is. I assume this and the original issue are both caused by the same bug, and if so, should be fixed in an upcoming version as mentioned above.
ch...@google.com <ch...@google.com> #16
Is there an idea on when will version 3.2 be released?
si...@adevinta.com <si...@adevinta.com> #17 Restricted
Restricted
si...@adevinta.com <si...@adevinta.com> #18
Thanks god 3.2 beta is finally out and it's fixed!!!
I've just spent 4 months of incredible mess cause of this issue!
I've just spent 4 months of incredible mess cause of this issue!
ch...@google.com <ch...@google.com> #19
Shoutout to juancnuno!
si...@adevinta.com <si...@adevinta.com> #20
I'm trying the new 3.2 beta and yes, the deduplication no longer occurs in the logcat window. Thanks! I'm eagerly waiting for the 3.2 final version to come out.
In the other hand, the dedupliaction still occurs in the Debug window. Similar description as in Comment #1 above:
In the Android Studio debug window, logs that have the same message header (the "W/MainActivity: " part of a message), have the message header deduplicated in logs. Instead of duplicating the logs, a 4-space indentation is instead present.
W/ActivityThread: Applicationcom.example.app is waiting for the debugger on port 8100...
I/System.out: Debugger has connected
____waiting for debugger to settle...
I/System.out: waiting for debugger to settle...
I/System.out: waiting for debugger to settle...
I/System.out: waiting for debugger to settle...
I/System.out: waiting for debugger to settle...
I/System.out: debugger has settled (1386)
(spaces displayed as underscores for readability)
Please move this message to a new debug-window related thread if appropriate. Here are some screenshots:
In the other hand, the dedupliaction still occurs in the Debug window. Similar description as in
In the Android Studio debug window, logs that have the same message header (the "W/MainActivity: " part of a message), have the message header deduplicated in logs. Instead of duplicating the logs, a 4-space indentation is instead present.
W/ActivityThread: Application
I/System.out: Debugger has connected
____waiting for debugger to settle...
I/System.out: waiting for debugger to settle...
I/System.out: waiting for debugger to settle...
I/System.out: waiting for debugger to settle...
I/System.out: waiting for debugger to settle...
I/System.out: debugger has settled (1386)
(spaces displayed as underscores for readability)
Please move this message to a new debug-window related thread if appropriate. Here are some screenshots:
Description
Context
For the past few months, we have been seeing more and more frequent
minify*WithR8
tasks taking up to 1h30 (our CI timeout is set to 2h for the entire pipeline so we definitely have even longer durations that are terminated early to avoid waiting indefinitely).When everything goes smooth, this task usually takes ~10 min, but when something goes wrong (and we currently don't really know why) it takes way more time.
Setup
Our current CI setup is as follow:
Here is our Gradle build setup, I can give more details if you think they are important:
And last but not least, our app is a fairly large app, with many third party dependencies.
The universal APK size is ~56MB (~14MB of native libraries, ~20MB of dex files).
Results
Now, here is the graph (
graph.png
) of an attempt leading to 1h50m build with ~1h30m ofminify*WithR8
....and the corresponding Gradle Scan insights (I do not trust these values very much, because they only track the value at the end of the build, but we don't have the new Develocity RAM/CPU usage graph yet):
com.android.tools.r8.printtimes
), but the early reports did not show anything particular. I'll keep an eye on it and report back when it happens again.Our hypotheses
We have a significant amount of proguard rules (5k+ lines) coming from our dependencies.
And one in particular (adyen-3ds2-2.2.21) is declaring 3.3k lines of rules (we are going to ask them why, and probably remove them in our build pipeline)… This will likely increase the total R8 time, but I'm not sure this is the root cause of the main issue.
What we’ve already tested
What we will (or could) test in the future
While this solution seems good, it is very… very.. time consuming for us, and let's be honest, it's a real pain that we don't want to go through!
To run R8 (and Lint) outside the Gradle process and (maybe?) prevent unexpected interactions.
In the meantime, we’ve also generated a compiler-input dump that I can share with you (not sure how, let me know), and here is the overview:
Thanks for your support.