Changes in ADT 20 break your libgdx Android builds

I love the activity on the ADT project, lots of nice new changes are introduced. They are also reworking the build system. However, in that process, some irritations turned up that made our lives a little bit less enjoyable from time to time. Watch the corresponding talk from this years I/O to see where the journey leads.

Since ADT 20 there’s a problem for the common libgdx setup (and other setups where you share code between, say your servlet and your Android app). Scenario: you have an Android project and a standard Java project in Eclipse. The Android project depends on the Java project. If you change things in the Java project and then run the Android project, ADT used to recompile the Android project to include the changes from the dependency. This is no longer the case, you’ll have to clean and rebuild your Android application for it to pick up changes in your Java project.

In any case, if you care enough, please star this issue:

Do not add “me too!” comments, just star the issue and call it a day.

10 thoughts on “Changes in ADT 20 break your libgdx Android builds

  1. I noticed this a while ago and thought it’s a bug in my Eclipse or project configuration so I didn’t even ask about it anywhere. Glad you figured it out, starred. Hope it gets fixed. Not fun to launch Android version, wait for it to upload, install, etc. only to find out I forgot to clean the projects and have to do it all over again.

  2. I downloaded eclipse juno versions multiple times thinking there was a bug in it lol. I guess ADT 20 trolled me o-o

  3. Just another reason to play to libgdx’s strength of developing mostly on desktop. I have to admit I didn’t fully appreciate that strength originally, but it’s a great plus for development. Now I only deploy to device when I need to test specific android platform features. Though this issue would certainly make such occasions more painful.

  4. Yeah! I was almost up to banging my head against something :S when i just sort of rebuild everything and found the updated code running on my device! It’s really a pain to clean up everything before running it everytime! 🙁

  5. Everytime, in the senario you described, I add a space in one of my android files and then run the android app.

  6. The issue will supposedly be fixed in ADK version 21, which is “very close to a final release” ( But until it’s here, here is a workaround.

    Add a file named build-touch-android.xml to the root of the Android project, with the following contents:

    Right-click your main project and choose “Properties”. Click “Builders” to the left, and add a new “Ant Builder”. Name it anything you like (e.g. “touch-android”). Point the “Buildfile” to the “build-touch-android.xml” file you just created.

    On the “Refresh” tab, check “Refresh resources upon completion”, “Specific resources”, and select “AndroidManifest.xml” in the root of your Android project.

    On the “Targets” tab, set the default target (“build-android”) to be invoked on both manual and automatic builds.

    Click “OK”.

    Now every time your main project gets built, the build file is invoked and touches the last-modified time on AndroidManifest.xml. Eclipse subsequently refreshes that file in the IDE, notices that it’s been changed, and rebuilds the Android project as a result. Profit!

  7. I believe this is fixed in ADT 21 preview. If anyone is stuck with this problem (I’ve wasted my whole morning in this) enable the preview versions in the SDK manager and install both the tools and the latest preview of ADT 21.

Leave a Reply

Your email address will not be published.