SDK 1.5 breaks our build

by Peter Jeffe » Tue, 19 May 2009 07:46:15 GMT

Sponsored Links
 Our app is build from three eclipse projects, one of which contains
the Android app manifest, and which includes the other two projects.
Previously this worked just fine, but after upgrading to the 1.5 SDK,
building against a 1.1 target, it now doesn't seem to include the
other projects in the .apk at build time, so now I get "dalvikvm:
Could not find method X" errors when I try to run the app.

BTW this sounds like the same problem that was reported in this

SDK 1.5 breaks our build

by Xavier Ducrohet » Tue, 19 May 2009 08:57:09 GMT

 Please see: 

Sponsored Links

SDK 1.5 breaks our build

by Peter Jeffe » Tue, 19 May 2009 22:58:18 GMT

 Thanks Xavier, sorry I missed that previous discussion.  However, we
need our lib project to be an Android project: it contains an Android
service that is used by the other project.  So I need to be able to
compile the aidl files etc.  I don't have any resources, so there's no
risk of collision between resource IDs between the projects.  But I
definitely need the service!

-- Peter


SDK 1.5 breaks our build

by Peter Jeffe » Wed, 20 May 2009 08:29:25 GMT

 So no help here?  This is very frustrating to say the least.  I've
spent all day trying to hack together a workaround for this, when I
need to be working on my product instead.  And I'm left with a hard-
coded mess instead of a clean build process.

What possible reason could there be for you to release these breaking
changes without warning, and without even any workarounds to offer?
If you didn't like the fact that people could shoot themselves in the
foot with resource ID collisions you could give a warning or
something--you don't need to just break all of us who need to build
our products from separate Android projects.

Can you tell me why this is not a serious problem that warrants an
immediate fix?

-- Peter


SDK 1.5 breaks our build

by Xavier Ducrohet » Wed, 20 May 2009 10:07:56 GMT

  have other responsibilities than read the Google groups all day long.

That said, I've been looking for a work around.

Since you want to build aidl files as part of your build, but cannot have
your project use the project nature, you'll have to manually add a new
builder that does what you want (after you remove the nature and builders
from the .project as indicated in the message I linked)

Eclipse makes it easy if you have an Ant file. I've attached an Ant build
file which is basically a stripped down version of the Ant script used by
people who don't use Eclipse. It only contains the aidl target (and another
target making sure some folders exist)

Now, follow these steps:
- In eclipse, right click on your project with the aidl files and choose
"Properties", and then "Builders" on the left.
- Click New to add a builder, and choose the "Ant Builder" type.
- In the new window, give the builder a name ('aidl' for instance).
- In the "Main" tab
* For "Buildfile", put the attached file in the root of your project, and
choose "Browse Workspace" to select it. This will make sure the build file
path is relative to the workspace, and avoids having hard-coded path in your
.project file.
* For "Base Directory", choose "Browse Workspace" as well and choose your
- In the "Refresh" tab
* You should probably set it to "refresh resources upon completion" to
make sure the aidl generated Java files are compiled by the JDT builder. I
would just select "The project containing the selected resource."
- In the target tab:
* Most cases should have "Default target selected". I had to change
Auto-Build to this as well (click Set Targets...). There's no Clean target
so don't have any for the Clean action (but do keep the default target for
After Clean).
- Click OK, and make sure your new builder is executing before the "Java

