I would make sure you're running aapt as part of each and every build.
And also aidl, if you use aidl files. These both need to run *before*
you run javac, because they produce java files that need to be
compiled. If you run them after, you'll always be picking up the
version from your previous build instead of teh current one, and the
resource IDs won't match if you've made changes to the resources.
Also, make sure that your javac task lists as source directories both
your source, and the generated output from aapt and aidl.
This example is a bit outdated, but illustrates:
<javac encoding="ascii" target="1.5" debug="true" extdirs=""
destdir="${out.classes.absolute.dir}"
bootclasspathref="android.target.classpath"
verbose="${verbose}" classpath="$
{extensible.classpath}">
<src path="${source.absolute.dir}" />
<src path="${gen.absolute.dir}" />
<classpath>
<fileset dir="${external.libs.absolute.dir}"
includes="*.jar" />
</classpath>
</javac>
On Dec 20, 9:38 am, Brian Olsen <brian.ol...@gmail.com> wrote:
> Hello,
>
> I have been building an Android app for some time now, and I decided
> to start using Ant for building instead of through Eclipse. Building
> through Eclipse has always worked flawlessly, but when I started
> building with Ant, the builds (that would install in an emulator)
> would always be unstable. Ant would always build and install the app
> fine, but running the app would cause these serious instability
> issues.
>
> Here are a few examples that would occur after building with Ant and
> installing the app:
>
> 1. The application would force close because of ClassCastExceptions
> being thrown. The source of these errors would be traced to casts like
> this:
>
> (LinearLayout)findViewById(R.id.my_layout)
>
> In this case, R.id.my_layout (or whatever I called it) would point to
> a non-existing resource. Of course, building this in Eclipse would not
> show these errors.
>
> 2. The wrong string resources would be used in an unpredictable way.
>
> 3. Layouts would not load up correctly, also causing random failures
> and force-closes.
>
> I believe that the source of these issues is related to how it is
> compiling R.java and the way it links it up to resources. I am
> unfamiliar as to how it builds resources into apps, so I am at a loss
> as to why this is occurring in the first place.
>
> The interesting thing is that if I make some change to the source
> code, and do another 'ant compile' or 'ant install', the problems in
> the previous build disappear and new resource issues pop up.
>
> After plenty of googling, I could not find anything describing
> something similar to this issue. I am concerned that potentially
> building via Ant might be exposing issues that I am not aware of, so
> besides using Ant, I just want to make sure.
>
> Is this a known issue? I just want to make sure before I attempt to
> reproduce the problem on a smaller scale.
>
> My development computer is:
>
> - Mac OS X 10.6.5
> - from java -version:
>
> java version "1.6.0_22"
> Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)
>
> I'm just using the default JVM for this.
>
> - building against Android + Google APIs, API 8 revision 2.
>
> Thank you very much,
> Brian
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
