if you could share with me a template of the ant script, it will be much appreciated!!
On Apr 5, 3:51 pm, Bob Kerns <[email protected]> wrote: > You should ALWAYS look outside the IDE for production builds. Any IDE. > Builds should always be automateable and as automated as possible. > Including managing revision control stategy. IDEs are simply not > designed for repeatability. > > However, the main part of the process is vanilla ant script produced > by the 'android' tool. It's just the setup and how it's driven that's > separate (and can be shared between projects). > > Remember, too, that ant scripts can integrate with the Eclipse IDE. > > On Apr 5, 10:27 am, HeHe <[email protected]> wrote: > > > > > Bob, sounds like you are going to devise some "Makefile" to achieve > > the purpose and i also have to look outside of Eclipse IDE and my code > > to find my "machine gun". please forget my problem and have a nice > > breakfast :) thanks anyway for your comments. > > > On Apr 5, 9:49 am, Bob Kerns <[email protected]> wrote: > > > > Your application is ALWAYS going to see Config.DEBUG as FALSE. You > > > seem stuck on that. Config.DEBUG has nothing to do with your > > > application whatsoever. It has to do with your device. > > > > I need to get breakfast, I'm getting grumpy. In addition to the link I > > > sent you, look at this link (which is linked from the link I sent > > > you!): > > > >http://developer.android.com/intl/de/reference/android/content/pm/App... > > > > You get the package manager, and get the application info for your > > > program, and examine its flags, to see the state of > > > android:debuggable. Again, nothing whatsoever to do with Config.DEBUG, > > > which you should forget you ever saw! > > > > The SDK tool chain provides NO WAY to identify a "debug build" of your > > > application -- because that could mean almost anything. > > > > YOU need to decide what it means -- you could have a debug build, a > > > test build, a build with extra logging, a build that contacts a debug > > > version of your back-end service, etc. etc. > > > > The best way to distinguish them is through the manifest. You can use > > > the android:debuggable attribute, but that's not its primary purpose. > > > But if your needs align with it, you can use it. > > > > More generally, you can include metadata in your manifest, and examine > > > that to determine how your program behaves. You can also use resources > > > for the purpose, but I would prefer such things to be done through the > > > manifest. > > > > I'm planning to start writing up my approach to building multiple > > > versions of an application from a single source tree, sometime within > > > the next couple days. One aspect of my approach is that > > > android:debuggable='true' is what appears in the manifest, unless I'm > > > creating a production build, where it is automatically set to false > > > instead. But I don't examine it in my code; I have metadata to control > > > various aspects of that. (I also automatically manage build numbers, > > > etc). > > > > On Apr 5, 9:12 am, HeHe <[email protected]> wrote: > > > > > thanks for the good idea to turn debuggable apk to red. however, the > > > > problem i am experiencing that even after i set "debuggable" attribute > > > > in manifest to TRUE and build and launch my apk using Eclipse "Run> > > > > Debug As", my apk still sees "Config.DEBUG" as FALSE. so right now i > > > > don't know how my apk can programmatically learn that it is a debug > > > > built. do you have a snippet teaching me how? thanks in adavance. > > > > > On Apr 5, 8:59 am, "~ TreKing" <[email protected]> wrote: > > > > > > On Mon, Apr 5, 2010 at 10:42 AM, HeHe <[email protected]> wrote: > > > > > > but what i need is some info telling my apk that it was a debug or > > > > > > release > > > > > > built without changing the "debuggable" attribute in manifest each > > > > > > time > > > > > > between debug/release builds. > > > > > > This is not possible. You will have to make sure to remember to > > > > > change that > > > > > "debuggable" flag. Maybe add some code that sets your primary layout's > > > > > background color to red in debug mode or something if you're so > > > > > worried > > > > > about it so you always know that you have that flag set. > > > > > > > i need it because in case i forget to change the debuggable > > > > > > attribute of my > > > > > > release built to false my apk can still behave correctly. > > > > > > So you don't really NEED it ... you just have to be careful before > > > > > publishing your app. Even a rudimentary test on your release APK > > > > > should > > > > > alert you that you still have the debuggable flag set (for example, by > > > > > setting your background to red in debug mode), in which case it takes > > > > > about > > > > > 2 seconds to switch it and rebuild. > > > > > > (1). i dont want to change the debuggable attribute in manifest > > > > > between > > > > > > > debug and release builds. > > > > > > You > > > > > should.http://developer.android.com/intl/fr/guide/publishing/preparing.html > > > > > Read section 4 > > > > > > In fact, as far as Android is concerned, that debuggable flag is > > > > > pretty much > > > > > what defines "DEBUG" vs "RELEASE", AFAIK. > > > > > > --------------------------------------------------------------------------- > > > > > ---------------------- > > > > > TreKing - Chicago transit tracking app for Android-powered > > > > > deviceshttp://sites.google.com/site/rezmobileapps/treking -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using "remove me" as the subject.
