* Handle status 5 for Ping command (heartbeat of out range)
* Write unit test for heartbeat reset
Bug: 2834195
Change-Id: Ic7952a4b296cf15c6ba895d6579fe7956b171e5b
When connecting to an IMAP, POP3, or SMTP server using SSL, perform
an explicit test of the certificate's host name against the server's
host name. Refuse connection if they do not match.
Bug: 2807409
Change-Id: Ib223170f1a5d57323a88037ad30fec15c6bbce20
* 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
* 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
* While working w/ Microsoft on this issue, we determined that Windows
Mobile 6.0 does not suffer from this issue; when we compared our
logs with those from the WM client, we noticed a difference in the
commands being sent to the server on initial sync (we send some extra
options whereas WM doesnot)
* As an experiment, I removed these options from the initial
sync, and this change solved the problem with a persistently unsyncable
account (time to receive: 60-70 seconds vs. > 240 seconds).
* The fix is to remove all "options" from the initial sync for a given
collection (i.e. with SyncKey=0)
* Note that Microsoft's documentation does not generally address the issue
of what should/should not be sent in an initial sync command
Bug: 2569162
Change-Id: Ib20ea56fb380ee8c9a01b139f7fa98b7ff505e7a
* Microsoft has documented cases in which the server can continue to
send MoreAvailable=true even when no new data is received. This
can cause looping behavior, which we stop when we recognize it.
* This workaround, however, can prevent the situation from resolving
itself, and lead to delayed sync (up to a few hours has been noticed)
* In this limited CL, we allow the sync to loop up to a maximum number
of times before stopping it forcibly.
Bug: 2685984
Change-Id: I2913b7e3438f6180c3c440508fab892176a06540
* Some autodiscover servers appear to require the bare user name
for authentication rather than the user's email address. This
is apparently common for complex organizations maintaining a
group of email domains
* If we get a 401 when trying to connect to an autodiscover server
using the email address, we try again using just the bare name
Bug: 2682833
Change-Id: Ia07ca336e189069d4f3539e2245b3d53c82e3324
* 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
* When sync threads get blocked by SSL/Socket code, we detect this
and shutdown the ClientConnectionManager, hoping this will solve
the problem.
* Apparently, this doesn't always work. The result is that syncs
are frozen until the device is rebooted (certainly) or until the
Email process is stopped and restarted (hopefully)
* This CL kills the Email process after an unsuccessful attempt to
clear blocked threads using ClientConnectionManager.shutdown()
Bug: 2615293
Change-Id: I8445b278817e508a855adeb88d6b2f969d28858b
* 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
* There is a race condition in which the AccountManager listener
isn't properly unregistered when SyncManager is shut down
* In this case, SyncManager tries to register a new listener
(i.e. registering again), which causes an IllegalArgumentException
* The quick workaround is simply to catch and ignore this exception,
as it's really more of a warning than a true error
* A bug will be filed for the underlying issue
Bug: 2631561
Change-Id: I139d24ae045d402d4d8cb006406ef96ccc768566
* 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
* Exchange seems to require time zone information in ics files containing
event exceptions, although this is NOT the case for iCalendar, and appears
not to conform to VCALENDAR specifications
* This causes exceptions to be placed on the wrong date or perhaps even
ignored, depending on the circumstance
* This CL simply adds time zone information to all exception ics files
Bug: 2640878
Change-Id: Ibc614eb7a2c45e9e782b10be979d9892bbfc0029
* The regression is caused by a check on whether the calendar is
syncable, as determined by the status of the Calendar (via
CalendarProvider2).
* Unfortunately, if there IS no calendar, we were disallowing sync,
which prevents the calendar from being created in the first place
Bug: 2619755
Change-Id: I1e94a129413bdbe9bc9bfb3608d3ca95f23d8dfb
* The current timeout is triggering more often than it should, which
causes delays and inefficiency. Increase it from 10 to 30 seconds.
Bug: 2615293
Change-Id: I54b74cc7ad9f1c8286af49b957584670c071640c
* When a sync thread receives an alarm due to a missed socket timeout
on an HttpPost, we try to abort the HttpPost.
* At times, however, the HttpPost cannot be aborted and the thread
hangs indefinitely.
* In this CL, we try to break this vicious cycle by shutting down our
ClientConnectionManager when this case is detected. This should, in
turn, close all of our socket connections, causing the sync threads
to generate IOExceptions and terminate.
* After appropriate IOException waits, new sync threads should then be
able to run normally.
Bug: 2615293
Change-Id: Idea6c3653cd60822d6260e0c5a7dad790ee25858
Doing the check caused:
IllegalArgumentException: Unknown URI content://com.android.email.provider/account/-1
at com.android.email.provider.EmailProvider.query(EmailProvider.java:1092)
at android.content.ContentProvider$Transport.query(ContentProvider.java:163)
at android.content.ContentResolver.query(ContentResolver.java:245)
at com.android.email.activity.MessageList.isSecurityHold(MessageList.java:1146)
Bug 2635060
Change-Id: I80e7c00ef2dd74ceae24a88daf43a0681124a9d4
* When SyncManager starts up, it reconciles the AccountManager sync settings
with its own
* This works for Contacts, but Calendar has a second setting that needs to be
checked - the sync_events column in the Calendar table (in CalendarProvider2)
* Before turning on Calendar sync, we now check this second setting; if
sync_events is 0, we won't re-enable Calendar sync
Bug: 2619755
Change-Id: Iea6c99dce228d2c111a529a6c9b865ed1577b19e
* When a sync thread triggers an alarm by failing to return from
an HttpPost beyond the socket timeout, we call abort() on the
HttpPost to force it to stop
* It appears that there are cases in which this is insufficient,
and the thread remains hung in a blocked state
* The result of this failure is to prevent the syncing mailbox from
ever syncing again, and is typically seen by a failure to receive
new mail (as reported in the referenced bug)
* In this CL, we add code to wait for 10 seconds after calling the
abort() method. If the HttpPost is still hung, we interrupt() the
thread, and have SyncManager release the Mailbox, so that another
thread can be started.
Bug: 2615293
Change-Id: I6a48195fc68bb950126006326a5b30448d3bbb63
* Make sure we send UNTIL with FREQ=DAILY as appropriate
* Also to help debug this in the future...
Add logging capability to utilities via SyncManager
Add public log methods so that CalendarUtilities can log properly
Change Log.d's to SyncManager.log in CalendarUtilities
Bug: 2623787
Change-Id: I3d651f00a3f7522e25c8d6e389469770c733953f
