* 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
* 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
* 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
* 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
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
* Turns out that Exchange 2003 requires the ics attachment to be in a
multipart/alternative, rather than a multipart/mixed MIME message
* Exchange 2007 accepts both types
* Therefore, we change our output for this particular situation, i.e.
a single attachment that is an ics file, to multipart/alternative
* Rename FLAG_SUPPRESS_CONTENT_DISPOSITION to FLAG_ICS_ALTERNATIVE_PART
and make this flag do double duty - 1) suppress the Content-Disposition
header (also required by Exchange) and 2) send the message as
multipart/alternative
* Add unit tests for Rfc822Output to check that mime parts are composed
properly
Bug: 2516394
Change-Id: I60e26f57b8ecaf01d0340e7828533334e0e7d45a
- Now SimpleIcsWriter does the UTF-8 conversion, and folds lines according
to the number of bytes in UTF-8.
- It now escapes special chars in TEXT values. You can safely put , ; \ or
line breaks. in summary, location, and description.
- Quotes all CN. (leftover from Ibb8f155a)
- Replace "s in CN with 's (rather than removing them)
Bug 2508283
Bug 2515768
Change-Id: Ibdced53ee32bba950608d63f507b11b24eaad7b0
* Add the (recurring) text when the invite is for a recurring
meeting
* Add a test for message text creation
Bug: 2515474
Change-Id: Ifefbc2ba1ac444175180cb7a58f4ec554d9674a3
* The utility wasn't handling commas properly, causing the referenced
bug
* Fixed the utility and updated the relevant test case
Bug: 2515488
Change-Id: Id229e50fcaaed1a0142db301eedaaba9209bed13
- In memory attachments are now stored as byte[], not String.
We can store any type of contents now.
- Added blob content_bytes to the Attachment table.
The content field is now deprecated and not used.
- Explicitly convert ICS files to UTF-8.
- Added Utility.to/fromUtf8().
Bug 2509287
Change-Id: I3785a365a9a34039ec12ba82bd857dcdbc4de92d
* We weren't sending out appropriate emails for exceptions and other
event updates
* Write exception specific ics file code in CalendarUtilities (in
the existing ics file creator)
* Send appropriate Update: subject for updated events/exceptions
* Compose simple message text consisting of:
When: <time>
Where: <location>
* Prepend message text for exceptions to indicate that the message
relates to a particular instance of the event:
This event has been canceled for: <date>
The details of this event have been changed for: <date>
* New strings were added in CL#44141
* Updated CalendarUtilities tests
Bug: 2501270
Change-Id: I920de8120bc56d5bd565cbde26ff4807be41579f
* Ignore CR and change LF into backslash + n
* Write unit test for handling of CRLF's
* Rename mLineCount to mColumnCount, which is more appropriate
Bug: 2508283
Change-Id: I8b2081aa474cb07b6cb09383ff6ac58a1dab1bba
I missed a case where message-id should not be set locally, which is
the case where the Mime parser clears all headers *and* does not find
a message-id. The parsed MimeMessage should accurately reflect this.
In the old code, the local id was created at construction time and then
immediately discarded by the parser (calling headers.clear()).
In the new code, I was generating a message-id any time I couldn't find
one. Now, when explicitly cleared or removed, I set a boolean to inhibit
automatic generation of a new one.
I also missed the fact that a missing message-id no longer throws an
exception, it simply returns null, and so I changed the code that was
catching that exception to simply check for null.
(Note: Clearly, modeling of legacy behavior is becoming annoying here;
It would be better to do away with all of the automatic logic, and simply
generate message-id locally when appropriate: On locally-generated
messages. I don't want to touch this for the current release, but I left
a note in the code to this effect.)
Bug: 2504774
Change-Id: Ibfcbd2363c7ae39ee6d44e4c3295f88258cb4945
Added DiscourseLogger, which stores last N (currently 64) lines of IMAP
commands sent to the server and responses received from the server.
We dump it to logcat when the IMAP parser crashes, that is, a) getting a
RuntimeException in ImapFolder.fetch() or b) getting a Runtime/IOException
in ImapResponseParser.
Bug 2480227
Change-Id: I6b5a728a7df106627ec29bb3c7c04a97a99b444b
Message and MimeMessage were creating a lot of unnecessary sub-objects
even when not needed, so do a bunch of lazy initialization. This should
raise the bar on the size of gigantic inboxes giving us trouble.
* Specific optimizations:
* Replace date formatter with a shared static
* lazy create mHeader (ArrayList)
* lazy create mFlags (HashSet)
* optimize MimeHeader fields class
* lazy create local message-ID (expensive-to-make uuid String)
* make message-id string less expensive to create
* Other cleanups:
* add some override annotations
* privatize some members
* update a fragile test (not a deep fix, it's still fragile)
Side effect, should be faster too.
Bug: 2357564
Bug: 2093422
Change-Id: I8a873879d402e2662339d5398ad0b15da6e580e9
This test has been failing since I60974b85, which is obviously correct,
so I modified the test.
Bug 2488770
Change-Id: I5a2eea19d9f3c3647b7c88a1e0db9297727b8e66
* Split account copy loop to do POP3 accounts first, then IMAP
* After upgrading accounts, upgrade folders
* Upgrade messages in those folders
* Preserve attachments on outgoing messages (e.g. drafts)
* Enable composer and start syncing after upgrade
* Fix latent bug in LocalStore (which was not used in Eclair)
* Add tests for upgrade workers in LegacyConversions
Bug: 2065528
* 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
* 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
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
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
* 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
* 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
