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
* In #2469254, uploaded new events were rejected because the time zone was
sent after dates; this doesn't matter to Exchange 2007, but it apparently
does to Exchange 2003
* Also, I noticed that upsync was upsyncing all new events, regardless of
whether the event belonged to the Calendar being synced! So this is
fixed as well.
Bug: 2469254
Change-Id: I651d591cf26e00b414f6da19897fddcdb840c97c
* When the user selects accept/decline/tentative in MessageView, we now send
an email to the organizer, with an iCalendar attachment indicating the reply
* Added a unit test for the reply case, but more tests to be added to handle
other circumstances
Change-Id: Iff799d88a92b6546735bf4965b22febf3a82b56f
* Was checking for any meeting related email
* Changed to look specifically for incoming meeting invites
* Bug noticed during debugging
Change-Id: I8f43d7a506939dbfc0504f96b249e5c17107bf47
* Wrote utility to create an ics file (iCalendar) based on a
CalendarProvider Event. This is a good first pass, but we need
to consider whether to include alarms, etc.
* Use aforementioned utility and new convenience method to send
meeting invitations to attendees of newly created meetings (events)
when they are uploaded to the server via the CalendarSyncAdapter
* Overall, attempted to modify existing provider and rfc822 output
code as little as possible. Rfc822Output is actually very limited
in its capabilities and should be made more robust in future
Change-Id: Ie20b9137df56dc414de6737d05fa40ec9cdf47e0
* We can use this for meeting request information which will start out with
one or two pieces of information, but might grow in the future.
* Binary compatible with Address.pack() format, so we can eventually
combine code.
* Added two columns to Attachment in EmailProvider
content: content that is written directly as an attachment
suppressDisposition: to suppress the content-disposition header
All meeting invitation emails use these two columns; the first
for ics attachment data (which is quite small, rarely over 1k),
and the second to indicate NOT sending the content-disposition
header; without this, Exchange will consider the ics as an
attachment rather than an iMIP style message (rfc2447)
* Modified tests to include these columns; added upgrade code for
new database version
* New columns and code are designed to be usable outside Exchange,
although there are no other clients of the code at this point.
* Modified Rfc822Output to use the content field, if present, in
lieu of retrieving attachment data via URL; added support for
suppressing the Content-Disposition header
- The entire android.pim package is hidden.
Use java.text.ParseException instead of android.pim.DateException.
- TelephonyManager.getDefault() is hidden.
Use Context.getSystemService() instead.
- Use newly added Base64 in the framework.
Bug 2226160
- Now that reconcileAccountsWithAccountManager() is static, we don't need to
instantiate SyncManager.
- Don't need to set mResolver. reconcileAccountsWithAccountManager() doesn't
use it.
