* 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
Merge commit 'ab4daabd5ec99da549407ce87d46e24be261c4a6' into kraken
* commit 'ab4daabd5ec99da549407ce87d46e24be261c4a6':
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
* 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
Merge commit '44ae6d2fa2e79de533ceb1fdf50c578a4ed84a3f' into kraken
* commit '44ae6d2fa2e79de533ceb1fdf50c578a4ed84a3f':
Update unit tests for invitation creation
Merge commit 'f1fa44bdc064a6c01813c5380839b90bd0290d46' into kraken
* commit 'f1fa44bdc064a6c01813c5380839b90bd0290d46':
Fix upload/download of attendee status
* It turns out that the UI uses selfAttendeeStatus and the attendee's status
from the Attendees table in confusing and undocumented ways
* selfAttendeeStatus is used in the UI, but only in certain cases. Generally speaking,
the Attendees table status is definitive. However, when the user sets his status
from the UI, this data is reflected in the event's selfAttendeeStatus, since for EAS,
the user is always the owner of his calendar
* On downsync, we'll put the user's busy status into the Attendees table
* On upsync, we'll send busy status based on the user's attendee status in the
Attendees table
* We'll use selfAttendeeStatus only to determine whether the user has manually changed
his status via the UI (as before)
Bug: 2615586
Change-Id: I3a82474cfd07cbf5aa595e5214807cb55005cefa
Merge commit 'd764ce7e4442b0027a891582cbdd728487a49f97' into kraken
* commit 'd764ce7e4442b0027a891582cbdd728487a49f97':
Send correct busy status information in upsyncs to EAS
Merge commit '825999f815979519d8d80334a8c1ce0223a89ef2' into kraken
* commit '825999f815979519d8d80334a8c1ce0223a89ef2':
Set selfAttendeeStatus and busyStatus properly on downsync/upsync
* Set selfAttendeeStatus on download from busy status
* Set busyStatus on upload from selfAttendeeStatus
Bug: 2587076
Change-Id: I34eaa0d3861bcec0cbfd51761b31965e44f5162b
Merge commit 'b8ef8a2c1d18421a7d537dbc8d1ea88ffca95898' into kraken
* commit 'b8ef8a2c1d18421a7d537dbc8d1ea88ffca95898':
Properly decode a uid from the globalObjId in invites
* Meeting invitations in EAS include a globalObjId. It turns out
that this id is EITHER the actual uid (if Exchange created it)
or a wrapper for the actual uid (if some other client created it)
* To find out which case we're dealing with, we have to look at
the base64 decoded string for the magic "vCal-Uid" substring
* If it's there, we pull the real uid out of the decoded string
* Otherwise, we build a hex strong from the decoded bytes
* Write unit test for this process
Bug: 2598201
Change-Id: I1cc40af6d1e45be44c19465eb8a4c31851ec8157
Merge commit 'ad383ff1231319c6ded4077b0d1415bf77bec70b' into kraken
* commit 'ad383ff1231319c6ded4077b0d1415bf77bec70b':
Use consistent device-id even the device is wiped.
Merge commit '8dffa087db44e27e5f0e5672b19fdb6975e614a7' into kraken
* commit '8dffa087db44e27e5f0e5672b19fdb6975e614a7':
Change account colors to what aren't used in Calendar.
Merge commit '772758177e3dd4fcb1c9d534afec3007b59c8bf7' into kraken
* commit '772758177e3dd4fcb1c9d534afec3007b59c8bf7':
Show device id on the exchange setting screen.
I've attached a screenshot on the referenced bug.
Also fixed a bug in SyncManager.getDeviceId() where sDeviceId cache wasn't
working.
Bug 2591124
Change-Id: I4b58517c095a96d47fb57179d70091b2c7af5249
Merge commit 'ef01261a8909ea3fe3e40b06cc537e0032d47898' into kraken
* commit 'ef01261a8909ea3fe3e40b06cc537e0032d47898':
Try TOP even on POP servers that fail to report CAPA
* Ignore the results of CAPA and always try TOP
* If TOP returns -ERR simply fall back to (bad old slow) RETR
* Unit tests for positive & failure cases
Bug: 2588432
Change-Id: Ife4b551217de1025e14efc46074f16ef4ae99c6f
* Write MIME-Version: 1.0 in all outbound messages, not just those
with multiparts. This is required by RFC 2045.
* Unit tests
Bug: 1678296
Change-Id: Icf37d93b8b0150f490791792499865a60744adea
It's a preliminary change for IMAP bug fixes.
Also,
- Fixed a potential bug in ImapFolder.setFlags where it'd throw
StringIndexOutOfBoundsException if flags is empty.
- Added a generic flag to proguard.flags so that now all methods with
the "ForTest" sufix are automatically preserved.
Turned out it wasn't needed for this CL, but it should come in handy
someday.
Bug 2538076
Change-Id: I49a08afc196c7b7f1f30477dfc38ac5381045d84
When receiving the EHLO response from the SMTP server, the multiline
answer has "-" prefix in all lines except the last line, where the
prefix is a blank. This is according to RFC 2821 section 4.2.1. This has
also been reported as issue 2309 at code.google.com.
Bug: 1744768
Change-Id: I3feccabed30767d2fa5b06352cd7d1c803e8d59c
* If the server asks for more than we can support, don't throw
and error from PolicySet creation. Let isSupported() do that.
* Overlong password lengths cannot be supported and isSupported is false.
* Overlong timeouts & max wipes can be reduced to supported
amount (this actually increases security) and isSupported is true.
* Clean up an obsolete comment
* Unit tests
Bug: 2567804
Change-Id: I2d664a7f2a315b9f9bdcb867fe2cd98f74de6f66
* Turns out that most other clients omit this.
* This has the pleasing effect of fixing the referenced bug
* Update unit tests
Bug: 2561821
Change-Id: I39f7db7e05be590373cd5f3d9b23c7ee21bde4f7
* Because we were sending these in the wrong format, upsynced changes
were failing, with the result that both the original event and
the "new" event (from the UNTIL date forward) remained in the calendar
* Fix is to send the proper format; unit test updated to reflect the
change
* Also, we only send the date of an UNTIL, rather than the to-the-minute
time; it turns out that EAS expects to see only a day for UNTIL.
Bug: 2561818
Change-Id: Ic4eacbe96c713d58c637386ceab2cf22ebe3c2d4
* We need to send date only (without time) in the VCALENDAR file for
all-day events
* Add unit test for this case
Bug: 2561789
Change-Id: I33a43c7a248059c97482ca147a23af083744118a
* We should be sending CANCEL as the method with cancellations
* Fix this and update unit test
Bug: 2527606
Change-Id: I2b982e4bfd1dbc57660cf578702edf49584d2957
A desktop shortcut to an account created on donut or before points at
com.android.email/.activity.FolderMessageList, which we've already removed.
- Added a dummy FolderMessageList to receive it and redirect to MessageList.
- Removed FolderMessageListUnitTests, which was left unremoved.
Bug 2535335
Change-Id: Ie5ffa158882633a4929c4c47a3d9625fd1626863
* 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
