-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vastly different file sizes 0.5.0->0.5.1 #27
Comments
This is expected with the current status of the CompactDex exports. The 0.5.0 release was not properly including all the necessary data sections, thus I've adjusted the file exporter logic to include the necessary regions from the shared data section of the matching Vdex container. I've missed this bug since I was processing the CompactDex files from within the mmaped Vdex file, so the shared data section was already loaded with all the data sections. However, when I was experimenting yesterday to offline process the Cdex exports with a dexlayout binary I'm working, I noticed the missing sections. The explanation behind this reverse exponential size growth is related to how the deduplication logic works. The first Dex file in a Vdex container has no deduplicated items since its the first occurrence of all data structs (Strings, CodeItems, etc.). Therefore the data size is the same as the original Dex. However, the 2nd Dex file has new data items (owned data section) and deduplicated items that are present in the owned data section of the 1st Dex file. Therefore, to not miss any data structs we need to copy the owned data sections of both Dex files. For the 3rd Dex file, the previous 2 owned data sections and the current, and so on. I've improved the debugging logic in recent commits so you can easily verify by observing the sizes of the data sections of each CompactDex file. For the Google photos app for example the data size of the 1st Cdex is 602a48, the 2nd aca1a8 and the 3rd cacbc8 (the entire shared data container). Hopefully, the dexlayout IR will remove the dead items when converting the IR back to StandardDex. Otherwise, ROM developers will have a huge perf/size impact. Now all the exported Cdex files can be processed with the dexdump2 utility as compiled from AOSP sources (not the SDK one). Now I'm more confident the ART file parsers are happy with the decompiled Cdex files that the tool exports, so I can continue with the dexlayout extensions
|
Thanks for the detailed explanation, now it makes more sense. |
As described in #23 (comment) the recent changes are working the libdexlayout IR. So closing this is issue, since there is nothing to track. |
It doesn't look right, as classes3 is always the smallest of the three. Perhaps there's some data intersection?
Vdex file: http://www.mediafire.com/file/pn2747p8aaoq7lv/boot-framework.vdex/file
The text was updated successfully, but these errors were encountered: