title: Android .apk doubles size depending on dev box used to deploy since v17 tools
body: <p>After updating to ADT r17 tools, we're having the issue of some dev boxes with classes.dex file within the .apk being 3.2MB vs 700KB. In addition to the inflated dex file, the application can't be launched from a device. It spits out a ClassNotFoundException. </p>
  
  <p>We're at a loss, since all project/eclipse settings appear to be the same across dev boxes.</p>
  
  <p>The project itself consists of two library projects and main project with the supportv4.jar and an in house jar. </p>
  
  <p><em>Update</em></p>
  
  <p>I chose the export the library projects and the jars (in the main project) and it works when it deploys onto the device, the .apk is still double the size. Another fun part is (on the boxes it doesn't work) we have a 50% fail rate on launching (that is eclipse freezes). So it is still essentially unusable still.  At r16 tools there was no problem on any box getting it to build and launch.</p>
  
  <p><em>Update v0.2</em></p>
  
  <p>I had library project 1 depend on library project 2 and added the neccesary jars only to lib1. It launches and runs, but still takes 3-4 minutes per change to the source to recomplie/build/deploy and the apk is still x2 the normal size. </p>
  
  <p><em>Update v0.3</em></p>
  
  <p>Even more fun, it will compile quickly via the command line, but not via eclipse. I'm still getting a very large .apk (7.16MB vs 3.xxMB for a previously "normal" apk).</p>
  
  <p><em>Update v0.4</em></p>
  
  <p>Turns out, even with an updated sdk/adt some box's eclipse are using adt 15/16 (help-> about eclipse -> instillation details) with no complaints. Those were the functional boxes.... </p>
  
  <p><strong>UPDATE V0.5</strong></p>
  
  <p>They released tool r18 today which "remedy" the issues, but the apk is still twice the "original" size and the build takes quite a while to complete. We ended up consolidating the project to one project, not a satisfactory answer by a long shot, but we couldn't waste any more cycles debugging our tools.</p>