Bug 39947 - GoogleAnalytics.ReportActivityStart sends the mangled name of the passed activity
Summary: GoogleAnalytics.ReportActivityStart sends the mangled name of the passed acti...
Status: RESOLVED ANSWERED
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Jonathan Pryor
URL:
Depends on:
Blocks:
 
Reported: 2016-03-28 14:15 UTC by Dimitar Dobrev
Modified: 2017-06-28 08:24 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED ANSWERED

Description Dimitar Dobrev 2016-03-28 14:15:53 UTC
Monodroid mangles the names of activities when internally compiling to Java, for example:

Activity -> md5803bcb4427292ce7445831bc505dc2cb.Activity

Usually this doesn't matter, just internals. However, using Google Analytics exposes a problem. It has a built-in method for reporting activities called Android.Gms.Analytics.GoogleAnalytics.ReportActivityStart(Activity activity). When this method is used, it reports this internal mangled name instead of, for example, the qualified name ("com.my.package.Activity") or the simple name ("Activity"). Activities from Java bindings are reported correctly - for example, "com.facebook.FacebookActivity".
So this is a bug that should be fixed one way or another - by removing the mangling or by adjusting this specific method of your GA Java binding (https://components.xamarin.com/view/googleplayservices-analytics). Please also note the following. The GA dashboard has specific views for reported activities and using a custom event would render those views empty. The GA Java client, on the other hand, is closed-source so it's impossible to copy the code of ReportActivityStart and replace the name of the activity. This all means the bug cannot be worked around.
Comment 1 Dimitar Dobrev 2016-04-22 20:07:04 UTC
Any comment?
Comment 2 Dimitar Dobrev 2016-05-28 12:36:40 UTC
Seriously, 2 months with no comments? Does nobody pay attention to this bug tracker any more?
Comment 3 Jonathan Pryor 2016-05-31 19:30:39 UTC
> So this is a bug that should be fixed one way or another - by removing the mangling 

The mangling is performed in order to avoid a nasty corner case in binding generation. See also Bug #16826 and https://developer.xamarin.com/releases/android/xamarin.android_5/xamarin.android_5.1/#Android_Callable_Wrapper_Naming

We are considering allowing the package name algorithm to be user-selectable, but (1) there's no timeframe for this, and (2) returning to the pre-5.1 behavior would re-open variants on Bug #16826.

In the meantime, if *you* control the Activity, *you* can explicitly specify a name by using the ActivityAttribute.Name property:

    [Activity(Name="appname.MyActivity")]
    partial class MyActivity : Activity {
    }

> or by adjusting this specific method of your GA Java binding

I haven't looked at the GA binding, but I imagine this isn't possible, because in all likelihood Google Analytics is using Java reflection to obtain the type names. There would be no way to "adjust [type names]," as the code providing the names has no way of adjusting them.
Comment 4 Dimitar Dobrev 2016-05-31 19:37:52 UTC
Thank you for the workaround, it's indeed going to help us. What I am not thankful for is the 2 months we had to wait, especially with such a simple solution. Please consider pointing the attention of whoever is in charge of support to this matter.
Comment 5 Jonathan Pryor 2016-05-31 21:16:05 UTC
Bugzilla is not a *support* channel.

Bugzilla is a bug reporting and feature request channel.
Comment 6 Dimitar Dobrev 2016-05-31 21:17:53 UTC
As long as I don't get a "please file a bug in Bugzilla", I am fine with using your support e-mails in the future.