* We weren't checking calendar id along with original event id when
uploading (original event id isn't unique)
* Fix the query selection to ensure finding the correct exception(s)
Bug: 2545659
Change-Id: I276dd10e2be171bd9d4f3300cdc8843bb28f2781
* Use one minute before/after for transition checking, instead of the
sloppier early version
* Add tests for additional known time zones
* Change most methods in CalendarUtilities to package private (for use
with unit tests)
* Clean up a little bad formatting
Change-Id: I9e5be5e1c859f2294adf06874459f7db15fb8c22
* EAS 2.5 doesn't like seeing bare LF's in Calendar location
and description, and Events including them won't sync back to
the server
* Create a utility to replace bare LF's with CRLF and write
unit test for the utility
* Fix the bug by using this utility
Bug: 2542220
Change-Id: I2c72d23f15e3a922ebe3585e063abe9fa9e2366f
* AccountObservers do a fair amount of database access, and all of
this should be done in a background thread, so we'll move it there
Bug: 2545753
Change-Id: I5a38677213a923d44eadade75ae32e151e9100da
* Calendar observer code does database access (sometimes quite a
lot), so it shouldn't be run in the UI thread
Change-Id: Ib6ec5ac3105df6d3fc45004dc2b09be4e33a11ac
* Fix the transition times so that they occur at the hour
* Remove an unused variable
* Fix a reference to Calendar.HOUR that should have been
Calendar.HOUR_OF_DAY
* Confirm that unit tests work properly
Change-Id: I3eaf31d160e97b5f3ba59c83878359085aea960d
* Remove some very old code that updated the Account in the database
when finishing an EAS FolderSync. The old code saved away the entire
Account structure using getContentValues(), which has long been recognized
as dangerous, since the data being saved might be stale.
* In this case, we were clearing the INCOMPLETE flag in another thread, but
FolderSync was saving away the old value (with INCOMPLETE set) along with
all of the other columns.
* Ironically, the old code is entirely obsolete, so the solution is to
simply remove the update call.
Bug: 2501574
Change-Id: I9eccbde40e05c83ec5f0ab1d3387289286acc5f3
* Previously, we would send "0", which is just wrong. Better to
send nothing
* Make sure that all tests pass
Bug: 2531679
Change-Id: I01412c6c6f7a2570fafadede75671012b917d25b
* Previously, we handled the error case for security related errors
* Add code to fail on ANY error, and in particular to recognize the
error in which an OWA server address is used instead of an EAS
server address
Bug: 2494110
Change-Id: Iab7df56e82f5ff73b1f58d386ec6f844db26a312
* Sanity check runs through every TimeZone and makes sure that there
are no exceptions thrown
* Also, that we find at least 10x as many TimeZone's with RRULEs as
those without (empirical)
Change-Id: I2f266ac9d2a839f053bb5fda10a5b77dc8dd2c04
There are a few places where we don't do the check in restoreMailboxWithId,
but they don't look trivial enough for me to fix.
Bug 2530534
Change-Id: I77b37a87ef108048077f14c1e8a3457ee494100a
* Properly parse the server's supported versions
* Choose the highest server version that we support
* Fail with MessagingException if we don't support any server
versions
Bug: 2527408
Change-Id: I0a2822c8fab31a65c8fea9b78b4a8c23df1804a3
* We were sending cancellations with a request for reply, which is
incorrect
* Send the correct dats in the ics attachment
* Update unit test to reflect this
Bug: 2527606
Change-Id: I4cea0bb8f1c29a3cad8d09fd6a4750f7ab067229
* An ANR was reported in MailboxAlarmReceiver
* The reciever calls into SyncManager, which does some database
operations, and may abort an I/O operation in a sync service
thread
* Move this potentially long-running code into a background
thread
Bug: 2215045
Change-Id: Id65c51f706b212d6b50af3921f3ba3dc2d014ce0
* There was a TODO for this... :-)
* First, I added some logging to help debug this kind of situation
in the future
* I also now forcibly stop any ongoing sync of the calendar being
disabled; this appears related to the problem of Events not
reappearing
* Added a kick() after the calendar is re-enabled to make sure it
starts resyncing immediately.
Bug: 2526924
Change-Id: Ib18f4c3c4e016f5cb5205fea5f3f12c0782b5e54
* Add "vibrate when silent" choice in UI
* Add storage for it in Email's provider. Existing accounts default to
their current settings (always vibrate / never vibrate).
* Respect new mode when notifications are posted
* Updated existing unit tests
Bug: 2457183
Change-Id: I5c933ac39dbef8b2028255f330e0b084a445421a
* We now keep track of attendees in the Event's extended properties
* When a message is updated, we compare current attendees with the
original list, and send cancellations to those who have been removed
Bug: 25623726
Change-Id: I7b3df99e62fb3d4a1482bd6d4612647f5bdb756a
* Yahoo! is not supporting search by UID so I can't identify the new
the UID after I upload. This inability to correlate the local and
remote messages means that we wind up syncing the same message back
down, in a loop, which spawns more messages.
* Yahoo! has partial support for UIDPLUS, and reports the new UID when
I append (upload) messages.
* Modify IMAP parser to parse response lists
* When APPENDUID is reported, use it (and skip the search)
* Modify the few other existing users of response lists to use the
parsed versions instead. Provided a couple of lightweight utilities
to make it easier to work with ImapList.
* Unit tests for most of it.
* Optimization: share a static date/time parser for all IMAP connections
Bug: 2448220
Change-Id: Ic10fc1a195ccf4671a498188cc8b17848c8d9df7
* There are serious issues with showing consistent and accurate attendee
status for Exchange 2007 events
* Unless and until these can be resolved, it is better to simply not show
the user the supposed attendee status (since it might well be wrong)
* In this CL, I never set the attendee status; therefore, it will appear
"unknown" and be shown simply as "Guest" when viewing the Event in the
Calendar app.
* Will create tracking bug for this, so that we can revisit for a later
release.
Bug: 2524410
Change-Id: I97fdd26750c68ff25bbb102547071c728e4124a9
* Most clients send name= in the content-type, but a few clients
send only filename= in content-disposition.
* There was code to handle both cases, but due to two typos, it didn't
work.
* Most easily reproduced by sending from hotmail/live web client.
Bug: 2366961
Change-Id: I1d9a00b9b5fd1094cfb8566c3248d94286a8ae91
* Quick fix for the bug that notifications may be stale after
and account is deleted.
Bug: 2202317
Change-Id: I950d173d20dee443b03b40ee04618afb98a95f38
It's useful to debug MIME related problems.
- New MimeStreamParser.LOG_MESSAGE flag
- Cleaned up LoggingInputStream, which now supports all InputStream methods
(e.g. close, available, etc.) properly.
- LoggingInputStream now dumps non-printable ascii chars as '\xXX'.
Change-Id: I4391e125abd418defc1dc21e4f35cf6ef8448acb
