This resolves cases like this: You are in the inbox of an Exchange
account. You click home, settings, accounts & sync, and you delete
the account. Now re-enter the Email app. You'll be left in a strangely
empty inbox, for an account that no longer exists.
* Set a flag any time the reconciler deletes an account
* Check that flag in onResume of any activity that depends on the account
list and could be left in an "empty" state if account(s) are deleted.
* The Activities in which we check it are:
* AccountFolderList
* AccountSettings
* MailboxList
* MessageCompose
* MessageList
* MessageView
* Clear the flag any time we come in through Welcome, which will dispatch
to other activities properly based on the number of accounts found.
Bug: 2563998
Change-Id: I00fc542581c2bed92d744a4c2e48a88f83737f11
* 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
* Now that we get proper callbacks on updateMailboxListCallback(),
show the error banner if there's a problem
* Follow-on to 63186a5442
Bug: 2585159
Change-Id: I2b4f365d02b639bc3ceff9f8938333185d5ba693
* 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 are still seeing an issue with at least one user on initial
calendar sync.
* Increase the read timeout a great deal for initial sync, as it
can a very long time for the server to respond
Bug: 2569162
Change-Id: I495c38dc58d9a80c5a21e40b6fc5d165d10a3c1a
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
* 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
* SecurityPolicy: Fix bug that prevents any notifications after the
user hits "cancel all" from the notification pane.
* AccountSecurity: If the user cancels the device admin acceptance
activity, repost the notification.
* MesageList: Catch security hold condition when entering a mailbox, and
launch security setup activity.
Bug: 2585159
Change-Id: I60d5d8c693cc5f00fe98a9cc69265802f5bee813
* 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
* 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
