Commit Graph

2497 Commits

Author SHA1 Message Date
Marc Blank
17cc6a7b81 Fix regression in Exchange calendar attendee response
* During the fix of a previous late-Froyo issue, a change was made that
  appeared superficially correct, but was semantically incorrect.  This
  changed the sense of the test for whether a reply email was required
  and caused the referenced bug.
* The trivial fix is to replace the test with the (older) proper one

Bug: 2764551

Change-Id: I7c72366252cf0607aee31ee0d76aca96a7d5fc2b
2010-06-30 13:27:14 -07:00
Marc Blank
7a358316ae Merge "Work around problem w/ large CalendarProvider2 transactions" into froyo 2010-06-11 11:27:28 -07:00
Andrew Stadler
572c06f91b DO NOT MERGE - Revert workaround for KeyguardLock problem
This reverts commit 3ee0cad5f5.

Because commit 284b62e1b8c3419bfd02c6fea5ba0a68146c06f8 fixes the underlying
conflict between DeviceAdmin policies and apps attempting to disable the
Keyguard Lock, this patch is no longer required.

Accounts with a server policy requiring a device PIN or Password will
now work properly.

Bug: 2737842
Change-Id: I533c27a01a8a331dc11a0cb84bcc78f48edf621c
2010-06-11 11:21:41 -07:00
Marc Blank
826c83a231 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
2010-06-11 10:44:39 -07:00
Kenny Root
8cfeacdcb3 Import revised translations
Change-Id: Ic8818f3a44fe8cd06241ecdbad4082bf5afc828c
2010-06-09 22:41:54 -07:00
Andrew Stadler
3ee0cad5f5 DO NOT MERGE Workaround for KeyguardLock problem
* The device policies that enforce the use of a device PIN or password
  can be sidestepped by apps that implement KeyguardManager.KeyguardLock
* This renders the policies unuseable
* To prevent this, the email app now scans for any packages holding the
  DISABLE_KEYGUARD permission.  The existence of any non-system app
  with this permission will put all security-enabled EAS accounts into
  a security hold, and post a dialog describing the problem.
* The user must uninstall any such app(s) in order to sync their EAS data.

Bug: 2737842
Change-Id: I4c96d76b12d9242b5c755dd60d7578a825fae597
2010-06-04 11:10:03 -07:00
Andrew Stadler
27e75533e9 Merge "Fix format string ordering" into froyo 2010-05-28 12:08:15 -07:00
Andrew Stadler
5b90a9b604 Fix format string ordering
* Three format strings had multiple replacement tokens, but the ordering
  information was missing.
* In five languages, the translations reverse the order, and the formatter
  crashes (because of types mismatching).
* This patch adds in the ordering information where needed

Bug: 2719864
Change-Id: I084e9c9ddab54901a5142710e8ef986223902c17
2010-05-27 17:27:59 -07:00
Marc Blank
8c742a4c65 Handle case of null organizerEmail in changed event
* A recent change assumed that organizerEmail couldn't be null while
  an event was being added.  However, there is an unusual case in
  which it CAN be null, and this CL handles that case
* Regression caused by: SHA 7f448dcd47
Bug: 2719254
Change-Id: Idb8fc79c898bcd2e53fcc8b3e42d0ba67ba762fa
2010-05-27 09:50:31 -07:00
Marc Blank
b6a08f68d7 Remember to store modified organizerEmail
Bug: 2709816
Change-Id: Ib26536c127857fa8a1fdf805469872419931f21c
2010-05-26 07:33:06 -07:00
Marc Blank
7f448dcd47 Limit the number of attendees in a synced event
* If there are over 50 attendees in an event, we only store the
  organizer as an attendee (the rest are redacted) and we set
  the hasAttendeeData flag to 0
* If the user is the organizer, we reset the owner of the event
  to a bogus address, which causes the UI to prevent edits to
  the event (we can't upload without losing all of the attendee
  information on the server). We also prevent the event from ever
  being uploaded (belt & suspenders)
* If the user is an attendee, we allow changes to be uploaded
  (this would be attendee status and free/busy), but the list of
  attendees on the server is removed.
* We also mark events with redacted attendees, even though we don't
  use that information currently.  In a future version, however,
  we could use this to indicate the redacted state to the user.

Bug: 2709816
Change-Id: I2b44af59c598cedf906af12bf9b4eaf7484b9d20
2010-05-25 19:35:05 -07:00
Marc Blank
8752159c7d Fix critical typo in CalendarSyncAdapter
* Used wrong name for column

