Status Update
Comments
hu...@google.com <hu...@google.com>
vs...@google.com <vs...@google.com> #2
I am not sure I understand the use case. how can the benchmark be code to real world scenario when it's not possible to do right now ? which scenario is it ?
In any case, since this would be for benchmarking, this would clearly not be available through the public DSL. We should find a semi-private way of doing this (maybe the private variant API object could offer that functionality for instance or a property).
an...@mavenclinic.com <an...@mavenclinic.com> #3
We want benchmarks to measure code after Progaurd / R8, but it's not possible to turn that on for androidTests in library modules at the moment (to my knowledge?)
Benchmarks are also a public facing thing, but we have a plugin to help configure gradle builds for our users, so if support for this ends up in a private API, we could try to keep those usages localized to our code perhaps.
aa...@google.com <aa...@google.com> #4
Any update on the status of this request and when it can be supported?
Thanks,
Amanda
an...@mavenclinic.com <an...@mavenclinic.com> #5
this is not part of our OKR at this point so we are not talking soon. at first glance, we would need to simulate usage patterns to minify against and such, this seems substantial amount of work. there are not a lot of library module that have android tests, most only rely on unit-tests.
how important is this ? we are out of PM right now but I suspect the next step will be to negotiate with J. Eason and xav@ to scale a priority level.
vs...@google.com <vs...@google.com> #6
This is a high priority request for Compose, to enable their benchmarks to measure release accurate performance. (Micro) Benchmarks are library modules, as they don't need the complexity of multi-apk tests - they're self measuring APKs that depend on libraries. (d.android.com/benchmark)
there are not a lot of library module that have android tests, most only rely on unit-tests.
To clarify, this is for com.android.library
modules, not jars - I'd expect most of those to use android tests (all of the libraries in jetpack for example do).
we would need to simulate usage patterns to minify against and such, this seems substantial amount of work
Simulate usage patterns? I don't understand - the dev can themselves provide a keep rule for test infra / classes if necessary. Long term, keep rules should be provided by test libraries.
vs...@google.com <vs...@google.com> #7
We've been experimenting with ways to work around this for Compose. Performance results from R8 seem significantly different, and would enable us to measure much more accurately. I've tried to come up with a workaround using a com.android.app module, and while it almost works (and we can get measurements), it's extremely hacky and doesn't let us run tests anymore via Studio:
vs...@google.com <vs...@google.com> #8
Bumping this request, as Compose has recently had more interest in the ability to benchmark with and without R8 enabled.
We're fine if the default implementation doesn't work with minification (tree shaking) - we're happy to supply those rules ourselves, or simply evaluating with minification off to take advantage of other optimizations.
an...@mavenclinic.com <an...@mavenclinic.com> #9
Juan, this might be something to put on our OKR in the near future, I think you chat with Amanda to set the priority.
an...@google.com <an...@google.com> #10
Hey everyone, I am catching up on feature requests and saw this one. I'll schedule time for us to talk about this in a few days.
Description
####################################################
Please provide all of the following information, otherwise we may not be able to route your bug report.
####################################################
1. Describe the bug or issue that you're seeing.
Android Studio appends "Ask Gemini" to the title message of every stack trace in Logcat
I imagine that this is intentional. But as a fairly senior engineer working for a company that has a "no company specifics in generative AI" policy, this is a nightmare, as tools will now encourage engineers to violate company policy.
What is even worse is that it is not even obvious that the "Ask Gemini" text is being added by Android Studio and isn't part of the exception message itself, making it possible that more junior engineers might reasonably think that asking gemini is the right thing to do for a given stack trace. What's even dumber is that it's a prompt with no action. I expect pithy deceptive engagement seeking design like this from social media apps; seeing it in tools is incredibly disappointing.
2. Attach log files from Android Studio
n/a
3. If you know what they are, write the steps to reproduce:
Anything that causes a stack trace to appear in logcat.
In addition to logs, please attach a screenshot or recording that illustrates the problem.
For more information on how to get your bug routed quickly, see
Build: AI-242.21829.142.2422.12358220, 202409120329
AS: Ladybug Feature Drop | 2024.2.2 Canary 2
AI-242.21829.142.2422.12358220, JRE 21.0.3+-79915917-b509.11x64 JetBrains s.r.o., OS Mac OS X(aarch64) v13.7, screens 3456x2234 (200%)
Android Gradle Plugin: 8.1.4
Gradle: 8.10
Gradle JDK: Eclipse Temurin 17.0.12 - aarch64
NDK: from local.properties: (not specified), latest from SDK: (not found)
CMake: from local.properties: (not specified), latest from SDK: (not found), from PATH: (not found)
Source: send_feedback_icon```