https://bugzilla.novell.com/show_bug.cgi?id=634931
https://bugzilla.novell.com/show_bug.cgi?id=634931#c1 Jonathan Pryor <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Jonathan Pryor <[email protected]> 2010-08-27 15:03:56 UTC --- So here's the answer: Don't Do That. :-) Background: monodroid.exe processes AssemblyManifest.xml, partially generating its contents. monodroid.exe provides a --package=NAME [0] option to change the value of the /manifest/@package attribute value. Why would you want to use --package? Android only allows having one application with a given package name to be installed at a time. Thus, if you want to install two different versions of your app (e.g. the "stable" and "development" versions for side-by-side testing), you would need to change the package name. `monodroid --package` allows you to trivially change the package name, allowing you to have the "same" app installed multiple times (under different package names), thus facilitating testing. HOWEVER, as you note from the activity docs, //activity/@android:name MUST be EITHER a fully-qualified class name OR a class name found within the /manifest/@package package. Consequently, if you actually used `monodroid --package` to change the package, AND you used the ".ShortHand" convention, your activity wouldn't be found (as monodroid generates Java proxies in the Java package corresponding to the namespace of your managed code, so if you change the package name but not your namespace the proxies will be in the "wrong" location... result: it won't work). Thus, to allow `monodroid --package` to sanely work, monodroid ALWAYS uses fully-qualified type names within //activity/@android:name. This just makes things easier to deal with. :-) The problem you're seeing is that the AndroidManifest.xml you're providing is making use of short names. monodroid doesn't currently check for short names, it just checks for full class names. Since it doesn't find an //activity/@android:name with the full type name, it creates one. Result: the AndroidManifest.xml that is actually built into the .apk file has *4* <activity/> elements, two with the short name and two with the full name. See ./obj/Debug/android/AndroidManifest.xml in your project directory. Which is why you're seeing two launchers: the <activity/> elements that monodroid generates by default includes the LAUNCHER category, so your attempt at "removing" LAUNCHER is being negated by monodroid's default behavior. There are several possible solutions here 1. Use full type names in your AndroidManifest.xml so that what you write takes precedence over what monodroid generates (as monodroid won't generate XML if the //activity/@android:name is already present). 2. #632611 will allow us to use attributes on the Activity to control the AndroidManifest XML that monodroid generates. This is likely the cleanest solution, but I don't know when it'll be complete. 3. We could fix monodroid to also check for short names and replace them with full names if necessary. I'm leery of this idea, though, as it could result in "odd" behavior if someone were to use the same class name in different namespaces; which type should the shortname refer to? Arguably, you shouldn't do that, but when (1) makes it trivial to support this scenario anyway, I don't see much point to adding additional code to support (3). So this bug is either a dup of #632611 or a WONTFIX (as you should be doing (1) and/or I don't like (3)). [0] http://monodroid.net/Documentation/Tools/Monodroid.exe -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