Bug: 2703075
Change-Id: I8107bd2df4fdc2ee79d126a657383b46317d0495
2010-05-25 14:05:45 -07:00
Marc Blank
027a6ddfaa Merge "Fix bugs related to TZ handling for all-day events" into froyo 2010-05-25 13:07:43 -07:00
Marc Blank
3e065170f3 Fix bugs related to TZ handling for all-day events
* In bug 2703075, all-day events from time zones at GMT or later
  appear a day early; this is because the time was calculated from
  the GMT date/time of the event rather than the local date/time of
  the event; this CL correctly changes this to use local date/time
* In bug 2707966, device-edited all-day events disappear in Outlook
  and OWA after upsync; this is due to the fact that we store all-day
  events in UTC on device, whereas we need to upload all-day events
  using the original (local) time zone.  In this CL, we save away
  the original time zone and use it on upsync
* In our decoding of Exchange time zone information, we default to
  local time when we can't find a time zone that matches the bias
  and DST information; we should really default to a time zone with
  the same bias, if one exists; we do that in this CL.
* Add/modify unit tests

Bug: 2703075
Change-Id: Id80c481ecc0eae980b2e91dae7f105f924cfca28
2010-05-25 11:46:44 -07:00
Marc Blank
6bd7a16724 Fix problem w/ sync of large calendars (never syncs)
* While working w/ Microsoft on this issue, we determined that Windows
  Mobile 6.0 does not suffer from this issue; when we compared our
  logs with those from the WM client, we noticed a difference in the
  commands being sent to the server on initial  sync (we send some extra
  options whereas WM doesnot)
* As an experiment, I removed these options from the initial
  sync, and this change solved the problem with a persistently unsyncable
  account (time to receive: 60-70 seconds vs. > 240 seconds).
* The fix is to remove all "options" from the initial sync for a given
  collection (i.e. with SyncKey=0)
* Note that Microsoft's documentation does not generally address the issue
  of what should/should not be sent in an initial sync command

Bug: 2569162
Change-Id: Ib20ea56fb380ee8c9a01b139f7fa98b7ff505e7a
2010-05-22 14:38:03 -07:00
Marc Blank
274492db09 Allow limited looping requests in sync
* Microsoft has documented cases in which the server can continue to
  send MoreAvailable=true even when no new data is received.  This
  can cause looping behavior, which we stop when we recognize it.
* This workaround, however, can prevent the situation from resolving
  itself, and lead to delayed sync (up to a few hours has been noticed)
* In this limited CL, we allow the sync to loop up to a maximum number
  of times before stopping it forcibly.

Bug: 2685984
Change-Id: I2913b7e3438f6180c3c440508fab892176a06540
2010-05-19 10:38:39 -07:00
Makoto Onuki
e98fc403ac Remove STOPSHIP
Bug 2694636

Change-Id: Ief270c69d202c4ff2bbe3b49cd3b9e4a52655e4b
2010-05-18 16:07:51 -07:00
Kenny Root
df9722f894 Import revised translations
Change-Id: Idf95a5cc69832bbb96459e341b1d700670889026
2010-05-17 11:33:01 -07:00
Marc Blank
e0ebcd8e6c Test for NPE in EasSyncService during alarm() call
Bug: 2681197
Change-Id: I1795f81ef5a41440fa6fa17f278562fc076dff3f
2010-05-14 09:47:26 -07:00
Andrew Stadler
3778b3ed7e Try autodiscover with bare name if we get 401 with address
* Some autodiscover servers appear to require the bare user name
  for authentication rather than the user's email address.  This
  is apparently common for complex organizations maintaining a
  group of email domains
* If we get a 401 when trying to connect to an autodiscover server
  using the email address, we try again using just the bare name

Bug: 2682833
Change-Id: Ia07ca336e189069d4f3539e2245b3d53c82e3324
2010-05-14 00:05:28 -07:00
Marc Blank
8100a2dc55 Server sending unsupported policies will cause NPE
* Add null check after trying to create a PolicySet during
  provisioning.

Bug: 2683220
Change-Id: If20adbd4287b291e6470591fd2c3ac1f69ad2355
2010-05-13 13:42:06 -07:00
Marc Blank
d1e00e8aa6 Fix NPE resulting from attendees-only update from server
* Code for updating attendees in CalendarProvider2 wasn't taking
  an attendees-only update into consideration
* Fix code to allow for this, including proper updates for our
  selfAttendeeStatus and attendees ExtendedProperty values

