[Mono-bugs] [Bug 634931] launcher for each activity class when using period shorthand in AndroidManifest

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=634931

https://bugzilla.novell.com/show_bug.cgi?id=634931#c1


Jonathan Pryor <jpryor at novell.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #1 from Jonathan Pryor <jpryor at novell.com> 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.