* Make "Exchange" option in account setup depend upon availability of the
Exchange EmailService
* Make presence of Exchange logging depend upon availability of the
Exchange EmailService
* Make AttachmentDownloadService use service rather than ExchangeService
class
* Move SSLUtils to emailcommon/utility
* Move account manager type defs to emailcommon/AccountManagerTypes
* Update proguard.flags
* This is the penultimate CL for the Email package itself; the next CL
creates a clean, SDK-compatible Email application
Bug: 3442973
Change-Id: I9162cf5fa6b5a043ded0fdd1e25fd3ce5948ad8f
* There are three pieces to this CL (sorry):
1) Move and/or rename some constants into emailcommon
2) Move Utility to emailcommon, moving the few UI
related utilities back into Email (FolderProperties
and UiUtilities)
3) Remove all references to resources from emailcommon
* The three pieces relate in that, between them, they allow
the emailcommon static library to compile cleanly
Bug: 3442973
Change-Id: Ic5e3abaa2a1b36999e0b6653c6c2134ea1bd544f
* CalendarProvider2 has unusual semantics for its delete operation on
Calendars; this caused the user's calendar NOT to be deleted when
the server commanded a wipe of calendar data. The result was
duplication of events after the subsequent resync
Bug: 3361000
Change-Id: I672034a7a444eb7ebdea60cd6dc66a31087cc6f7
* Hoist wipe() method from AbstractSyncParser to AbstractSyncAdapter
* Add deleteAccountPIMData(accountId) to the EmailService API
* Implement deleteAccountPIMData for EAS
Change-Id: I1037cde25fc2b24419f399446cfa0906dc0174d1
* Apparently, Exchange 2003 doesn't like to see Visibility set in
Exceptions
* Apparently, Exchange 2003 likes to see Exception Deleted and
ExceptionStartTime prior to other data
* The word "apparently" is used above to indicate that these
findings are not part of any specification, but have been
determined empirically
Bug: 2775885
Change-Id: I163f156675f65c494a59d5233b2b6e23b3f1d6a0
* Load MIME data for these messages and parse, looking for a body either
in HTML or plain text or both
* If the MIME data had been trunctated and we can't find text, mark the
message as partially loaded and load the body text as we did before
(i.e. get the plain text body); this should be a rare case
TODO: Consider what is testable in the new EmailSyncAdapter code
Change-Id: I00a3066a373a0596431335593de356a4dda7f036
* Turns out that we weren't handling one of the cases for YEARLY
RRULE; that in which the date is specified as a day of week plus
week of month
* Also, we weren't always sending the INTERVAL properly in a few
cases
* Fix these issues and add a unit test that confirms the fixes
* Also removed an unused argument in recurrenceParser in
CalendarSyncAdapter
Bug: 2718948
Change-Id: If9146d484218e7d6bd9f5c2305d0e6a216aeed49
* Created MockProvider that can be used for testing the results of
ContentProviderOperation's for Calendar/Contacts (we can't use these
within our mock contexts because we can't instantiate the provider
classes within the Email package)
* Wrote some unit tests for MockProvider
* Use MockProvider to test addEvent, in particular how a user's attendee
status is stored, depending on whether the event is new or updated
Change-Id: I97f02d125eb7347726261e12ce70aadc539be1d4
* The meaning of a busy status of "Busy" is uncertain; it could mean
"Accepted" or "Tentative", depending on whether the event was
created via OWA/Outlook or EAS
* We have interpreted it as "Accepted", which prevents the user from
actually accepting the event (as a state change is required for us
to send updates to the server/organizer)
* This CL changes the behavior such that a newly arriving event with
a "Busy" status is shown as "No response" in the Calendar, thereby
allowing the user to pick from any of the three possible options.
Bug: 2811859
Change-Id: Ie2c375278b79b47dedac02472dfe6e4cf1182b65
* During the fix of a previous late-Froyo issue, a change was made that
appeared superficially correct, but was semantically incorrect. This
changed the sense of the test for whether a reply email was required
and caused the referenced bug.
* The trivial fix is to replace the test with the (older) proper one
Bug: 2764551
Change-Id: I7c72366252cf0607aee31ee0d76aca96a7d5fc2b
* We're seeing binder transaction failures when we try to send more than around
1500 CPO's to CalendarProvider2 in a batch (the limit is related to memory
usage in binder transactions)
* When an event has A attendees and E exceptions in an event, we currently must
create A*E CPO's; this number can become very large and cause a binder failure
* The result of a failure is looping behavior, resulting in failed sync and very
much reduced battery life
* The workaround here is to redact all non-organizer and non-user attendees from
exceptions once we reach half of the maximum number of CPO's. This has been
determined empirically and is set to 500 CPO's in this CL
* We also reduce our sync "window" to 4 calendar/contact items per sync command
to help limit the potential size of our batch
* For later releases, we should reconsider this and see if something that is more
of a "fix", rather than a workaround, can be implemented
Bug: 2760514
Change-Id: I06ca1a1ae88c772342a9e46b5997c41678e95144
* We're seeing binder transaction failures when we try to send more than around
1500 CPO's to CalendarProvider2 in a batch (the limit is related to memory
usage in binder transactions)
* When an event has A attendees and E exceptions in an event, we currently must
create A*E CPO's; this number can become very large and cause a binder failure
* The result of a failure is looping behavior, resulting in failed sync and very
much reduced battery life
* The workaround here is to redact all non-organizer and non-user attendees from
exceptions once we reach half of the maximum number of CPO's. This has been
determined empirically and is set to 500 CPO's in this CL
* We also reduce our sync "window" to 4 calendar/contact items per sync command
to help limit the potential size of our batch
* For later releases, we should reconsider this and see if something that is more
of a "fix", rather than a workaround, can be implemented
Bug: 2760514
Change-Id: I2941b392ae1058a9ead8a79f0ac73f4eb345917d
* A recent change assumed that organizerEmail couldn't be null while
an event was being added. However, there is an unusual case in
which it CAN be null, and this CL handles that case
* Regression caused by: SHA 7f448dcd47
Bug: 2719254
Change-Id: Idb8fc79c898bcd2e53fcc8b3e42d0ba67ba762fa
* If there are over 50 attendees in an event, we only store the
organizer as an attendee (the rest are redacted) and we set
the hasAttendeeData flag to 0
* If the user is the organizer, we reset the owner of the event
to a bogus address, which causes the UI to prevent edits to
the event (we can't upload without losing all of the attendee
information on the server). We also prevent the event from ever
being uploaded (belt & suspenders)
* If the user is an attendee, we allow changes to be uploaded
(this would be attendee status and free/busy), but the list of
attendees on the server is removed.
* We also mark events with redacted attendees, even though we don't
use that information currently. In a future version, however,
we could use this to indicate the redacted state to the user.
Bug: 2709816
Change-Id: I2b44af59c598cedf906af12bf9b4eaf7484b9d20
* In bug 2703075, all-day events from time zones at GMT or later
appear a day early; this is because the time was calculated from
the GMT date/time of the event rather than the local date/time of
the event; this CL correctly changes this to use local date/time
* In bug 2707966, device-edited all-day events disappear in Outlook
and OWA after upsync; this is due to the fact that we store all-day
events in UTC on device, whereas we need to upload all-day events
using the original (local) time zone. In this CL, we save away
the original time zone and use it on upsync
* In our decoding of Exchange time zone information, we default to
local time when we can't find a time zone that matches the bias
and DST information; we should really default to a time zone with
the same bias, if one exists; we do that in this CL.
* Add/modify unit tests
Bug: 2703075
Change-Id: Id80c481ecc0eae980b2e91dae7f105f924cfca28
* Code for updating attendees in CalendarProvider2 wasn't taking
an attendees-only update into consideration
* Fix code to allow for this, including proper updates for our
selfAttendeeStatus and attendees ExtendedProperty values
Bug: 2668682
Change-Id: I8c7deb971cd0b6846c09ee3cd603f6fc762a9407
* 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
* 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
* We were previously storing the user's attendee status in the
SYNC_ADAPTER_DATA column of the Event, but it turns out that
this data isn't available in the Entity we retrieve when
uploading changes to the server
* The result is that we often thought the user's status had
changed when in fact it had not; in these cases, we sent email
to the organizer, often with the wrong information.
* As of this CL, we store the user's attendee status in an
ExtendedProperties row (these values are already exposed in event
entities)
* The logic otherwise remains the same; we now get correct data,
however
Bug: 2638762
Change-Id: Ibe8db90c16b4ca06203f77fd010aa26dde89a556
* 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
* Exchange has been using METHOD_DEFAULT for reminders, but it turns out
that this doesn't work.
* Changed to use METHOD_ALERT
Bug: 2604156
Change-Id: Ia76bb2fc150202de9c49af9ab8caf86c9bda775f
* All day events are supposed to be stored w/ UTC as the time zone
* We already zero out hour, minute, and day
* Use DTEND for non-recurring and DURATION for recurring all day events
Bug: 2440161
Change-Id: I31f2e5a355b721c06b4022b57ccc8a29b288a5d9
* Set selfAttendeeStatus on download from busy status
* Set busyStatus on upload from selfAttendeeStatus
Bug: 2587076
Change-Id: I34eaa0d3861bcec0cbfd51761b31965e44f5162b
* We were setting this for all events, but apparently CalendarProvider
does not approve, and generates warnings
* Only set this for exceptions
Bug: 2550631
Change-Id: I8a7152eb0d4233432b1a5b5664da964d5433fbae
* It turns out that this bug is due to a bad rebase/merge for a previous CL
in which the changed code appears in its new form AND old form
* Fixes change SHA c3aa318200 (CL 48406)
* Don't say it.
Bug: 2587775
Change-Id: I3f70a97e498db30345452b942909448049680fdf
* We weren't sending a proper ics file for the deleted attendee, and
this caused Exchange to send a message to the wrong people (the
referenced bug)
* Split out code that adds attendees to outgoing mail
* Changed the optional last argument to createMessageForX to be a specified
attendee, i.e. the only addressee to be used for the message
Bug: 2548465
Change-Id: I629fcfaffe621408ea460d42c9c7c283929f7e79
* With multiple accounts, serverId's are not guaranteed to be unique
(indeed, they rarely are)
* There were two queries in CalendarSyncAdapter that checked only
serverId and this has caused the referenced bug PLUS others that
would have turned up later on
* This is a critical fix
Bug: 2589815
Change-Id: I49bc6cb5bb4708f4bf4ca60a891ff78f0b25e989
* We weren't sending up the event description with exceptions, so
changes to description were being lost on upload
* Move the code uploading description so that it happens with
exceptions as well as top-level events
Bug: 2590020
Change-Id: Ifab556bed68671f3ee8cab02b657adbd8ba9c50c
* We were adding deleted exceptions to the "deleted" list; this is bad,
because the exception then gets deleted from the database after the
sync. The symptom is that the deleted exception reappears on the
calendar.
Bug: 2587837
Change-Id: If497f82ba0b2b817d1cef6165ded23d19876528f
* We were assuming a single day for all-day events
* Use the actual end date
* Make sure we send date/time back to server in local TZ
* Also fixes#2500863
Bug: 2578776
Change-Id: I58767a574248935b9840ce93e634a24e54abe62f
* We need to send name & email for Exchange 2007
* For Exchange 2003, only name & email if the event is new
Bug: 2586661
Change-Id: Ia35c2c7a645a3d20b7031e9a43b8b5044a40f005
* Meeting status differentiates between appointments and meetings,
which is important in Outlook and OWA
* Fix older, completely incorrect code for upsyncing categories
Bug: 2586071
Change-Id: I277252ef2c31e5b8ec7ceda69c229f5fd100ecdb
* Exceptions take a copy of Attendees when they are created, but
we weren't adding the organizer to Attendees before exceptions
were parsed
* Fix this by adding the organizer just before exception parsing
* If there aren't any exceptions, we add the organizer as before
Bug: 2585817
Change-Id: Ie894682977e38a55d975135c8fc2fd8f2d4b1365
* First, make sure we catch the cases of DELETED=1 and eventStatus=cancelled
* Second, only send email updates if the user is the organizer
Bug: 2583054
Change-Id: I886efa0f28931dc815bc31d4d6adb3d700f83c6b
* Use AS_SYNC_ADAPTER flag when changing attendee information in
downsyncs
* Allow DTSTAMP to come before new attendee information in the case
in which only attendees are changing
* Add _SYNC_DATA of "0" for all newly synced events
Bug: 2582513
Change-Id: Iacde0ddf3f2a99d108e00ef1991edfc34613f5c7
* Right now, we only send this for 2.5 (where it's required)
* If we don't send this for 12.0 and later, the status will be
set to "free", which is almost always going to be wrong
* So always send busy status = 2 (we can't know differently, as
we don't track free/busy)
Bug: 2575611
Change-Id: I11d952b68ac0ef7a022b030037ce6408f72d4a90
* When the sync state of Calendar/Contacts is changed, a number of observer calls
are triggered. In addition, we might have a running sync.
* The syncKey operations need to be synchronized, because we may otherwise
inadvertently use stale data when syncing, which would cause symptoms
as seen in the referenced bug
Bug: 2561864
Change-Id: I03db58fe01c45778d271fad34d8d4940edefe8fe
* We were queueing up emails during our upsync, but before the upsync
was complete. If there were connection issues, we could pile up
multiple copies of the same message, each of which would eventually
get sent out
* Fix is to simply queue up the outgoing mail and send it all after
the sync operation is complete.
Bug: 2515975
Change-Id: Ide3eb2deb6e959d0637d28efabd613efb3c6e209
* Had to add an optional argument to the email creator for this case,
since there may not be any remaining addressees to send to (if the
only guest was uninvited)
* The optional argument forces the creation of a message, even if there
are no addressees
Bug: 2548465
Change-Id: I88784f49ce7afedce331fc756c5ecef4e73a07bc
* Prior fix used the wrong column when adding time zone information
to downloaded exceptions
Bug: 2548436
Change-Id: Idc1001fd58d2fba51823624a15862fe439c9ff6a
Marc Blank