Brill, thanks for comment. using your approach, do you run a DEBUG build on a real device and still succeed in map api?
my apk has no problem telling itself if it is running on emulator or not, because running on emulator an apk should always assume itself a debug build. my release build has no problem running on real device either. AFAIK, the map api key that an apk should use is decided by the app signing key used to sign the apk; it is not decided by which emulator/ device the apk runs on. so, when a DEBUG build runs on my REAL phone, it fails map api key, because there seems to me no way to tell build type of an apk, UNLESS like Bob suggested i put some "semi-auto" attribute or metadata in my code, and remember to remove it before formal RELEASE, or devise some makefile to put/remove the metadata for me automatically. OR, i should not run a debug build on a real device and hope map api works... On Apr 5, 10:39 am, Brill Pappin <[email protected]> wrote: > actually i had the same issue with different Map keys for dev and > production. > > My solution was a little bit of code that checks to see if your > running in the emulator or not. It works for at least Android 2.1 > update 1: > > public static final boolean isEmulator() { > if ("1".equals(System.getProperties() > .getProperty("ro.kernel.qemu", "0"))) { > // Emulator > return true; > } > return false; > } > > public static final String getGoogleMapsAPiKey() { > if (isEmulator()) { > return "YOUDEVKEY"; > } > return "YOURPRODKEY"; > } > > I've actually deployed this to a device and it seems to work just > fine. > > - Brill Pappin > > On Apr 5, 1:27 pm, 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.
