Status Update
Comments
as...@gmail.com <as...@gmail.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).
cm...@google.com <cm...@google.com>
ko...@gmail.com <ko...@gmail.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.
lf...@google.com <lf...@google.com> #4
Any update on the status of this request and when it can be supported?
Thanks,
Amanda
ga...@gmail.com <ga...@gmail.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.
be...@microsoft.com <be...@microsoft.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.
ma...@gmail.com <ma...@gmail.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:
bo...@google.com <bo...@google.com>
la...@gmail.com <la...@gmail.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.
sh...@squareup.com <sh...@squareup.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.
re...@gmail.com <re...@gmail.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.
ma...@gmail.com <ma...@gmail.com> #11
Ivan, can you provide a rough estimate on how long this would take ?
ga...@gmail.com <ga...@gmail.com> #12
I think this is a duplicate of
My understanding of this feature request is the following:
- As a library author, I'd like to write microbenchmarks in my library subproject that measure performance of my library after it's been processed by R8 [1]
Chris/Dustin, is this correct? If [1] is correct, this is a duplicate of a duplicate of
li...@gmail.com <li...@gmail.com> #13
As a small correction, it's:
- As a user of microbenchmarks, I'd like to measure performance of code processed by R8
For a bit more context, we generally recommend library and app devs create a completely new, empty library module to add microbenchmarks to, e.g. mylib/src/androidTest/
.
For this reason, we don't particularly care about the minified main library component from the same module.
This librarytest-only focus does have the downside that app devs must pull code into a library to be microbenchmarks, and maybe that could be something improved if there was a good minification story across the test and app module boundary, but that's a separate (but related) concern for the future.
For right now, we care about libraries with empty main directories running R8 on the code in androidTest and its dependencies.
sv...@whisp.de <sv...@whisp.de> #14
Thanks for clarifying this. In terms of benchmarking R8-processed library there seem to be two options:
- minify both library and its usages together (in this case they are coming from microbenchmark tests), and collect performance data
- run R8 on the library only, and use non-minified (i.e. public library APIs) from microbenchmark tests to collect performance data; this is captured in
.http://b/263197720
IMO both 1) and 2) are valid use-cases. For 1) you'd like to see how your library behaves given concrete API usages, while 2) tests library "full-surface".
Could 1) also be modelled with an application that depends on the library, uses some APIs, and then microbenchmark tests from its androidTest are doing the profiling?
rk...@google.com <rk...@google.com> #15
For 1) you'd like to see how your library behaves given concrete API usages,
Yes, this is it exactly. We want 1, assuming that it means all of the library dependencies of the benchmark and it's androidTest code would be run through R8 together.
As there's no content in my-benchmark/src/
, I don't think 2 helps our issue.
Could 1) also be modelled with an application that depends on the library, uses some APIs, and then microbenchmark tests from its androidTest are doing the profiling?
We experimented with this years ago when we started the project, it could work conceptually, but the issue is that the androidTest dir build wasn't factored into the tree shaking step, so every test had to be accompanied by manual keep rules/annotations to the code it invodes. I'd be fine having to specify keep rules for JUnit and @Test methods, but if we wanted libraries to be minified, they had to be in the app, and the benchmark had to cross that test/apk boundary constantly.
Another option we explored was declaring each test twice (as a @Keep
function in src/
and wrapper in androidTest/
so Studio could see/run the test method). which technically worked, but was similarly cumbersome.
rk...@google.com <rk...@google.com> #16
I think I have all requirements right now.
- library androidTest: there is a single APK AGP produces, and this would allow you to run R8 on both androidTest code and its runtime classpath (which includes all of its dependencies&main). Every class from your tests would be an entry point. Also, when
main
component of the library is processed with R8, we'd apply its mapping file. - application androidTest: we produce 2 APKs, so R8 runs on androidTest code and its runtime classpath (includes only its dependencies, and all duplicate libraries from main are removed). Every class from your tests would be an entry point. Also, when
main
component of the application is processed with R8, we'd apply its mapping file.
Is this a correct summary? If so, we can de-duplicate?
P.S. Related to issues with taking test usages into account when running R8 on application code, this is
ma...@gmail.com <ma...@gmail.com> #17
Yes, thanks, duping against
rk...@google.com <rk...@google.com> #18
IIUC, for library androidTest, we are going to run R8 for its program code(e.g. my-benchmark/src/
suppose it is not empty) together with androidTest code and other dependencies, right?
If so, I think
enable it on the test apk for libraries. I do not want progaurd to run on the library itself, however.
which seems to suggest the program code should not be minified.
ma...@gmail.com <ma...@gmail.com> #19
I do not want progaurd to run on the library itself, however.
My reading of this statement on that bug is that they don't want the library's .aar or .jar to be minified (as part of the actual library build), but they DO want the library minified as part of the library test build, which is why I agreed with the duping suggestion.
From a later comment, comment13:
The original comment is pretty clear that it's for libraries which do not want to run R8 on their main code but want to on their test APK to validate things like the embedded rules.
Testing embedded rules implies that the .aar/.jar from the library won't be minifed, but they want to test an environment where the library is minified when embedded in an apk, via the tests.
rk...@google.com <rk...@google.com> #20
Thanks for the insights, Chris. Can you also clarify what are the embedded rules? keep rules shipped with the library?
rk...@google.com <rk...@google.com> #21
Yes, rules shipped with the library.
ma...@gmail.com <ma...@gmail.com> #22
When it comes to introducing the new dsl, we are considering making it more specific, rather than using "minify". So I would love to confirm with you what you want r8 to do. e.g. codeShrinking, obfuscation?
rk...@google.com <rk...@google.com> #23
We want all of the r8 functionality, since we want to be able to mirror the behavior in apps (either for correctness testing or for performance testing).
My suggestion would be for library test configuration to match app DSL, for consistently and simplicity. As things change in the app r8 dsl, we could have the library r8 dsl mirror it (e.g.
ma...@gmail.com <ma...@gmail.com> #24
I'm sorry but I only have high level knowledge of this stuff so I can't help much when it comes to linux drivers. But I'll be happy to try out any pre-release should this be of help!
rk...@google.com <rk...@google.com> #25
I believe this is not a kernel, but some weird assumptions in qemu which break if we open a device moments before using it or in a wrong thread. If you happen to have a linux machine and willing to build and play with our emulator, we will be happy to take a patch from you :) From here I will be working on virtio-snd first and then I will try to figure out if we can -no-microphone
.
ad...@linkedin.com <ad...@linkedin.com> #26
This looks like not an easy issue to fix! I also personally dislike fixing race-condition bugs by adding delays as these bugs could resurface back after some time.
Do you think we could disable mic by default and add an option to manually enable it for those who need it? The audio recording isn't a main stream feature for many developers
rk...@google.com <rk...@google.com> #27
This looks like not an easy issue to fix! ... as these bugs could resurface back after some time.
I agree :(
we could disable mic by default
If we go this way, we probably want to add an option to disable it.
ad...@linkedin.com <ad...@linkedin.com> #28
If we go this way, we probably want to add an option to disable it.
This also works, at least we could disable mic manually and have the sound quality back. Do you think you could use it as a short term fix while you are looking for a better solution?
rk...@google.com <rk...@google.com> #29
a short term fix while you are looking for a better solution?
I'll talk about it on our weekly meeting on Tuesday.
dm...@gmail.com <dm...@gmail.com> #30
ad...@linkedin.com <ad...@linkedin.com> #31
rk...@google.com <rk...@google.com> #32
rk...@google.com <rk...@google.com> #33
I figured out how to pass runtime values into virtio-snd
and hda-duplex
, we should be able to avoid opening the microphone in those devices. When I tried the same with goldfish_audio
, the QEMU says -device goldfish_audio,debug=42: Parameter 'driver' expects pluggable device type
. We probably want to retire (not sure if we can just disable it) this device instead of hacking it further.
rk...@google.com <rk...@google.com> #34
I merged a
ma...@gmail.com <ma...@gmail.com> #35
"Sounds like" (pun intended) a very good improvement!
BTW: What decides which audio driver to use (I mean with which logic virtio-snd
or hda-duplex
or goldfish_audio
is used) ?
be...@gmail.com <be...@gmail.com> #36
rk...@google.com <rk...@google.com> #37
What decides which audio driver to use?
virtio-snd is a drop-in replacement for Intel HDA, but the linux driver is required. If
if this fix will apply to me (I'm using an M1 mac) and
Yes, it will apply for Apple M1.
when the fix will go out?
I still need to figure out what to do with goldfish_audio if our leads will not buy my change to disable the microphone permanently on goldfish_audio. One everything is merged, we should release the changes into the canary channel in weeks.
ma...@gmail.com <ma...@gmail.com> #38
Cool thanks!
If the system image says it has the driver, then we use the virtio-snd device
Do you know from which API do system images ship with the linux virtio driver?
rk...@google.com <rk...@google.com> #39
T is the first system image with virtio-snd drivers.
ma...@gmail.com <ma...@gmail.com> #40
Super! To sum it up: with any emu image with at least api26 the mic will obey the hw.audioInput
setting in the .ini file otherwise (for older emu images) the mic will always be disabled. Correct?
rk...@google.com <rk...@google.com> #41
Unfortunately we create the goldfish_audio device unconditionally, it is not even a sound card from the qemu point of view, it just happens to call the audio API. I disabled the microphone in goldfish_audio
rk...@google.com <rk...@google.com> #42
All changes are merged and available in the 8513367 emulator build. I checked our system images, on x86 the microphone issue should be fixed on API23 and later, on arm ones - API29 and later. We will see if we can fix our older arm system images (API28 and older).
rk...@google.com <rk...@google.com> #43
To disable the microphone you want to add hw.audioInput=no
to config.ini
in the AVD folder.
ji...@gmail.com <ji...@gmail.com> #44
Following along from #43, I figured I should mention I recently opensourced the tool I built to quickly enable and disable the hw.audio*
(and other) settings on the various emulators I use for day to day development:
A checkbox just makes life a bit easier than constantly going in and hand editing .ini files.
Thanks for your work on this ticket and #37095756 over the last couple of years, appreciate it.
ma...@gmail.com <ma...@gmail.com> #45
All changes are merged and available in the 8513367 emulator build.
Is this build downloadable somewhere?
Is there a target version in which we can expect this fix to land in (I'm currently using emulator v 31.3.2)?
rk...@google.com <rk...@google.com> #46
Is this build downloadable somewhere?
While there is nothing secret there, I am not sure how to share it with you until we release the usual way.
Is there a target version
I don't know yet. Our emulator version is something like 31.3.7-8408431
, the build number is after the dash.
rk...@google.com <rk...@google.com>
ma...@gmail.com <ma...@gmail.com> #48
Thank you, I was able to access a build and I could verify on my machine that the issue has been resolved. thank you very much everyone again for listening to our comments until here!
ma...@gmail.com <ma...@gmail.com> #49
Hello,
emulator 31.3.8 build 8598121 just landed in the canary channel.
Can you please check if it includes this fix?
Writing hw.audioInput=no
in config.ini
and using an API32 image still produces the BT audio switch when launching the emu.
rk...@google.com <rk...@google.com> #50
Got log says 31.3.8 should include my change to fix this issue. Unfortunately I am out of the office and cannot check this.
rk...@google.com <rk...@google.com> #51
I confirm, 8513367
does not affect BT audio quality, while 8598121
does affect.
rk...@google.com <rk...@google.com> #52
rk...@google.com <rk...@google.com> #53
Here is what happened: the last time we cut a new release was April, 4. Since then we have been doing cherry-picks which I have not requested before. With the cherry-picks requested this fix is available in 31.3.9 which should be published by the end of this week or the next week.
rk...@google.com <rk...@google.com> #54
Ranjit, could you please confirm this fix is available in 31.3.9?
You need bluetooth headphones for it.
- Connect the headphones to the host.
- Start some audio on the host (e.g. a youtube video with good audio quality).
- Coldboot an emulator (you can use any system image, e.g. S), notice host's audio quality drops when the emulator starts.
- Add
hw.audioInput=no
to the AVD'sconfig.ini
. - Coldboot the emulator again, check if host's audio quality is unaffected.
ra...@google.com <ra...@google.com> #55
I verified with steps mentioned on #54 on Mac Intel(macOS Monterey with Version 12.4) and Mac M1(macOS Big Sur with Version 11.6.6)
With hw.audioInput=yes observed the following issues on both Mac machines.
1) When I cold boot AVD the audio on the host stops for a bit and then continues. There is a change in audio quality.
2) When I do wipe data on the AVD the audio on the host breaks for a bit.
After updating hw.audioInput=no to the AVD's config.ini the issues are resolved. I neither see change in the audio quality nor the audio breaks on the host machine.
ma...@gmail.com <ma...@gmail.com> #57
I can confirm 31.3.9 is now available from the canary channel and that it includes this fix. Thanks a lot for making this happen!
bo...@gmail.com <bo...@gmail.com> #58
rk...@google.com <rk...@google.com> #59
The fix should be available on M1 as well, it is in the 31.3.9 version. What is your emulator version?
ma...@gmail.com <ma...@gmail.com> #60
I confirm I've tested it with 31.3.9 on M1 processor and it's working.
ja...@edg.com.au <ja...@edg.com.au> #61
ma...@gmail.com <ma...@gmail.com> #62
Did you tweak the .ini file as it was explained in this long thread?
rk...@google.com <rk...@google.com> #63
Hi Jamie, it should be fixed, please add hw.audioInput=no
to AVD's config.ini
file for API32 and below. It is not required for API33 and above. There are some other quirks there (in API33) as I am learning about QEMU audio API behavior (the QEMU and kernel disagree on how audio is consumed).
sh...@gmail.com <sh...@gmail.com> #64
It is not required for API33 and above
Using API 33 but the sound quality still drops
rk...@google.com <rk...@google.com> #65
shalva258, could you please elaborate? I just created API30 and API33 on Mac and I can hear that API30 affects audio in my bt headphones when the emulator starts and API33 does not. Maybe update the emulator? I tried on 32.1.3.
sh...@gmail.com <sh...@gmail.com> #66
sh...@gmail.com <sh...@gmail.com> #67
rk...@google.com <rk...@google.com> #68
Try installing
> Is not this the version that should have fixed this?
You want at least 31.3.9.
[Deleted User] <[Deleted User]> #69
[Deleted User] <[Deleted User]> #70
حذف الكل
pa...@outlook.com <pa...@outlook.com> #71
It's freaking 2024, the original issue from 2016 that was marked as fixed was definitely not fixed, this one wasn't either. Windows 10, using emulator 34.2.14-11834374 and this beyond intrusive problem is still there. Good luck trying to share your emulator screen on a meeting and keep your audio and mic working without problems, you won't because this insanely dumb bug is still present to this day and it takes over your audio input forcing hour headset into hands-free mode when you don't want to.
rk...@google.com <rk...@google.com> #72
Hi particlecore,
It's freaking 2024, the original issue from 2016 that was marked as fixed
The original issue is fixed.
Good luck trying to share your emulator screen on a meeting and keep your audio and mic working without problems
This is a separate problem which we have never heard before. Please file a new bug (specify which meeting software you use).
Description
OS: macOS 11.2.3 Emulator version: 30.5.3 Image: x86_64 with play store
I use a tool that monitors audio devices activity. I see that it notifies me about my microphone is active
Steps to Reproduce:
Please check the attachments.