* 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
* It's reported that 50% of third party users have issues syncing
Calendar in Exchange
* In testing, it was determined that the server takes > 30 seconds
to respond to a sync request initially, which is beyond our timeout
limit
* Also, I found that the system SyncManager was trying to trigger an
upload sync at the same time (i.e. before the sync session was
established with the server)
* There are four changes here:
1) Prevent upload syncs while the sync key is null or "0" ("0"
is the initial state)
2) Increase timeout for connection; at worst, this will
cause a short extra delay in syncs with a bad connection, but this
will be unnoticable to users
3) Increase the read timeout for initial sync to twice that of
regular syncs (the initial sync always seems to take longer)
3) Reduce the lookback for calendar to two weeks (from one month);
this is a better default anyway, and it probably reduces the server
and client load a great deal
* Empirically, this solves the bug for a known completely repeatable
case.
Bug: 2569162
Change-Id: I36b1c3e1e0b65f50d42e05f1830fed912191651f
and Contacts, so that when you relaunch Email from Home, you always see
the Email app, not Calendar/Contacts.
Note as stated in the corresponding bug, this CL itself won't fix the issue,
because CLEAR_WHEN_TASK_RESET will be lost when Contacts/Calendar apps handle
the intent.
There's a feature request against the framework (bug 2586404) which should fix
this losing flag problem.
Bug 2584792
Change-Id: I34ac3707b99926fc07529ea2229f2a6b3c4f93e4
* 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
* 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 allowing all sync services to attempt provisioning, but this
could potentially lead to a race condition in which two different
policy keys are created on the server (this is speculative)
* Change to allow only the account mailbox to attempt provisioning
* Log policy keys when verbose exchange logging is enabled
* We'll see if this solves the referenced bug
Bug: 2569162
Change-Id: I36c60098a4866882a8f9f4c288da54ea378d9aee
* 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
* Accounts that require security need to check that the Email app
is still an active device admin from time to time
* Add a check for this before each run of the ping loop
Bug: 2583282
Change-Id: I1491821b7d0c1a341b1fe7ef1002c8b21aed12c2
* 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
I shouldn't have changed the layout_height.
I changed it as a trial, and the final version of the fix didn't require this.
Bug 2581421
Change-Id: Ie06f813ed6d65a128381a99b9efeaa8d9275b5bf
It's unfortunate but some of the fields we cleared in I34451000 are accessed
in BG threads or after the activity is destroyed. We could add != null checks
everywhere, but it'll be a mess. I also think it's safer to simply remove
the "= null" lines.
On the other hand, clearing AsyncTasks are relatively safer because they are
kept only so that we can cancel them afterwards, so I kept them. But let me
know if you want to revert the original CL.
Bug 2570603
Change-Id: I04a10dd7382bfcceb686c3e9af92f8949caf619e
* 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
* Make yes, no, maybe, etc. larger (easier to touch)
(bug #2561772)
* Make the accept/decline/maybe buttons focusable
Make the "View in Calender" a button
(bug #2561767)
Change-Id: I5b68041835e9d85e5290a30fe7910837b577c003
* Handle the case in which a Mailbox to be synced doesn't have
a serverId (rare case which happened to a Zimbra user)
* Tweak logging to improve debugability of similar issues
Bug: 2551196
Change-Id: Id61cee5c4b33eb2f87455fbae0899fec8ff3748f
* 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
* Simplify the logic in the onDisabled() receiver. Make sure
security policy keys are *always* disabled.
* Eliminate unused variable and unused receiver.
Bug: 2576145
Change-Id: I3665a1d300edfb77e02737c08aee22bc977f4968
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
* Track whether the user clicked "manual" vs. clicking next (and falling
into "manual" because the account is not found in the providers list.
Convert this into an "allowAutoDiscover" parameter.
* Pass "allowAutoDiscover" down into AccountSetupAccountType and through
into AccountSetupExchange. (Note, it's unused/ignored for POP & IMAP
accounts and should not affect them.)
* In AccountSetupExchange, use the existing EXTRA_DISABLE_AUTO_DISCOVER
(previously only for testing) to suppress autodiscover in manual mode.
Bug: 2570919
Change-Id: I2583e00d1e6cc26bbd4b85134eddae8cc3a1f91e
* Split out network operations w/ timeout and watchdog from send HttpClientPost
* Use this in autodiscover calls
* Add logging to help debug this issue, in case there are additional problems
Bug: 2568077
Change-Id: I2a2e1abca2c4dab02c8e04c304f67db2a7b4cb22
* In Controller, map EmailServiceStatus.SECURITY_FAILURE
to MessagingException.SECURITY_POLICIES_REQUIRED
* In MessageList, map MessagingException.SECURITY_POLICIES_REQUIRED
to string account_setup_failed_security
Bug report will be forwarded to next release to get a more specific
string with proper translation.
Bug: 2563988
Change-Id: Ia1e6e947e3c0c7e6bd37301de2ea8ef4d641ef14
* 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