Note that the Ant build file will require to know where the SDK is. This is
accomplished by a file called placed in the root of your
You can run the "android update project" command to generate it (see for more

If you use a source control system:
- do not submit as it contains a reference to your local
SDK installation. Each developers should make their own based on their SDK
installation folder.
- submit aild_build.xml
- inside your project you have a folder ".externalToolBuilders", with a
single file named after the name of the builder you added. If you used the
"Browse Workspace" options as I mentioned, it should not contain any
reference to local paths, and you must submit it in your source system (it's
required for the builder to run).

Now, I'll address the issue of why we removed this "feature".
To be honest, I think we underestimated the impact of this change. We didn't
remove it because we don't like you using it. We never actually intended for
it to work, and didn't think people would be using it (much), because, in
most cases, it doesn't work (resource ID collisions).

We added support for referenced project to make it easier to work with
external than using jar files, but we never expected that people would
actually use it to reference Android pr

SDK 1.5 breaks our build

by Peter Jeffe » Wed, 20 May 2009 23:13:03 GMT

 Xavier, thanks for your thoughtful response, and I'm sorry for being
so testy, but please understand that this sort of thing can have a big
impact on developers.  From what you say it sounds like not many
others are configuring their projects this way, but for a product that
supports multiple platforms it's going to be a common configuration.
We have a middle tier that is a service on Android, so the Android
service code needs to live with that project while the presentation
layer, which is completely platform-specific, lives in another.  I
have to imagine we're not alone in this.

I certainly understand, and I think that's a real problem for us all--
the Google developers are trying to support the developer community in
their spare time, and we developers have no recourse other than to
post here and hope someone reads and responds, or submit a bug report
and have almost no chance of a timely response.  I really think Google
needs to create a more mature developer program that has at least pay-
per-incident support and other levels of support for the developer
community, with dedicated support resources.  Having a problem/
solution forum structure also really encourages community experts to
step up and augment the vendor resources--it also clearly
distinguishes problem-solving from general discussion (see
BlackBerry's forums for a good example of this).  If Google doesn't
put this level of investment into building the community then I really
don't believe you can create the kind of ecosystem you need for
Android to thrive.

Thanks very much for the effort, this sounds much cleaner than my hack
so I'll put it in place and see how it goes.

-- Peter


SDK 1.5 breaks our build

by Peter Jeffe » Fri, 22 May 2009 01:54:49 GMT

 That workaround does the job, thanks for the help Xavier!

-- Peter

SDK 1.5 breaks our build

by Dianne Hackborn » Fri, 22 May 2009 02:53:58 GMT


You aren't dependent on Google doing this.  If there is value in such a
thing (money to be made), it seems like a good opportunity for someone to
provide a service.  For what it's worth, I think it is unlikely for Google
to do such a thing itself -- it would be hard to justify giving away more
money to provide significantly more dedicated support people, and trying to
put together a profit making (or just break-even) for-pay support
organization just doesn't seem to fit well with Google's business.

Let's say Google has X amount of money to invest in all of the Android stuff
they are giving away...  would that money be better invested in supporting
device manufacturers to bring out devices, or developers to develop for
those devices?  Certainly at this point in Android's life, I think getting
more devices out is key, so that is the better place to invest.

At any rate, Google is already throwing lots of money in to developer
support, but doing that in ways that get the most bang for the (given away)
buck: SDK documentation, tools, and other high-leverage work.

Personally I am very much of the opinion that you have a strong ecosystem
primarily by having a lot of shipping product (and thus customers for your
developers).  I mean, let's say Android devices have 50% of the market...
if the Android platform manages to provide a fairly consistent API across
those devices, is it going to matter much to the strength of the ecosystem
if someone is providing high quality for-pay third party developer support?

Dianne Hackborn
Android framework engineer

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails.  All such
questions should be posted on public forums, where I and others can see and
answer them.


Other Threads

1. adding Scroll bar

       How to add Scroll Bar to TextView..... ?

2. Replacement for MapView's OnLongPressListener

What is the common replacement MapView's OnLongPressListener ?
OnLongClick does not provide the screencoordinates and adding an
Overlay just to get the coordinates is not the way its meant to be...

Thx in advance

3. Can't call startActivity() - real easy, please help

4. ACTION_PICK_ACTIVITY: anyone have this working?

5. Problem with running emulator - my program won't show up

6. IPsec support in Android

7. How to upload files to Android emulator? How to prepare MediaPlayer?