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.
This is a big problem, we have very good reasons for wanting to keep
these as separate projects, so can someone please suggest a way to
make this work?
The solution is to edit the project containing the code to only be
"library" project. This is a concept we don't support yet, but you can
make them manually by editing .project to remove the Android nature
and builder (in the message I linked I mistakenly mention editing
.classpath when it's .project you need to edit).
On Mon, May 18, 2009 at 4:46 PM, Peter Jeffe <pje...@gmail.com> wrote:
> 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.
> This is a big problem, we have very good reasons for wanting to keep
> these as separate projects, so can someone please suggest a way to
> make this work?
> -- Peter
-- Xavier Ducrohet
Android Developer Tools Engineer
Google Inc.
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!
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?
I 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
project.
- 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
Builder".
Note that the Ant build file will require to know where the SDK is. This is
accomplished by a file called local.properties placed in the root of your
folder.
You can run the "android update project" command to generate it (see
http://developer.android.com/sdk/1.5_r1/upgrading.html#AntUsers for more
information)
If you use a source control system:
- do not submit local.properties 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 project. Most people I've talked to
didn't even realize the issue with resources IDs. It seems you are one of
the few who paid attention to it and made sure to make it work properly,
while still using complex features (like build aidl).
When we realized the problem (when we added support for running JUnit test
in a separate project), we remove it to prevent people from doing something
they shouldn't be, but also to make the JUnit feature properly work (you
don't want to have the code of the application you are testing inside your
instrumentation project).
We (now) completely realize we need to have a built-in way to support this,
and we'll add it to the next version. At this point however, we can't
provide a quick fix. Hopefully the work around (either the simple one as
linked in my previous message, or this one with the Ant build file) will
work for you until we provide a better mechanism.
On Tue, May 19, 2009 at 5:28 PM, Peter Jeffe <pje...@gmail.com> wrote:
> 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
-- Xavier Ducrohet
Android Developer Tools Engineer
Google Inc.
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 have other responsibilities than read the Google groups all day long.
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.
> That said, I've been looking for a work around.
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.
On Wed, May 20, 2009 at 8:12 AM, Peter Jeffe <pje...@gmail.com> wrote: > 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.
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.
> 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.
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?
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.
|
