We have an application cut into 3 android projects:
* Project REAL (the real android project)
* Project LIB1 (an android project without any activity, just to make
android reusable classes)
* Project LIB2 (same as LIB1)
LIB1 and LIB2 are android projects rather than J2SE ones because LIB1
and LIB2 use Android classes.
Project REAL has LIB1 and LIB2 in its project build path in Eclipse.
In SDK 1.0 and 1.1, no problem at all when running the project REAL
from Eclipse, it mixes the code of the 3 projects and produces one big
APK with everything in it.
But now in SDK 1.5, it installs 3 different APKs on the emulator or on
the phone (I tested both), and the project REAL immediately crashes
because of a VerifyError: it does not find a class that is in LIB1.
The size of the produced APK is smaller, indeed LIB1 and LIB2 classes
are not in it...
I tried using uses-library in the manifest like google maps library
but it complains at installing, we have a "missing shared library"
error.
I tried adding class folders in build path, it compiles in Eclipse but
we still have a VerifyError.
Same thing if we use external class folders in build path.
The only thing that worked for me was to add an eclipse folder, which
is in fact a symbolic link, and to make it a source folder. But that
solution is not convenient for us because when we share the projects
in SVN, the referenced paths are different for each developer. Using
eclipse path variables can do the trick but it is far from being
convenient. Indeed, if we have to reinstall Eclipse or if we move the
place we check out the code in our developer station we have to
reconfigure all these messy path variables in Eclipse.
Is there a way to restore the old behavior on other android projects
in build path ?
> We have an application cut into 3 android projects:
> * Project REAL (the real android project)
> * Project LIB1 (an android project without any activity, just to make
> android reusable classes)
> * Project LIB2 (same as LIB1)
> LIB1 and LIB2 are android projects rather than J2SE ones because LIB1
> and LIB2 use Android classes.
> Project REAL has LIB1 and LIB2 in its project build path in Eclipse.
> In SDK 1.0 and 1.1, no problem at all when running the project REAL
> from Eclipse, it mixes the code of the 3 projects and produces one big
> APK with everything in it.
> But now in SDK 1.5, it installs 3 different APKs on the emulator or on
> the phone (I tested both), and the project REAL immediately crashes
> because of a VerifyError: it does not find a class that is in LIB1.
> The size of the produced APK is smaller, indeed LIB1 and LIB2 classes
> are not in it...
> I tried using uses-library in the manifest like google maps library
> but it complains at installing, we have a "missing shared library"
> error.
> I tried adding class folders in build path, it compiles in Eclipse but
> we still have a VerifyError.
> Same thing if we use external class folders in build path.
> The only thing that worked for me was to add an eclipse folder, which
> is in fact a symbolic link, and to make it a source folder. But that
> solution is not convenient for us because when we share the projects
> in SVN, the referenced paths are different for each developer. Using
> eclipse path variables can do the trick but it is far from being
> convenient. Indeed, if we have to reinstall Eclipse or if we move the
> place we check out the code in our developer station we have to
> reconfigure all these messy path variables in Eclipse.
> Is there a way to restore the old behavior on other android projects
> in build path ?
We've had the same problem with ProSyst mBS running on cupcake. After
some checks we found that it depends what JDK you use for building your
jar files before DEXing them. In general here is the info:
We've checked with the following JDK versions: jdk1.5.0_06, jdk1.5.0_10,
jdk1.5.0_12, jdk1.5.0_15, jdk1.6.0_06, jdk1.6.0_10. Only with
jdk1.5.0_06, jdk1.5.0_10 and jdk1.5.0_12 there was no verify errors.
Evan JIANG wrote:
> Well, I met the same issue.
> Does anyone have any idea about this?
> Best regards,
> On Tue, Apr 28, 2009 at 11:14 PM, Guillaume Perrot
> <guillaume.p...@gmail.com> wrote:
>> We have an application cut into 3 android projects:
>> * Project REAL (the real android project)
>> * Project LIB1 (an android project without any activity, just to make
>> android reusable classes)
>> * Project LIB2 (same as LIB1)
>> LIB1 and LIB2 are android projects rather than J2SE ones because LIB1
>> and LIB2 use Android classes.
>> Project REAL has LIB1 and LIB2 in its project build path in Eclipse.
>> In SDK 1.0 and 1.1, no problem at all when running the project REAL
>> from Eclipse, it mixes the code of the 3 projects and produces one big
>> APK with everything in it.
>> But now in SDK 1.5, it installs 3 different APKs on the emulator or on
>> the phone (I tested both), and the project REAL immediately crashes
>> because of a VerifyError: it does not find a class that is in LIB1.
>> The size of the produced APK is smaller, indeed LIB1 and LIB2 classes
>> are not in it...
>> I tried using uses-library in the manifest like google maps library
>> but it complains at installing, we have a "missing shared library"
>> error.
>> I tried adding class folders in build path, it compiles in Eclipse but
>> we still have a VerifyError.
>> Same thing if we use external class folders in build path.
>> The only thing that worked for me was to add an eclipse folder, which
>> is in fact a symbolic link, and to make it a source folder. But that
>> solution is not convenient for us because when we share the projects
>> in SVN, the referenced paths are different for each developer. Using
>> eclipse path variables can do the trick but it is far from being
>> convenient. Indeed, if we have to reinstall Eclipse or if we move the
>> place we check out the code in our developer station we have to
>> reconfigure all these messy path variables in Eclipse.
>> Is there a way to restore the old behavior on other android projects
>> in build path ?
--
Best Regards,
Daniel
---------------------------------------------------------------
Daniel Janev · Department Manager/Core Platform and Smart Home
ProSyst Software GmbH
1606 Sofia, Bulgaria · Vladajska Str. 48
Tel. +359 (0)2 952 35 81/109 · Fax +359 (0)2 953 26 17
Mobile Phone +359 (0)888 678 670
http://www.prosyst.com · d.ja...@prosyst.com
---------------------------------------------------------------
stay in touch with your product.
---------------------------------------------------------------
I use a temporary solution thanks to a comment of Raphael on the
original topic (I posted twice, sorry):
* LIB1 and LIB2 are now java projects
* I removed the sun JRE from build path
* I added android.jar instead, for SVN convenience, I added thanks to
an Eclipse PATH variable (pointing on the android.jar in the platforms/
android-1.5 dir of the SDK) so that I don't have to version control
the .jar (which is 3MB).
The only flaw I see is that each developer must set/maintain this
classpath variable in their Eclipse but according to me it was better
than versioning this "huge" jar file... twice.
On 29 avr, 13:22, Daniel Janev <d.ja...@prosyst.com> wrote:
> We've had the same problem with ProSyst mBS running on cupcake. After
> some checks we found that it depends what JDK you use for building your
> jar files before DEXing them. In general here is the info:
> We've checked with the following JDK versions: jdk1.5.0_06, jdk1.5.0_10,
> jdk1.5.0_12, jdk1.5.0_15, jdk1.6.0_06, jdk1.6.0_10. Only with
> jdk1.5.0_06, jdk1.5.0_10 and jdk1.5.0_12 there was no verify errors.
> I hope that this can help you.
> Evan JIANG wrote:
> > Well, I met the same issue.
> > Does anyone have any idea about this?
> > Best regards,
> > On Tue, Apr 28, 2009 at 11:14 PM, Guillaume Perrot
> > <guillaume.p...@gmail.com> wrote:
> >> We have an application cut into 3 android projects:
> >> * Project REAL (the real android project)
> >> * Project LIB1 (an android project without any activity, just to make
> >> android reusable classes)
> >> * Project LIB2 (same as LIB1)
> >> LIB1 and LIB2 are android projects rather than J2SE ones because LIB1
> >> and LIB2 use Android classes.
> >> Project REAL has LIB1 and LIB2 in its project build path in Eclipse.
> >> In SDK 1.0 and 1.1, no problem at all when running the project REAL
> >> from Eclipse, it mixes the code of the 3 projects and produces one big
> >> APK with everything in it.
> >> But now in SDK 1.5, it installs 3 different APKs on the emulator or on
> >> the phone (I tested both), and the project REAL immediately crashes
> >> because of a VerifyError: it does not find a class that is in LIB1.
> >> The size of the produced APK is smaller, indeed LIB1 and LIB2 classes
> >> are not in it...
> >> I tried using uses-library in the manifest like google maps library
> >> but it complains at installing, we have a "missing shared library"
> >> error.
> >> I tried adding class folders in build path, it compiles in Eclipse but
> >> we still have a VerifyError.
> >> Same thing if we use external class folders in build path.
> >> The only thing that worked for me was to add an eclipse folder, which
> >> is in fact a symbolic link, and to make it a source folder. But that
> >> solution is not convenient for us because when we share the projects
> >> in SVN, the referenced paths are different for each developer. Using
> >> eclipse path variables can do the trick but it is far from being
> >> convenient. Indeed, if we have to reinstall Eclipse or if we move the
> >> place we check out the code in our developer station we have to
> >> reconfigure all these messy path variables in Eclipse.
> >> Is there a way to restore the old behavior on other android projects
> >> in build path ?
> --
> Best Regards,
> Daniel
> ---------------------------------------------------------------
> Daniel Janev · Department Manager/Core Platform and Smart Home
> ProSyst Software GmbH
> 1606 Sofia, Bulgaria · Vladajska Str. 48
> Tel. +359 (0)2 952 35 81/109 · Fax +359 (0)2 953 26 17
> Mobile Phone +359 (0)888 678 670http://www.prosyst.com· d.ja...@prosyst.com
> ---------------------------------------------------------------
> stay in touch with your product.
> ---------------------------------------------------------------
> I use a temporary solution thanks to a comment of Raphael on the
> original topic (I posted twice, sorry):
> * LIB1 and LIB2 are now java projects
> * I removed the sun JRE from build path
> * I added android.jar instead, for SVN convenience, I added thanks to
> an Eclipse PATH variable (pointing on the android.jar in the platforms/
> android-1.5 dir of the SDK) so that I don't have to version control
> the .jar (which is 3MB).
> The only flaw I see is that each developer must set/maintain this
> classpath variable in their Eclipse but according to me it was better
> than versioning this "huge" jar file... twice.
> On 29 avr, 13:22, Daniel Janev <d.ja...@prosyst.com> wrote:
> > Hi Guys,
> > We've had the same problem with ProSyst mBS running on cupcake. After
> > some checks we found that it depends what JDK you use for building your
> > jar files before DEXing them. In general here is the info:
> > We've checked with the following JDK versions: jdk1.5.0_06, jdk1.5.0_10,
> > jdk1.5.0_12, jdk1.5.0_15, jdk1.6.0_06, jdk1.6.0_10. Only with
> > jdk1.5.0_06, jdk1.5.0_10 and jdk1.5.0_12 there was no verify errors.
> > I hope that this can help you.
> > Evan JIANG wrote:
> > > Well, I met the same issue.
> > > Does anyone have any idea about this?
> > > Best regards,
> > > On Tue, Apr 28, 2009 at 11:14 PM, Guillaume Perrot
> > > <guillaume.p...@gmail.com> wrote:
> > >> We have an application cut into 3 android projects:
> > >> * Project REAL (the real android project)
> > >> * Project LIB1 (an android project without any activity, just to make
> > >> android reusable classes)
> > >> * Project LIB2 (same as LIB1)
> > >> LIB1 and LIB2 are android projects rather than J2SE ones because LIB1
> > >> and LIB2 use Android classes.
> > >> Project REAL has LIB1 and LIB2 in its project build path in Eclipse.
> > >> In SDK 1.0 and 1.1, no problem at all when running the project REAL
> > >> from Eclipse, it mixes the code of the 3 projects and produces one big
> > >> APK with everything in it.
> > >> But now in SDK 1.5, it installs 3 different APKs on the emulator or on
> > >> the phone (I tested both), and the project REAL immediately crashes
> > >> because of a VerifyError: it does not find a class that is in LIB1.
> > >> The size of the produced APK is smaller, indeed LIB1 and LIB2 classes
> > >> are not in it...
> > >> I tried using uses-library in the manifest like google maps library
> > >> but it complains at installing, we have a "missing shared library"
> > >> error.
> > >> I tried adding class folders in build path, it compiles in Eclipse but
> > >> we still have a VerifyError.
> > >> Same thing if we use external class folders in build path.
> > >> The only thing that worked for me was to add an eclipse folder, which
> > >> is in fact a symbolic link, and to make it a source folder. But that
> > >> solution is not convenient for us because when we share the projects
> > >> in SVN, the referenced paths are different for each developer. Using
> > >> eclipse path variables can do the trick but it is far from being
> > >> convenient. Indeed, if we have to reinstall Eclipse or if we move the
> > >> place we check out the code in our developer station we have to
> > >> reconfigure all these messy path variables in Eclipse.
> > >> Is there a way to restore the old behavior on other android projects
> > >> in build path ?
> > --
> > Best Regards,
> > Daniel
> > ---------------------------------------------------------------
> > Daniel Janev · Department Manager/Core Platform and Smart Home
> > ProSyst Software GmbH
> > 1606 Sofia, Bulgaria · Vladajska Str. 48
> > Tel. +359 (0)2 952 35 81/109 · Fax +359 (0)2 953 26 17
> > Mobile Phone +359 (0)888 678 670http://www.prosyst.com· > d.ja...@prosyst.com
> > ---------------------------------------------------------------
> > stay in touch with your product.
> > ---------------------------------------------------------------
> I fixed the problem just by modifying .classpath, AndroidManifest.xml and
> adding build.xml
> Best Regards
> Eric Chen
> On Wed, Apr 29, 2009 at 7:52 PM, Guillaume Perrot <
> guillaume.p...@gmail.com> wrote:
>> I use a temporary solution thanks to a comment of Raphael on the
>> original topic (I posted twice, sorry):
>> * LIB1 and LIB2 are now java projects
>> * I removed the sun JRE from build path
>> * I added android.jar instead, for SVN convenience, I added thanks to
>> an Eclipse PATH variable (pointing on the android.jar in the platforms/
>> android-1.5 dir of the SDK) so that I don't have to version control
>> the .jar (which is 3MB).
>> The only flaw I see is that each developer must set/maintain this
>> classpath variable in their Eclipse but according to me it was better
>> than versioning this "huge" jar file... twice.
>> On 29 avr, 13:22, Daniel Janev <d.ja...@prosyst.com> wrote:
>> > Hi Guys,
>> > We've had the same problem with ProSyst mBS running on cupcake. After
>> > some checks we found that it depends what JDK you use for building your
>> > jar files before DEXing them. In general here is the info:
>> > We've checked with the following JDK versions: jdk1.5.0_06, jdk1.5.0_10,
>> > jdk1.5.0_12, jdk1.5.0_15, jdk1.6.0_06, jdk1.6.0_10. Only with
>> > jdk1.5.0_06, jdk1.5.0_10 and jdk1.5.0_12 there was no verify errors.
>> > I hope that this can help you.
>> > Evan JIANG wrote:
>> > > Well, I met the same issue.
>> > > Does anyone have any idea about this?
>> > > Best regards,
>> > > On Tue, Apr 28, 2009 at 11:14 PM, Guillaume Perrot
>> > > <guillaume.p...@gmail.com> wrote:
>> > >> We have an application cut into 3 android projects:
>> > >> * Project REAL (the real android project)
>> > >> * Project LIB1 (an android project without any activity, just to make
>> > >> android reusable classes)
>> > >> * Project LIB2 (same as LIB1)
>> > >> LIB1 and LIB2 are android projects rather than J2SE ones because LIB1
>> > >> and LIB2 use Android classes.
>> > >> Project REAL has LIB1 and LIB2 in its project build path in Eclipse.
>> > >> In SDK 1.0 and 1.1, no problem at all when running the project REAL
>> > >> from Eclipse, it mixes the code of the 3 projects and produces one
>> big
>> > >> APK with everything in it.
>> > >> But now in SDK 1.5, it installs 3 different APKs on the emulator or
>> on
>> > >> the phone (I tested both), and the project REAL immediately crashes
>> > >> because of a VerifyError: it does not find a class that is in LIB1.
>> > >> The size of the produced APK is smaller, indeed LIB1 and LIB2 classes
>> > >> are not in it...
>> > >> I tried using uses-library in the manifest like google maps library
>> > >> but it complains at installing, we have a "missing shared library"
>> > >> error.
>> > >> I tried adding class folders in build path, it compiles in Eclipse
>> but
>> > >> we still have a VerifyError.
>> > >> Same thing if we use external class folders in build path.
>> > >> The only thing that worked for me was to add an eclipse folder, which
>> > >> is in fact a symbolic link, and to make it a source folder. But that
>> > >> solution is not convenient for us because when we share the projects
>> > >> in SVN, the referenced paths are different for each developer. Using
>> > >> eclipse path variables can do the trick but it is far from being
>> > >> convenient. Indeed, if we have to reinstall Eclipse or if we move the
>> > >> place we check out the code in our developer station we have to
>> > >> reconfigure all these messy path variables in Eclipse.
>> > >> Is there a way to restore the old behavior on other android projects
>> > >> in build path ?
>> > --
>> > Best Regards,
>> > Daniel
>> > ---------------------------------------------------------------
>> > Daniel Janev · Department Manager/Core Platform and Smart Home
>> > ProSyst Software GmbH
>> > 1606 Sofia, Bulgaria · Vladajska Str. 48
>> > Tel. +359 (0)2 952 35 81/109 · Fax +359 (0)2 953 26 17
>> > Mobile Phone +359 (0)888 678 670http://www.prosyst.com· >> d.ja...@prosyst.com
>> > ---------------------------------------------------------------
>> > stay in touch with your product.
>> > ---------------------------------------------------------------
> We've had the same problem with ProSyst mBS running on cupcake. After
> some checks we found that it depends what JDK you use for building your
> jar files before DEXing them. In general here is the info:
> We've checked with the following JDK versions: jdk1.5.0_06, jdk1.5.0_10,
> jdk1.5.0_12, jdk1.5.0_15, jdk1.6.0_06, jdk1.6.0_10. Only with
> jdk1.5.0_06, jdk1.5.0_10 and jdk1.5.0_12 there was no verify errors.
Can anybody confirm this? I'm developing on a Mac, facing the same
VerifyError issue. And updates 06, 10 and 12 for JDK 1.5.0 are not
available for OSX, so this would mean trouble for Android development
on OSX in general.
The JDK is clearly not the problem here, I don't know what he's talking
about as there are several causes that can trigger a VerifyError but in this
discussion we deal with the latest ADT Eclipse plugin release.
The problem here is that the ADT plugin tries to upload the referenced
android projects in build path as separate APKs instead of mixing the code
like in previous SDK releases.
Even if several APKs are uploaded, there is no link between them on the
device and so the VerifyError occurs when launching the main one.
The only solution proposed so far is to use J2SE projects instead, using the
android.jar in their build path (see one of my previous mail on the
subject).
PS: Eclipse does not require a JDK, just a JRE, it has its own Java
compiler, which compliancy level can be set based on what JRE you use.
> > We've had the same problem with ProSyst mBS running on cupcake. After
> > some checks we found that it depends what JDK you use for building your
> > jar files before DEXing them. In general here is the info:
> > We've checked with the following JDK versions: jdk1.5.0_06, jdk1.5.0_10,
> > jdk1.5.0_12, jdk1.5.0_15, jdk1.6.0_06, jdk1.6.0_10. Only with
> > jdk1.5.0_06, jdk1.5.0_10 and jdk1.5.0_12 there was no verify errors.
> Can anybody confirm this? I'm developing on a Mac, facing the same
> VerifyError issue. And updates 06, 10 and 12 for JDK 1.5.0 are not
> available for OSX, so this would mean trouble for Android development
> on OSX in general.
Ok , my way diff the project new with old sdk ,there are 3 modified files
.classpath, AndroidManifest.xml and adding build.xml. It will work
Best Regards
Eric Chen
On Thu, Apr 30, 2009 at 2:40 AM, Guillaume Perrot
<guillaume.p...@gmail.com>wrote:
> The JDK is clearly not the problem here, I don't know what he's talking
> about as there are several causes that can trigger a VerifyError but in this
> discussion we deal with the latest ADT Eclipse plugin release.
> The problem here is that the ADT plugin tries to upload the referenced
> android projects in build path as separate APKs instead of mixing the code
> like in previous SDK releases.
> Even if several APKs are uploaded, there is no link between them on the
> device and so the VerifyError occurs when launching the main one.
> The only solution proposed so far is to use J2SE projects instead, using
> the android.jar in their build path (see one of my previous mail on the
> subject).
> PS: Eclipse does not require a JDK, just a JRE, it has its own Java
> compiler, which compliancy level can be set based on what JRE you use.
>> > We've had the same problem with ProSyst mBS running on cupcake. After
>> > some checks we found that it depends what JDK you use for building your
>> > jar files before DEXing them. In general here is the info:
>> > We've checked with the following JDK versions: jdk1.5.0_06, jdk1.5.0_10,
>> > jdk1.5.0_12, jdk1.5.0_15, jdk1.6.0_06, jdk1.6.0_10. Only with
>> > jdk1.5.0_06, jdk1.5.0_10 and jdk1.5.0_12 there was no verify errors.
>> Can anybody confirm this? I'm developing on a Mac, facing the same
>> VerifyError issue. And updates 06, 10 and 12 for JDK 1.5.0 are not
>> available for OSX, so this would mean trouble for Android development
>> on OSX in general.
> The problem here is that the ADT plugin tries to upload the referenced
> android projects in build path as separate APKs instead of mixing the code
> like in previous SDK releases.
> Even if several APKs are uploaded, there is no link between them on the
> device and so the VerifyError occurs when launching the main one.
Ouch. Why is that? Will this behavior be fixed anytime soon? Does
anybody know?
Switching to J2SE projects would imply that I'd have to build the
projects using Ant or some other external build tool, right? Well, I
was really happy with the Android tool chain until now...
Eric Chen, what is that build.xml file ? And what exaclty did you modify in
the .classpath and the manifest files ?
Handtwerk, I don't know if the problem also affects the Ant tool chain or
just the Eclipse one, someone should test that.
(When I say switching to J2SE projects, it only affects the referenced
projects, not the main one of course which is still an Android project).
> > The problem here is that the ADT plugin tries to upload the referenced
> > android projects in build path as separate APKs instead of mixing the
> code
> > like in previous SDK releases.
> > Even if several APKs are uploaded, there is no link between them on the
> > device and so the VerifyError occurs when launching the main one.
> Ouch. Why is that? Will this behavior be fixed anytime soon? Does
> anybody know?
> Switching to J2SE projects would imply that I'd have to build the
> projects using Ant or some other external build tool, right? Well, I
> was really happy with the Android tool chain until now...
I've got a working solution to this similar to your hint about J2SE
projects. Assuming your lib project is an android project, modify
the .project file to remove all Android builders and Android natures.
I removed the "resourcemanagerbuilder", "precompilerbuilder",
"apkbuilder", and "androidnature". My lib project does not have any
resources so I don't know what happens in that situation; its just my
android code common to multiple projects.
This allows the project to compile against the Android library
specified by the new "default.properties" file without manually
specifying the android.jar and your dependent applications projects
still compile in Eclipse and generate proper APKs.
This is still less than ideal, but it has allowed me to get back on
track. YMMV.
> I've got a working solution to this similar to your hint about J2SE
> projects. Assuming your lib project is an android project, modify
> the .project file to remove all Android builders and Android natures.
> I removed the "resourcemanagerbuilder", "precompilerbuilder",
> "apkbuilder", and "androidnature". My lib project does not have any
> resources so I don't know what happens in that situation; its just my
> android code common to multiple projects.
> This allows the project to compile against the Android library
> specified by the new "default.properties" file without manually
> specifying the android.jar and your dependent applications projects
> still compile in Eclipse and generate proper APKs.
> This is still less than ideal, but it has allowed me to get back on
> track. YMMV.
Editing the .classpath is a good solution. Let me explain why.
ADT supports referenced projects so that you can have library projects
reused by your main Application project.
In the past, the build system provided by ADT just looked at the list
of referenced projects, and added their output (bin/*/*.class) to the
classes.dex of the application project.
The main issue here is that those referenced projects should never
have been Android project themselves.
The reason is that those Android projects could have resources, which
in turn creates an R.java file, which in turn is potentially used by
the library project classes. Even if the resources from the library
projects are copied into the main application project, there's no
guarantee that the IDs in R.java will be similar between the projects.
Therefore, at runtime, the classes from the library would access the
wrong resources.
We noticed this when we implemented the JUnit support. Instrumentation
projects (look under samples/ApiDemos/test/) must reference the
project they're testing to be able to compile, but they shouldn't
include the code of the application they test.
To fix this, we've restricted support of referenced projects to
projects that are not Android projects (ie, do not have the Android
Nature).
Now, we do realize that you may still want to be able to share code
that reference or extend Android classes, and this is not convenient.
The solution to edit the .classpath to remove the nature and builder
is one that will work, as long as you ensure that you are not using a
previously generated R.java.
For code that doesn't reference Android code, just make a standard Java project.
In the future we will probably add a new type of Android project
(maybe Android Library Project), that will allow you to compile
against the Android framework but doesn't support Android resources,
and doesn't generate R.java classes.
On Thu, Apr 30, 2009 at 7:26 AM, JMoger <James.Mo...@gmail.com> wrote:
> I've got a working solution to this similar to your hint about J2SE
> projects. Assuming your lib project is an android project, modify
> the .project file to remove all Android builders and Android natures.
> I removed the "resourcemanagerbuilder", "precompilerbuilder",
> "apkbuilder", and "androidnature". My lib project does not have any
> resources so I don't know what happens in that situation; its just my
> android code common to multiple projects.
> This allows the project to compile against the Android library
> specified by the new "default.properties" file without manually
> specifying the android.jar and your dependent applications projects
> still compile in Eclipse and generate proper APKs.
> This is still less than ideal, but it has allowed me to get back on
> track. YMMV.
> -J
-- Xavier Ducrohet
Android Developer Tools Engineer
Google Inc.
> Editing the .classpath is a good solution. Let me explain why.
> ADT supports referenced projects so that you can have library projects
> reused by your main Application project.
> In the past, the build system provided by ADT just looked at the list
> of referenced projects, and added their output (bin/*/*.class) to the
> classes.dex of the application project.
> The main issue here is that those referenced projects should never
> have been Android project themselves.
> The reason is that those Android projects could have resources, which
> in turn creates an R.java file, which in turn is potentially used by
> the library project classes. Even if the resources from the library
> projects are copied into the main application project, there's no
> guarantee that the IDs in R.java will be similar between the projects.
> Therefore, at runtime, the classes from the library would access the
> wrong resources.
> We noticed this when we implemented the JUnit support. Instrumentation
> projects (look under samples/ApiDemos/test/) must reference the
> project they're testing to be able to compile, but they shouldn't
> include the code of the application they test.
> To fix this, we've restricted support of referenced projects to
> projects that are not Android projects (ie, do not have the Android
> Nature).
> Now, we do realize that you may still want to be able to share code
> that reference or extend Android classes, and this is not convenient.
> The solution to edit the .classpath to remove the nature and builder
> is one that will work, as long as you ensure that you are not using a
> previously generated R.java.
> For code that doesn't reference Android code, just make a standard Java
> project.
> In the future we will probably add a new type of Android project
> (maybe Android Library Project), that will allow you to compile
> against the Android framework but doesn't support Android resources,
> and doesn't generate R.java classes.
> Xav
> On Thu, Apr 30, 2009 at 7:26 AM, JMoger <James.Mo...@gmail.com> wrote:
> > I've got a working solution to this similar to your hint about J2SE
> > projects. Assuming your lib project is an android project, modify
> > the .project file to remove all Android builders and Android natures.
> > I removed the "resourcemanagerbuilder", "precompilerbuilder",
> > "apkbuilder", and "androidnature". My lib project does not have any
> > resources so I don't know what happens in that situation; its just my
> > android code common to multiple projects.
> > This allows the project to compile against the Android library
> > specified by the new "default.properties" file without manually
> > specifying the android.jar and your dependent applications projects
> > still compile in Eclipse and generate proper APKs.
> > This is still less than ideal, but it has allowed me to get back on
> > track. YMMV.
> > -J
> --
> Xavier Ducrohet
> Android Developer Tools Engineer
> Google Inc.
I wholeheartedly agree with Guillaume that Android lib projects would be a good feature. But maybe the case I have in mind requires something different.
I have ported to Android an LGPL library, libdmtx. This library has native code and JNI wrapper. I created an org.libdmtx APK which installs the native library (and the icon). The standard access rules to /data/data/org.libdmtx/lib folder allow the native library to be used from any application. But to work with this library, for every application I must copy the libdmtx.jar file to the project libs directory. Also, creating libdmtx.jar is a separate manual step in Eclipse, and I must not forget to do this when some sources of libdmtx change.
I would expect there to be a more straightforward and automatic way to do all this. At least, luckily I can tell Eclipse that the application references the libdmtx project (in the same workspace) and it will install libdmtx.apk together with my application apk when I debug it or run it as Android application.
> Hello, > Editing the .classpath is a good solution. Let me explain why. > ADT supports referenced projects so that you can have library projects > reused by your main Application project. > In the past, the build system provided by ADT just looked at the list > of referenced projects, and added their output (bin/*/*.class) to the > classes.dex of the application project. > The main issue here is that those referenced projects should never > have been Android project themselves. > The reason is that those Android projects could have resources, which > in turn creates an R.java file, which in turn is potentially used by > the library project classes. Even if the resources from the library > projects are copied into the main application project, there's no > guarantee that the IDs in R.java will be similar between the projects. > Therefore, at runtime, the classes from the library would access the > wrong resources. > We noticed this when we implemented the JUnit support. Instrumentation > projects (look under samples/ApiDemos/test/) must reference the > project they're testing to be able to compile, but they shouldn't > include the code of the application they test. > To fix this, we've restricted support of referenced projects to > projects that are not Android projects (ie, do not have the Android > Nature). > Now, we do realize that you may still want to be able to share code > that reference or extend Android classes, and this is not convenient. > The solution to edit the .classpath to remove the nature and builder > is one that will work, as long as you ensure that you are not using a > previously generated R.java. > For code that doesn't reference Android code, just make a standard Java > project. > In the future we will probably add a new type of Android project > (maybe Android Library Project), that will allow you to compile > against the Android framework but doesn't support Android resources, > and doesn't generate R.java classes. > Xav > On Thu, Apr 30, 2009 at 7:26 AM, JMoger <James.Mo...@gmail.com> wrote: > > I've got a working solution to this similar to your hint about J2SE > > projects. Assuming your lib project is an android project, modify > > the .project file to remove all Android builders and Android natures. > > I removed the "resourcemanagerbuilder", "precompilerbuilder", > > "apkbuilder", and "androidnature". My lib project does not have any > > resources so I don't know what happens in that situation; its just my > > android code common to multiple projects. > > The .classpath file remains unchanged: > > <classpath> > > <classpathentry kind="src" path="src"/> > > <classpathentry kind="src" path="gen"/> > > <classpathentry kind="con" > > path="com.android.ide.eclipse.adt.ANDROID_FRAMEWORK"/> > > <classpathentry kind="output" path="bin"/> > > </classpath> > > This allows the project to compile against the Android library > > specified by the new "default.properties" file without manually > > specifying the android.jar and your dependent applications projects > > still compile in Eclipse and generate proper APKs. > > This is still less than ideal, but it has allowed me to get back on > > track. YMMV. > > -J > -- > Xavier Ducrohet > Android Developer Tools Engineer > Google Inc.
