• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[DevTOOL][2012-10-01] Fast AAPT (#2) - Speed up Eclipse/apktool/etc

Search This thread

lockzackary

Senior Member
Jan 24, 2011
147
10
San Pedro
chainfire - you're a god!

anyways, for a productive post, it really is faster now. very much noticeable when the project contains a lot of assets (mine was around 14mb of assets and before it builds with the "pause" you were referring to on your post)
using faapt it just cleans builds in like 2 seconds

thanks for your awesome work :)
 

StErMi

Member
Feb 2, 2011
17
3
I'm using Ubuntu 12.04 x64 version with latest eclipse (stable), latest adb (stable) and sdk version.

Maybe it's be that I don't understand restrictions of your aapt version.
If I use your faapt it would not compile as always, I notice that R.java is not regenerated well and my projects show those errors.

With faapt I can only build but not clean? Or my is an example of not-stable-faapt?
 

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,442
87,710
www.chainfire.eu
I'm using Ubuntu 12.04 x64 version with latest eclipse (stable), latest adb (stable) and sdk version.

Maybe it's be that I don't understand restrictions of your aapt version.
If I use your faapt it would not compile as always, I notice that R.java is not regenerated well and my projects show those errors.

With faapt I can only build but not clean? Or my is an example of not-stable-faapt?

Could be the linux compile, could be many things. If you want to figure it out, jump on IRC.

(I don't have much time though, leaving for Paris for the weekend in a bit)

EDIT: turned out to be a permission problem (doh), nothing to see here.
 
Last edited:

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,442
87,710
www.chainfire.eu

KOJANHQ

Senior Member
Apr 30, 2010
124
50
California
After compiling faapt (Patched aapt from android source) on Mac OS X i get Bus error: 10:

...snip...

Can someone help me with compiling on Mac OS X?
 
Last edited by a moderator:

DieBagger

Member
Aug 27, 2010
7
3
Holy sh**, android development has just become fun again... Really compile times have gone way done with this patch... Only problem, now I can't get coffee while I wait for eclipse to re-compile.. ;)

thx a lot!
 

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,442
87,710
www.chainfire.eu
After compiling faapt (Patched aapt from android source) on Mac OS X i get Bus error: 10:
Code:
#include "ResourceIdCache.h"

struct lutEntry {
    String16 package;
    String16 type;
    String16 name;
    bool onlyPublic;
    uint32_t resId;
};

typedef struct lutEntry t_lutEntry;

// more than enough... uses about 100kb of memory
static const int lutCapacity = 4096;
static t_lutEntry lut[lutCapacity]; //bus error: 10
//t_lutEntry * lut = new t_lutEntry[lutCapacity]; //bus error: 10
static int lutUsed = 0;
Can someone help me with compiling on Mac OS X?

I've not been able to compile the SDK on my OS X VM at all, so I can't help you directly. Not sure why this would throw a "bus error", it's a relic of the past that has no place in modern computing.

First, revert to the original code, as I see you made some changes.

(1) Try reducing lutCapacity to 256 (should still be enough for most projects) in case it's a heap allocation problem.
(2) If that doesn't work, try changing the onlyPublic bool to a uint32_t (and change some code), or change both onlyPublic and resId to to uint64_t if you're compiling to 64 bit executables... in case it's an alignment issue (as should be the case when you get a bus error, but shouldn't happen with this code, and I've read is regularly not the actual cause of a bus error on OS X).
(3) Try removing the "static" keywords, see if that helps

If any of those things fixes the problem, do let us know ...

Are you sure the bus error occurs at allocation? If not, at which access? If you know which iteration it happens...
 

KOJANHQ

Senior Member
Apr 30, 2010
124
50
California
I've not been able to compile the SDK on my OS X VM at all, so I can't help you directly. Not sure why this would throw a "bus error", it's a relic of the past that has no place in modern computing.

First, revert to the original code, as I see you made some changes.

(1) Try reducing lutCapacity to 256 (should still be enough for most projects) in case it's a heap allocation problem.
(2) If that doesn't work, try changing the onlyPublic bool to a uint32_t (and change some code), or change both onlyPublic and resId to to uint64_t if you're compiling to 64 bit executables... in case it's an alignment issue (as should be the case when you get a bus error, but shouldn't happen with this code, and I've read is regularly not the actual cause of a bus error on OS X).
(3) Try removing the "static" keywords, see if that helps

If any of those things fixes the problem, do let us know ...

Are you sure the bus error occurs at allocation? If not, at which access? If you know which iteration it happens...

I found solution:
Code:
//
// Copyright 2012 The Android Open Source Project
//
// Cache for resIds - we tend to lookup the same thing repeatedly
//

#include "ResourceIdCache.h"
#include <vector>

struct lutEntry {
    String16 package;
    String16 type;
    String16 name;
    bool onlyPublic;
    uint32_t resId;
};

//typedef struct lutEntry t_lutEntry;

// more than enough... uses about 100kb of memory
//static const int lutCapacity = 4096;
//static struct lutEntry lut[lutCapacity];
std::vector <lutEntry> lut;
static int lutUsed = 0;

uint32_t ResourceIdCache::lookup(const String16& package,
                                 const String16& type,
                                 const String16& name,
                                 bool onlyPublic)
{
    for (int i = 0; i < lutUsed; i++) {
        if (
            // name is most likely to be different
            (name == lut[i].name) &&
            (package == lut[i].package) &&
            (type == lut[i].type) &&
            (onlyPublic == lut[i].onlyPublic)
        ) {
            return lut[i].resId;
        }
    }
    return 0;
}

bool ResourceIdCache::store(const String16& package,
                            const String16& type,
                            const String16& name,
                            bool onlyPublic,
                            uint32_t resId)
{
    lut.push_back(lutEntry());
    lut[lutUsed].package = String16(package);
    lut[lutUsed].type = String16(type);
    lut[lutUsed].name = String16(name);
    lut[lutUsed].onlyPublic = onlyPublic;
    lut[lutUsed].resId = resId;
    lutUsed++;
    return true;
}
 

dzn

Member
Nov 23, 2009
22
2
Hey,

Disclaimer: this might just be me missing a readme somewhere or doing something wrong!

I've been building K-9 ( android e-mail client ) since 2 years, when I read about this I tried it. Just swapped out the aapt binary on my linux system. Ever since I had resource troubles ( weren't found in the app ). Only when I switched back it worked again. I'm back at the default aapt for now, just letting you know.

