aapt size difference from build-tools release versions

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Comparing the D:\Android\sdk\build-tools\20.0.0\aapt.exe windows size from 
Android SDK is 862kb
2.
3.

What is the expected output? What do you see instead?
the 
D:\Github\iBotPeaches\Apktool\brut.apktool\apktool-lib\src\main\resources\prebui
lt\aapt\windows\aapt.exe is 6279kb

What version of the product are you using? On what operating system?
using the most recent source and while checking out the API update to 21 i was 
going to update the aapt.exe for a experment and found that the versions for 
apktool is inflated have yet to check the Linux and OSX versions.

this is mainly a question of why such a large inflation in size comparison 

Please provide any additional information below.

Original issue reported on code.google.com by raziel...@gmail.com on 18 Oct 2014 at 1:48

[GoogleCodeExporter]

I just built AOSP with no changes via

lunch sdk-eng
make -j4 sdk

The linux version was 5.9mb and the release one via Android was 1.2mb. Unless 
I'm missing a command, then I don't know. Seeing how you only download apktool 
once anyway, I don't think I'm going to worry about this.

Original comment by connor.tumbleson on 19 Oct 2014 at 5:13

• Changed state: Done

[GoogleCodeExporter]

well i have been following this project since day one before you came into the 
picture it is just that this was the first time i have looked into this section 
of the src to compare to the actual binaries in the sdk to the ones you are 
providing

Original comment by raziel...@gmail.com on 19 Oct 2014 at 5:18

[GoogleCodeExporter]

Original comment by raziel...@gmail.com on 19 Oct 2014 at 5:31

Attachments:

• build-tools.zip

[GoogleCodeExporter]

What does following the project since day one have to do with this bug report? 
The way you worded it looked quite a lot like a personal attack to my running 
of the Apktool project.

---

We have to compile our own aapt to get around some android changes

1) 
https://github.com/iBotPeaches/platform_frameworks_base/commit/adcb933331a1b9ca9
8064d108556478cead77b95 - forced package id

2) 
https://github.com/iBotPeaches/platform_frameworks_base/commit/8abaf4854aac0b667
a8c64924be53be2ec1d600c - no limitation on diFFeReNt capitalization. 

3) 
https://github.com/iBotPeaches/platform_frameworks_base/commit/5006a5b886de0988b
3f6e8a5c6415fb6deddb23c - miui support

None of these changes I see affecting build size by 4mb. Not to mention as I 
said in comment #1, compiling raw AOSP results in the same aapt size as the 
modified aapts. We can't use the stock build-tools aapt, so attaching them 
won't help. You are free to investigate why building AOSP results in a 
different aapt size then what is provided in build-tools.

Original comment by connor.tumbleson on 19 Oct 2014 at 5:40

[GoogleCodeExporter]

I was not attacking i was just wondering why the file size was 6 times the size 
of the aapt in the sdk then this but i will look at the code changes you listed 
above to see why the difference.

I am sorry i came across the wrong way because you are doing a damn good job 
since you took over the project and have helped me better improve my APK 
Multi-Tool project that i started working on since 2009 which is a batch script 
multi-functional tool.

Thanks to you I have been able to remove features from the tools because they 
are now automatically done when you run your code now and with the build in 
aapt files this is also allowed me to remove unneeded binaries to have to have 
people add and many many many other changes and support for more devices and 
with all my   themes and such

Original comment by raziel...@gmail.com on 19 Oct 2014 at 5:50

[GoogleCodeExporter]

Ah. Thanks for noticing this. I have found the problem. I implement the ctype.h 
functions which are hella big which explains the 4mb increase. I had my fork of 
frameworks_base in my roomservice file, so never noticed the different during 
AOSP builds.

I am finding an alternative for isdigit() and will patch this. It should drop 
all the sizes of the 3 included aapts and decrease the overall size of apktool2.

Thanks for the find.

Original comment by connor.tumbleson on 19 Oct 2014 at 5:53

[GoogleCodeExporter]

Original comment by connor.tumbleson on 19 Oct 2014 at 5:53

• Changed state: Accepted

[GoogleCodeExporter]

your welcome

my 36 years on this earth I have always been told The only Dumb questions are 
the ones not asked

Original comment by raziel...@gmail.com on 19 Oct 2014 at 6:00

[GoogleCodeExporter]

Hmm. Removed that dependency and its still 5.9mb.

Will check more.

Original comment by connor.tumbleson on 19 Oct 2014 at 6:44

[GoogleCodeExporter]

Yea that seems strange about the small changes in the commits you listed why 
would something that should only add a few kb add MB's

Original comment by raziel...@gmail.com on 19 Oct 2014 at 7:14

[GoogleCodeExporter]

Original comment by connor.tumbleson on 20 Oct 2014 at 11:53

• Changed title: aapt size difference from build-tools release versions
• Added labels: Priority-Low, Milestone-v2.0
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Okay, the next release of apktool will have this in it. I haven't pushed the 
new binaries yet since they are old. I will wait for Lollipop AOSP then push 
newer smaller (1.1mb) binaries.

Original comment by connor.tumbleson on 21 Oct 2014 at 1:43

• Changed state: Fixed

[GoogleCodeExporter]

Cool can I ask what was actually causing the bloating

Original comment by raziel...@gmail.com on 21 Oct 2014 at 1:46

[GoogleCodeExporter]

My script was pulling the first aapt binary it found during build. The aapt it 
found was the aapt used during the build process to build applications. The 
production aapt is compiled later on in the cycle which my script ignored. 

Simply waiting for the production aapt to be built and using that one solved it.

Original comment by connor.tumbleson on 23 Oct 2014 at 3:06