tree 9340db9ad65add03ef3f61264a4bc1c3f353a89a
parent d68ee11543671e8e926f7a95d014c5c04e964eb8
author Marc Blank <mblank@google.com> 1276205243 -0700
committer Marc Blank <mblank@google.com> 1276278279 -0700

Work around problem w/ large CalendarProvider2 transactions

* We're seeing binder transaction failures when we try to send more than around
  1500 CPO's to CalendarProvider2 in a batch (the limit is related to memory
  usage in binder transactions)
* When an event has A attendees and E exceptions in an event, we currently must
  create A*E CPO's; this number can become very large and cause a binder failure
* The result of a failure is looping behavior, resulting in failed sync and very
  much reduced battery life
* The workaround here is to redact all non-organizer and non-user attendees from
  exceptions once we reach half of the maximum number of CPO's.  This has been
  determined empirically and is set to 500 CPO's in this CL
* We also reduce our sync "window" to 4 calendar/contact items per sync command
  to help limit the potential size of our batch
* For later releases, we should reconsider this and see if something that is more
  of a "fix", rather than a workaround, can be implemented

Bug: 2760514
Change-Id: I06ca1a1ae88c772342a9e46b5997c41678e95144