Bug: 2668682
Change-Id: I8c7deb971cd0b6846c09ee3cd603f6fc762a9407
2010-05-10 09:39:20 -07:00
Marc Blank
85a63c3c2f Fix issues with exception downloads
* It turns out that, in addition to other requirements of the
  CalendarProvider, there is another - that the ORIGINAL_INSTANCE_TIME
  also be set with hour, minute, and second as zero (in UTC)
* Change setTimes() to properly modify ORIGINAL_INSTANCE_TIME
* Also, there was a regression due to an incorrect validity test
  for events; this regression caused all exception downsyncs to fail
* Changed isValidEventValues() to be correct for both exceptions
  and original events
* Update tests for setTimes and isValidEventValues()
* This CL also fixes 2658988

Bug: 2664229
Change-Id: I9c8aea08e606ff58e5be37ca81a2d86a181c46f6
2010-05-07 15:47:57 -07:00
Marc Blank
c901810f84 Start sync ASAP when calendar is re-enabled
Bug: 2664421
Change-Id: Id3c08a5ca8abc5ad0f483408f38371dcc5f2d840
2010-05-06 20:36:36 -07:00
Marc Blank
3558e5f227 Shut down Email process when sync is totally blocked
* When sync threads get blocked by SSL/Socket code, we detect this
  and shutdown the ClientConnectionManager, hoping this will solve
  the problem.
* Apparently, this doesn't always work.  The result is that syncs
  are frozen until the device is rebooted (certainly) or until the
  Email process is stopped and restarted (hopefully)
* This CL kills the Email process after an unsuccessful attempt to
  clear blocked threads using ClientConnectionManager.shutdown()

Bug: 2615293
Change-Id: I8445b278817e508a855adeb88d6b2f969d28858b
2010-05-06 15:03:33 -07:00
Marc Blank
8f255ddeee Merge "Add checks for Event validity before commit" into froyo 2010-05-06 08:49:48 -07:00
Marc Blank
33f07963eb Add checks for Event validity before commit
* Enforce CalendarProvider2's requirements for valid Events
* Add unit tests for the new code
* Backport of change I42ad7acb from master
Bug: 2658149

Change-Id: I8151d035247a7dbb1fda3eae163b24ccfe055299
2010-05-06 08:28:34 -07:00
Marc Blank
2b3bbb6948 Fix NPE in SyncManager
Bug: 2660742
Change-Id: I80ec62a0e128b3f20873a718d951e41f3fa2eb90
2010-05-06 07:05:26 -07:00
Andy Stadler
48d2621b45 Merge "Fix GAL lookup issue" into froyo 2010-05-03 07:25:15 -07:00
Andrew Stadler
a7628f3bc0 Merge "Better handling for untyped attachments" into froyo 2010-05-03 07:22:00 -07:00
Marc Blank
cb7ac76f0b Fix GAL lookup issue
Bug: 2646410
Change-Id: I52b0ddf4b7c6b56b3ad060d8d42a6080efa3662b
2010-05-02 13:51:35 -07:00
Andrew Stadler
80ebde2897 Better handling for untyped attachments
* IMAP/POP rely on sender to set mime type of attachments
* Which doesn't always work, because senders don't always provide it
* Remap using filename extensions, when needed
* This is applied as late as possible - in the MessageView, and in
  the content provider getType().  No changes to how we write databases,
  and no change to existing attachment rows.

Bug: 2356638
Change-Id: Ie69e3fd12f406aac803583f9d1299a8af4fba010
2010-04-30 15:01:10 -07:00
Makoto Onuki
cf362a48c1 Collectly preserve the service start-id.
We were passing the wrong arguments, which caused the service left running.

Bug 2646212

Change-Id: Ie5aeaeb80635c8e805fc2e9c6f4aec3b21942740
2010-04-30 14:41:47 -07:00
Andrew Stadler
14812a50a8 Workaround for IllegalArgumentException in SyncManager
* There is a race condition in which the AccountManager listener
  isn't properly unregistered when SyncManager is shut down
* In this case, SyncManager tries to register a new listener
  (i.e. registering again), which causes an IllegalArgumentException
* The quick workaround is simply to catch and ignore this exception,
  as it's really more of a warning than a true error
* A bug will be filed for the underlying issue