thx
 

Top Liked Posts

  • There are no posts matching your filters.
  • 113
    Presenting: Fast AAPT - aka FAAPT ;)

    Lately Android development has been getting me down. Slow builds all over the place in many of my app projects, and my PC is blazing fast - it shouldn't all be that slow, even if you're running Eclipse!

    Working on DSLR Controller has been driving me mad - testing a minor change in the underlying communications library, then building and launching the app - ugh! So I set out to fix this. I had done all the usual tricks, even gave Eclipse loads more memory (helped with regular performance, but not building) but nothing major seemed to change. Then I figured out most of the time building was spent in AAPT. So I synced my AOSP repo (2012.09.26, took a few minutes), tried to get the Windows SDK to build on my Linux box (took several hours) and finally got to actually mucking with the source.

    Found the bottleneck (for my long-build-time projects at least, related to XML file compilation) and fixed it (by introducing a simple cache). "DLSR Controller" build time has gone down from 35 seconds minimum, to 2-3 seconds ( >10 times faster). Hell, I can even turn "Build Automatically" back on without getting constant delays!

    Note that my build times quoted only apply to incremental internal builds. If your images still need to be "crushed" (optimized), or you're "exporting" an APK (final build for publication), build time will still be significantly longer. However, during normal development and testing (by far most builds if you're making an app in Eclipse) those stages are not performed, and builds should be lightning fast.

    "Fixed" is a big word though, right now it's more of a "hack", and it needs some pollish, so the patch can be submitted to AOSP. I don't want to keep it from you for that long, so my first test build is attached - don't use it in production builds..

    Patch code has been submitted to:
    AOSP - #1 Cancelled, #2 Review in Progress ... superseded by ctate rewrite
    AOKP - #1 Merged, #2 Merged
    CM - #1 Cancelled, #2 Merged

    Attached ZIP includes Linux, Windows and Mac OS X versions.

    The files are drop-in replacement, but I would certainly advise you to backup the originals for your production builds! :) Also, don't forget to chmod/chown on Linux or it won't work.

    Enjoy and leave some feedback :)

    Will this help your project build ?

    A quick way to spot if this will have effect on your slow build is as follows:

    - In Eclipse, set Build output to Verbose under Window -> Preferences -> Android -> Build.
    - Clean and build your project.
    - If the build pauses on lines in the "(new resource id <filename> from <filename>)" format, you have the problem FAAPT fixes :)

    (of course, you can also run aapt manually if you know how, you'll get the same output)

    In a full framework build the optimizations only affect a very small portion of the actions done during the build, so you won't see any spectaculair speed increases there.

    Update (#2)

    I have updated the patch code to fix problems with Mac OS X compatibility, I've also included a Mac OS X binary in the new zip file.

    -----

    ( v1: 557 )
    2
    Thanks brother, gonna give it a try right now on Linux :)

    EDIT:

    It works. Gave it three tries. Went consistently around 19.1 sec with FAAPT and 33.9 sec with regular AAPT. This is on the Linux version. Good job :)

    Glad to hear the Linux version also works! Too bad your increase is not as much as mine, but I guess it depends heavily on the amount and type of assets in your project.
    2
    The patch is indeed in the very latest ADT tools !
    2
    apktool and Maps.apk on Linux.
    aapt - 29.2s to compile
    faapt - 2.2s to compile
    Amazing job, Chainfire!
    2
    Hey,

    Disclaimer: this might just be me missing a readme somewhere or doing something wrong!

    I've been building K-9 ( android e-mail client ) since 2 years, when I read about this I tried it. Just swapped out the aapt binary on my linux system. Ever since I had resource troubles ( weren't found in the app ). Only when I switched back it worked again. I'm back at the default aapt for now, just letting you know.

    Will try to reproduce and fix :)

    Note sure what is going on here. I have installed the sources and dependencies on my Windows system (my Linux system is currently not equipped to build stuff like this, will try later) and produced files both in aapt as well as in faapt mode - with identical results.

    I'm going to try this on my pc running linux

    Any chance for arm version ?

    The patches have been posted/submitted (see first post, AOKP currently has a full up-to-date merge), feel free to build an ARM version yourself - I'm not planning to.