Fixed
Status Update
Comments
sh...@google.com <sh...@google.com> #3
Thanks for the feedback. It is the limitation of our tool at this moment, but it's on our backlog to address in the future.
ci...@gmail.com <ci...@gmail.com> #4
Anything on this?
sh...@google.com <sh...@google.com> #5
Thanks for the ping. This hasn't been prioritized at this moment. We are investigating how best to improve the memory profiler including this request.
gc...@gmail.com <gc...@gmail.com> #6
I don't understand... this IS how to best improve the profiler. It should be able to find leaks.
Can you at least provide a workaround?
This is the basis of a lot of ill behaved apps.
And for us that bother looking for leaks this is just not good enough.
Some help would be really appreciated.
Thanks
Can you at least provide a workaround?
This is the basis of a lot of ill behaved apps.
And for us that bother looking for leaks this is just not good enough.
Some help would be really appreciated.
Thanks
gc...@gmail.com <gc...@gmail.com> #7
For people looking here...
I guess as mentioned on the linked issue in #2 a workaround is to:
*) save an hprof with latest AS (for example 3.4).
*) use AS 2.3.3 and open the hprof with that.
you can then find the root with meaningful attribution to the holding package/class.
FYI the root would be with depth 0 and it is easy to spot in AS 3.4 but the attribution to the owning package/class is not enough to find the culprit.
With 2.3.3 it is crystal clear!
I guess as mentioned on the linked issue in #2 a workaround is to:
*) save an hprof with latest AS (for example 3.4).
*) use AS 2.3.3 and open the hprof with that.
you can then find the root with meaningful attribution to the holding package/class.
FYI the root would be with depth 0 and it is easy to spot in AS 3.4 but the attribution to the owning package/class is not enough to find the culprit.
With 2.3.3 it is crystal clear!
sh...@google.com <sh...@google.com>
sh...@google.com <sh...@google.com> #8
Thank you for the crystal clear feedback. Leak detection is surely on our to-do list.
gi...@gmail.com <gi...@gmail.com> #9
Is there any ETA for adding the Analyzer task back into the profiler?
sh...@google.com <sh...@google.com> #10
girishiitj@gmail.com: Thanks for the question. As a general rule, we don't comment on release schedule. But I can assure you that Analyzer Task has a high priority on our to do list.
sh...@google.com <sh...@google.com> #11
Leak activities + fragments detection is now brought back since 3.6 canary 10 (https://developer.android.com/studio/preview/index.html ).
Please give it a go and let us know if you run into issues. Thanks!
Please give it a go and let us know if you run into issues. Thanks!
sh...@google.com <sh...@google.com> #12
Marking this as fixed now. Please re-open if you run into issues!
Description
After profiling the memory of an app and saving the hprof file under the captures directory, opening the file via the Captures tab brings in the Heap Dump results.
However, the "Analyzer Tasks" are nowhere to be found so there is no way to find memory leaks.
Is this a bug or was the functionality removed?
Searching for the term "Analyzer Tasks" for AS does not bring any useful results.
Thanks