On Monday, March 19, 2012 10:01:55 AM UTC-7, Lathe26 wrote:
>
> I'm wondering if anyone else is seeing this severe data corruption bug.
> I've confirmed this behavior in the Android simulator and on my own phone
> using the libGoogleAnalytics.jar version 1.4.2
>
> If I use the Google Analytics JAR for Android to track several page views
> or events and then dispatch them, the data being sent to the server does
> not match what I'm tracking (LogCat output shows this too). Example: if I
> track 8 different events and then dispatch, then 8 event packets are sent
> but only the 1st and 8th packets are correct while the packets between are
> random repeats or skips of the events in between.
>
> If I call the following:
> tracker = GoogleAnalyticsTracker.getInstance();
> tracker.setDebug( true );
> tracker.setDryRun( true );
> tracker.setAnonymizeIp( true );
> tracker.setProductVersion("myProductVersion", "1.0");
> tracker.startNewSession("UA-24601666-42", this);
> tracker.trackEvent( "Clicks", "Button", "down1", 1 );
> tracker.trackEvent( "Clicks", "Button", "up2", 2 );
> tracker.trackEvent( "Clicks", "Button", "down3", 3 );
> tracker.trackEvent( "Clicks", "Button", "up4", 4 );
> tracker.trackEvent( "Clicks", "Button", "down5", 5 );
> tracker.trackEvent( "Clicks", "Button", "up6", 6 );
> tracker.trackEvent( "Clicks", "Button", "down7", 7 );
> tracker.trackEvent( "Clicks", "Button", "up8", 8 );
> tracker.dispatch();
>
> then in LogCat I'll see the debug put for the following events in this
> order: down1, down3, down5, down7, down5, down7, down7, up8
>
> For anyone that wants to see a demo, see the attached source code.
>
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.
--
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