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. On Monday, March 19, 2012 10:05:45 AM UTC-7, Lathe26 wrote: > > I should add that a Issue 200 has been filed in the > analytics-issues<http://code.google.com/p/analytics-issues/>bug database at > this link location: > http://code.google.com/p/analytics-issues/issues/detail?can=2&start=0&num=100&q=event&colspec=ID%20Component%20Type%20Status%20Priority%20Stars%20Summary&groupby=&sort=&id=200 > -- 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
