Status Update
No update yet.
Comments
aa...@google.com
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?
jv...@google.com
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
aa...@google.com
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
jv...@google.com
sounds reasonable to me, thanks
aa...@google.com
an...@google.com
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
1) the methods are a lighter shade of gray if they're just a reference
2) there's no counter for the "defined methods" column.
This is not very discoverable and we had various people at Google I/O be confused about this, especially when they had multi-dex in their APK, looking at classes.dex they saw their methods and were annoyed that the tool didn't allow them to see their bytecode.
We should consider changing this UI to make this more discoverable.
One option: have two separate trees in the view, one for definitions and another for references. where each root node is named as such.