Hello, Thank you very much and sorry for the late reply. I am going to give this a try today. Based on what you said, aidl and aapt weren't running.
Brian On Dec 22, 4:30 am, Bob Kerns <r...@acm.org> wrote: > I should also point out that you can get the 'android' command to set > up ant build files for you, and this is probably a better idea than > doing it yourself. > > I have been doing it myself, based on what the android command did, > because when I first did it, there were various serious flaws in how > it did it, including the hardwired use of the 'ascii' encoding (which > is just plain nuts, and is still the default, but can be overridden > now). But at this point, I plan to replace my android-specific > portion with using theirs, and just handle the build management > (checkout, etc.) with a wrapper that calls theirs to do the actual > build. > > See here for how to use the 'android' tool to set this up: > > http://developer.android.com/intl/de/guide/developing/other-ide.html > > On Dec 22, 1:14 am, Bob Kerns <r...@acm.org> wrote: > > > 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,BrianOlsen<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
