Memory usage problem

[GoogleCodeExporter]

Hi all.

We are trying to use baksmali to disassemble DEX files directly on the phone. 
The problem is that there are tight resource constraints, and currently 
baksmali always disassembles the entire DEX file into a DexFile object, which 
grows very large. I wonder if there is a way to disassemble individual classes 
from the DEX file, one at a time.

Thanks in advance!

Original issue reported on code.google.com by eric.bod...@gmail.com on 10 Aug 2012 at 10:48

[GoogleCodeExporter]

Currently: no, it's not possible, unfortunately. I am aware of this problem, 
and I do want to support that style of usage, with maybe some sort of on-demand 
loading of individual items.

Original comment by jesusfreke@jesusfreke.com on 14 Aug 2012 at 6:38

• Changed state: Accepted

[GoogleCodeExporter]

Thanks a lot for your feedback! Could you roughly let me know within which time 
frame you are planning to support this?

Original comment by eric.bod...@gmail.com on 14 Aug 2012 at 9:29

[GoogleCodeExporter]

Hello.

This issue has become quite a blocker for us. It really keeps us from 
progressing. We would be more than willing to devote some man power and help 
fix this if you could let us know in which way to proceed. What would be a good 
way to go about this?

Original comment by eric.bod...@gmail.com on 11 Sep 2012 at 7:37

[GoogleCodeExporter]

I had started some work on this, but didn't get very far - I was still in the 
experimental stage, trying out various ideas to see what paradigm might work 
best. And then I got side-tracked by other ideas/features that I found more 
interesting :)

If you want to implement something yourself, I would say define a reader-only 
interface, and provide an implementation that is separate from the current 
implementation. Obviously, per your requirements, each section would need to be 
able to read in an individual item on demand (rather than reading it all in at 
once).

As a quick example of how that might work, you would have an IndexedSection and 
OffsetSection class that offer something like getItemByIndex and 
getItemByOffset methods, which read the data at the given index/offset and a 
construct item of the appropriate type for that section on-demand.

And then, in an individual item implemention. Let's take ClassDefItem, which 
has a reference to a ClassDataItem. When the ClassDefItem is created, it will 
read in the raw pieces of data from the buffer, and save them as local fields. 
So it will have an offset to ClassDataItem in a field somewhere. ClassDefItem 
would then have a getClassData() method, which would call something like (very 
pseudo-code-ey): 
dexFile.getSection(CLASS_DATA).getItemByOffset(classDataOffset).

Alternately, You could even provide a slightly higher level api - instead of 
exposing things like class_def_item and class_data_item separately, you could 
have a single class interface that exposes all the information about a given 
class.

If you do start working on this, I'm happy to review incoming changes. Feel 
free to commit early and often - either to your own fork somewhere or to a 
branch in this repository, it's up to you. I would much rather get lots of 
small changes along the way, than a single huge drop at the end. It's not only 
easier to review, it's much better to be able give feedback on the general 
design earlier, rather than later :)

Original comment by jesusfreke@jesusfreke.com on 12 Sep 2012 at 2:53

[GoogleCodeExporter]

The new 2.0 release has a completely rewritten dexlib that supports a much more 
memory-efficient method of iterating over a dex file while disassembling

Original comment by jesusfreke@jesusfreke.com on 7 May 2013 at 8:14

• Changed state: Fixed