Make the date parser accept invalid dates like
"Thu, 10 Dec 09 15:08:08 GMT-0700" which was observed in an email from eBay.
Per RFC, timezone must be either obs-zone (e.g. "GMT") or +/- with 4 digits.
The GMT+/-digits format is not permitted.
Bug 2367124
Change-Id: I59968274160aeadea70223208b463ee692660056
Follow up to I3bf7d340. Make sure temp directory is set before running tests.
Turned out Application.onCreate doesn't seem to be guaranteed to be run
before unit tests.
Without this, some tests may fail saying: "TempDirectory not set.
Application hasn't started??", if onCreate runs too late.
Change-Id: Ic5aee939a2c21f9579a643d0729dd0e9ba81022e
* 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
* Enforce CalendarProvider2's requirements for valid Events
* Add unit tests for the new code
Bug: 2658149
Change-Id: I42ad7acbcee3b6b831f805c59436017a32651f3a
* 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
Makoto Onuki