* It turns out that Events don't store null for empty fields like location
and description, but rather an empty string.
* Exchange 2003 doesn't like seeing empty values, so check for this before
uploading.
Bug: 2490068
Change-Id: Ib208f9d6ec116a99adf798939dfbc4d4bdd15edf
* These logging statements haven't been useful in quite a while
* Leave them in the source, commented out, in case we want to
restore them
Change-Id: Ie8bc6497bc2ea3aa3437f9b2aec8c2b12af907bf
* Prune all folders, messages & attachments that won't migrate
* Clean up SSL/TLS values for better connection results & security
* Move account setup lookup code to AccountSettingsUtils to share it
* Cleanup config/auto-rotation settings to prevent relaunch of
auto-discover or account check (from exchange).
* A couple of other very small fixes
Bug: 2065528
If the account specified with an Intent doesn't exist, show the Welcome
activity instead, which will navigate the user to the appropriate activity.
(e.g. account list if there're more than one account)
Bug 2479609
* Included is a (nearly complete) VCALENDAR parser that is
used to verify the contents of the ics attachments we create
* Added a test for meeting invitation
* More to come (always)
Change-Id: I31eeac66eb635f443c85aacf56e67a943cc3d53b
* Unlike EmailProvider, CalendarProvider can return null from queries.
* Put checks for null around code using the result of query to
prevent NPE's
Change-Id: Ia9e8e2f44406dce07dcb2ffa40c22933ec2d4f07
* We needed to check that clientId wasn't null before sending it back
to the server
* Exceptions don't have a clientId
Bug: 2478711
Change-Id: Ic0d42bb699605a7bb77535b050a4d03b4b6b8b09
* We want an NPE to be thrown, since we need to locate/fix errors
of this kind.
* Add logging to help isolate the error
Change-Id: I0f4336b42cbdb88c72459bdeca9c9fc236d9299f
* VTIMEZONE blocks must be sent in our ics files for meeting
invitations that are recurring, as the originator's time zone
is critical in making attendee's calendars accurate
* Created a utility to convert TimeZone to VTIMEZONE data; the
utility successfully generates data (including recurrence rules)
for the entire tzinfo database (the source of TimeZone).
* Updated our ics files to include VTIMEZONE when appropriate and
send DTSTART/DTEND in local time in that case
* Wrote some unit tests, but more are needed
Change-Id: Iccbdd00cd3b2be2da058b344ebacd17ed6fb0e3d
* My Calendar observer registration code was storing the wrong id
in the hash map. Because of this, the code could be called again
and again, generating lots of extraneous queries and generally
creating a lot of havoc, including ANR's
Bug: 2450322
Change-Id: I03db8156ee99a0c7243a9188558dffc6a843a65a
We've observed that the secure.emailsrvr.com email server returns an excess
FETCH response for a UID FETCH command. Excess responses don't have the
UID field, even though we request, which led the response parser to crash.
This patch fixes it by making the parser ignore response lines that don't
have UID.
Bug: 2441065
* Syncs in progress weren't checking the getSyncAutomatically setting in
the account; therefore, a long sync would continue running even though the
user unchecked the "Sync Calendar/Contacts" box in the settings
* Make the adapters check the flag each time through its sync loop (which
is currently 5 items); this should cause in-progress syncs to stop within
a few seconds
Bug: 2185319
Change-Id: Ie181f6de4219ecf27fff58ed59a277ae285622c5
* We weren't retrying the initial account sync after policies are
successfully enabled. This results in failure to sync, as we
go right into a ping loop.
* Retry account sync after provisioning is first successful
Bug: 2474554
Change-Id: I20165a5941626b690710f82088d8d861679084b2
On the first boot after upgrade from Eclair, enable calendar sync for all the
existing Exchange accounts, if any, and show notification.
Note on this version, nothing happens when you click on the "Calendar added"
notification. We're waiting for an API (action or something) to launch
calendar.
Bug 2428718
* Fill in this missing piece of meeting related functionality.
* We keep track of the last synced attendee status in the newly
created syncAdapterData event column
* When this changes, we (in addition to syncing up the change)
send an email to the organizer (unless we're the organizer, of
course)
Bug: 2467153
Change-Id: I6332fb6d0839e33d4c54bd4358ee0f154bff6612