Bug: 2631561
Change-Id: I139d24ae045d402d4d8cb006406ef96ccc768566
2010-04-30 12:39:08 -07:00
Marc Blank
47a59d883f Merge "Fix issues with incorrect email replies to event organizer" into froyo 2010-04-30 12:04:34 -07:00
Marc Blank
468fe91dd8 Prevent account reconcile from running when service is down
Bug: 2644142
Change-Id: Ia6ccf7371bc08b3b67ab3d0871f3618c5e5bd107
2010-04-30 11:43:40 -07:00
Marc Blank
d2c773a806 Fix issues with incorrect email replies to event organizer
* We were previously storing the user's attendee status in the
  SYNC_ADAPTER_DATA column of the Event, but it turns out that
  this data isn't available in the Entity we retrieve when
  uploading changes to the server
* The result is that we often thought the user's status had
  changed when in fact it had not; in these cases, we sent email
  to the organizer, often with the wrong information.
* As of this CL, we store the user's attendee status in an
  ExtendedProperties row (these values are already exposed in event
  entities)
* The logic otherwise remains the same; we now get correct data,
  however

Bug: 2638762
Change-Id: Ibe8db90c16b4ca06203f77fd010aa26dde89a556
2010-04-30 10:52:18 -07:00
Marc Blank
09f0ab0454 Merge "Fix NPE in SyncManager" into froyo 2010-04-30 10:39:30 -07:00
Makoto Onuki
5ab7ec7123 Move a bare string to a resource.
Bug 2637666

Change-Id: I59cf5d2b30846604049d3f988b1003dd7d91ad6f
2010-04-30 09:21:04 -07:00
Marc Blank
3139d43ee2 Fix NPE in SyncManager
Bug: 2644142
Change-Id: I4336aef65669b7a4a32e43e8068edd4dd9772b03
2010-04-29 20:41:07 -07:00
Marc Blank
f2d43c39b4 Merge "Update unit tests for invitation creation" into froyo 2010-04-29 20:19:07 -07:00
Kenny Root
3cc3b89fc4 Import revised translations
Change-Id: I1586d45f93b08b55010c3136ceacd798aab3df6b
2010-04-29 15:40:54 -07:00
Marc Blank
9294d8c030 Update unit tests for invitation creation
* Tests changed/added for exception/recurrence changes in CL50201

Bug: 2640878
Change-Id: I97e5557c198aa686d1705158f2c9087c1683590e
2010-04-29 11:03:37 -07:00
Marc Blank
8ba0728533 Use timezone in exception ics files
* Exchange seems to require time zone information in ics files containing
  event exceptions, although this is NOT the case for iCalendar, and appears
  not to conform to VCALENDAR specifications
* This causes exceptions to be placed on the wrong date or perhaps even
  ignored, depending on the circumstance
* This CL simply adds time zone information to all exception ics files

Bug: 2640878
Change-Id: Ibc614eb7a2c45e9e782b10be979d9892bbfc0029
2010-04-29 10:16:58 -07:00
Marc Blank
39e6d3aed0 Fix concurrent modification exception
* Synchronize recently added call to releaseMailbox on sSyncLock

Bug: 2639210
Change-Id: Iaa1f2ed7cdc9cc0c306363487095ac5ccd02f9a3
2010-04-28 22:49:23 -07:00
Marc Blank
8917e52db0 Fix regression that prevents calendar sync w/ new accounts
* The regression is caused by a check on whether the calendar is
  syncable, as determined by the status of the Calendar (via
  CalendarProvider2).
* Unfortunately, if there IS no calendar, we were disallowing sync,
  which prevents the calendar from being created in the first place

Bug: 2619755
Change-Id: I1e94a129413bdbe9bc9bfb3608d3ca95f23d8dfb
2010-04-28 15:27:11 -07:00
Marc Blank
b7f57f25ea Remove STOPSHIP debug code
Bug: 2638014
Change-Id: I10a7ac89cce68ae1db146eb9bed574c00386ba62
2010-04-28 09:48:40 -07:00
Marc Blank
b5bf09a56d Merge "Allow more time for HttpPost watchdog timeout" into froyo 2010-04-27 23:25:15 -07:00
Marc Blank
f7369ad51f Merge "Shutdown all connections when sync service is hung" into froyo 2010-04-27 23:17:41 -07:00
Marc Blank
8f9e872eaf Allow more time for HttpPost watchdog timeout
* The current timeout is triggering more often than it should, which
  causes delays and inefficiency.  Increase it from 10 to 30 seconds.

Bug: 2615293
Change-Id: I54b74cc7ad9f1c8286af49b957584670c071640c
2010-04-27 23:13:32 -07:00