Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
Original comment by connor.tumbleson
on 19 Oct 2014 at 5:53
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
Hmm. Removed that dependency and its still 5.9mb.
Will check more.
Original comment by connor.tumbleson
on 19 Oct 2014 at 6:44
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
Original comment by connor.tumbleson
on 20 Oct 2014 at 11:53
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
Cool can I ask what was actually causing the bloating
Original comment by raziel...@gmail.com
on 21 Oct 2014 at 1:46
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
Original issue reported on code.google.com by
raziel...@gmail.com
on 18 Oct 2014 at 1:48