Corrupt event data being sent by Android libGoogleAnalytics.jar

[GoogleCodeExporter]

---------------------------------------------------------------------------
NOTE: This issue tracking system is for Google Analytics developer products
only.
If you are not a developer/programmer visit:
http://www.google.com/analytics/support.html
---------------------------------------------------------------------------
Name of affected component: Mobile Tracking

Name of related library and version, if applicable (e.g. Android, iOS,
Snippets, etc.): Android libGoogleAnalytics.jar version 1.4.2

Issue summary:
When multiple calls are made to the GoogleAnalyticsTracker.trackEvent method 
and then dispatch() is called, the label and value parameters of the trackEvent 
calls get cross-wired.  In other words, the data from one call to trackEvent 
gets sent in the upload data that was for another call to trackEvent.  This was 
confirmed by observing the LogCat output while calling trackEvent multiple 
times and then calling dispatch once.  This problem occurs randomly in that it 
sometimes it doesn't show up, other times the labels get corrupted, other times 
the values, and other times both get corrupted.  The, the first and last events 
being dispatched are fine but the ones in between get corrupted.

Example code steps to reproduce issue:
1. tracker.setDebug( true );
2. tracker.trackEvent( "Clicks", "Button", "clicked", 77); 
3. tracker.trackEvent( "Clicks", "Button", "clicked2", 99); 
4. tracker.trackEvent( "Clicks", "Button", "clicked", 77); 
5. tracker.trackEvent( "Clicks", "Button", "clicked2", 99); 
6. tracker.dispatch()

Expected LogCat output:
I/GoogleAnalyticsTracker(29411): GET 
/__utm.gif?utmwv=4.8.1ma&utmt=event&utme=5(%2FClicks*%2FButton*%2Fclicked)(77)&.
..
I/GoogleAnalyticsTracker(29411): GET 
/__utm.gif?utmwv=4.8.1ma&utmt=event&utme=5(%2FClicks*%2FButton*%2Fclicked2)(99)&
...
I/GoogleAnalyticsTracker(29411): GET 
/__utm.gif?utmwv=4.8.1ma&utmt=event&utme=5(%2FClicks*%2FButton*%2Fclicked)(77)&.
..
I/GoogleAnalyticsTracker(29411): GET 
/__utm.gif?utmwv=4.8.1ma&utmt=event&utme=5(%2FClicks*%2FButton*%2Fclicked2)(99)&
...

Actual LogCat results:
I/GoogleAnalyticsTracker(29411): GET 
/__utm.gif?utmwv=4.8.1ma&utmt=event&utme=5(%2FClicks*%2FButton*%2Fclicked)(77)&.
..
I/GoogleAnalyticsTracker(29411): GET 
/__utm.gif?utmwv=4.8.1ma&utmt=event&utme=5(%2FClicks*%2FButton*%2Fclicked)(77)&.
..
I/GoogleAnalyticsTracker(29411): GET 
/__utm.gif?utmwv=4.8.1ma&utmt=event&utme=5(%2FClicks*%2FButton*%2Fclicked)(77)&.
..
I/GoogleAnalyticsTracker(29411): GET 
/__utm.gif?utmwv=4.8.1ma&utmt=event&utme=5(%2FClicks*%2FButton*%2Fclicked2)(99)&
...

Notes:
This was reproduced with a slightly modified version of the sample code 
provided with the Android libGoogleAnalytics.jar.  All code was executed on the 
main UI thread.  The above LogCat output and steps were simplified to show the 
root of the problem.  The actual steps included having the user click on on the 
"Create Event" button and the "Create Event2" buttons a few times alternatively 
and finally clicking on the "Dispatch" button.  A stripped down version of the 
source code for TestActivity.java is attached.

Considering that corrupt data is being silently delivered to the servers, this 
bug delivers corrupt data that appears to be indistinguishable from valid data. 
 This can cause developers to make bad decisions based on bad data.

Original issue reported on code.google.com by lath...@gmail.com on 19 Mar 2012 at 4:43

Attachments:

• TestActivity.java

[GoogleCodeExporter]

This bug is worse than originally thought.  It is sending corrupt PageViews as 
well as corrupt events.  

I've attached a more straight-forward demo app that has 3 buttons: Dispatch 
Events, Dispatch Pages, and Quit.  Simply click either of the first 2 buttons 
and watch the LogCat output (note: you might have to force LogCat to refresh 
itself since it does not always automatically do so for the Android Google 
Analytics output).

Original comment by lath...@gmail.com on 19 Mar 2012 at 4:50

Attachments:

• GoogleAnalyticsCorruptData.zip

[GoogleCodeExporter]

On further investigation, it was found that this bug only manifests when 
setDryRun(true) is called.  The good news is that when it is set to false (or 
not called), then the LogCat output and any network capture logs (ex: 
WireShark) show that the correct data is actually uploaded to the servers.

Since the real data being sent to the service is not being corrupted, this 
lowers the severity of this bug.

Without seeing the source code, I'm guessing that when setDryRun(true) is 
called, all tracking calls stop going to the SQLite DB and instead go to an 
alternative in-memory data structure and that this data structure either has 
some bugs or is not fully thread-safe.

Original comment by lath...@gmail.com on 21 Mar 2012 at 3:40

[GoogleCodeExporter]

Original comment by awa...@google.com on 7 Nov 2013 at 9:36

• Changed state: Obsolete