Status Update
Comments
ma...@gmail.com <ma...@gmail.com> #2
I don't think the average developer understands the distinction between method references and method definitions in this context (inside a DEX file). I know I don't.
@jvg, can you elaborate?
je...@google.com <je...@google.com>
je...@google.com <je...@google.com> #3
people who are looking at the bytecode in the dex to optimize their app through shrinking hopefully will learn the difference as string tables for method references between various dex files can account for quite a bit of disk space. but more importantly a definition is something you can analyze its code for where a reference you can't so the UI can be confusing without seeing the difference
je...@google.com <je...@google.com> #4
How about something like this?
I think having defined members be directly under the class node while references are nested in a group makes more sense.
Also note that the method refs have a
an...@google.com <an...@google.com> #5
sounds reasonable to me, thanks
je...@google.com <je...@google.com> #6
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Ladybug Feature Drop | 2024.2.2 Canary 4
- Android Gradle Plugin 8.8.0-alpha04
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
Description
SourceDirectories.addGeneratedSourceDirectory
works the same way as the artifact API and takes over the output for the tasks. For example in thetoml/gen
), running the verification task shows that the location is changed tobuild/generated/toml/debugAddCustomSources
.It does in fact work if you pass this to multiple variants. For instance changing the recipe to something like this:
will in fact works. However the look of the API make it looks like it would not work.
Part of this is the way some of our other APIs work (for example transforms on Artifact are very variant specific).
At the very least we should document that it can in fact be used for multiple variantss. We should also consider making it more obvious (maybe the API just needs to receive a
Provider<Directory>
, though I think there are potentially issue as the location should be inbuild/
?)