App Inspection > Database Inspector: Persist IDE choices across app runs [350526050]

Fixed

Feature Request

Status Update

No update yet.

Description

st...@gmail.com

created issue #1

Jul 1, 2024 11:42PM

DESCRIBE THE ISSUE IN DETAIL:

When I use the database inspector, I may do something like enable "Live updates", and increase the number of items I query from the default of 50 to a custom number like 1000, and I may pick a specific ordering on my tables. When I re-run the app, those options are simply gone, making me re-do those changes each time. This experience is quite frustrating and having some persistence across runs would make this experience much nicer.

STEPS TO REPRODUCE:

Open the Database inspector
Change some settings inside of it, like enable "Live updates"
Re-run the app and notice that your options are lost

Android Studio Koala Feature Drop | 2024.1.2 Canary 7 Build #AI-241.17890.1.2412.11993144, built on June 20, 2024 Runtime version: 17.0.11+0-17.0.11b1207.24-11852314 aarch64 VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o. macOS 14.5

Comments

ad...@google.com <ad...@google.com> Jul 2, 2024 04:26PM

Assigned to an...@google.com.

aa...@google.com <aa...@google.com> Jul 3, 2024 07:48PM

Reassigned to aa...@google.com.

aa...@google.com <aa...@google.com> #2Sep 23, 2024 07:20PM

Status: Won't Fix (Intended Behavior)

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).

st...@gmail.com <st...@gmail.com> #3Sep 23, 2024 07:34PM

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> #4Sep 23, 2024 07:41PM

Status: Assigned (reopened)

Hi Jerome,

Any update on the status of this request and when it can be supported?

Thanks,
Amanda

st...@gmail.com <st...@gmail.com> #5Sep 23, 2024 07:55PM

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.

aa...@google.com <aa...@google.com> Sep 26, 2024 02:06PM

Marked as fixed.

an...@google.com <an...@google.com> #6Sep 27, 2024 12:48AM

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.