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.
