* 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
* Change "broken pipe" behavior to simply run through the ping loop
again, rather than be treated as a NAT timeout
Bug: 2615293
Change-Id: I67c3200f148a8c2beda58f812c29af8a726a4b9c
* When you have 2 or more accounts configured, MessageList gets confused.
* If you are viewing a mailbox from account A, and account B does a
background sync, MessageList gets confused by the reports coming back
from the Controller. It gives up and returns to the Accounts list.
* This change adds a check for the current account and ignores the
MessageList updates if we weren't actually waiting for them.
* To test the positive case for this code (make sure we didn't break it),
verify that the inbox on an IMAP account is displayed properly
immediately after you add it.
Bug: 2619513
Change-Id: Ib31254b4099ba6b7922b06d42e2b7928551e4fb2
* This prevents unnecessary delays in receiving push mail
* At present, there is a likely 5 minute delay on receiving new pushed
mail on the network displaying the behavior we're testing for
Bug: 2615293
Change-Id: Ic42e576fa683790f96434fcbad5ee873d0730f6d
* 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
* Harden each of the major upgrade steps so any errors (e.g. NPE) are
caught and that account goes into error state.
* Make sure that any account in error state is abandoned properly - all
steps skipped except the final delete/cleanup.
* Bugfix: The variable that indicates that an account has gone into an
error state (upgrade failed) state was being set in the UI thread and
tested in the worker thread, so it was not properly stopping the
upgrade of any given account. Split that variable into two, one for the
UI thread (set/read by the handler) and one for the worker thread.
* Bugfix: Report errors against the correct account, when 2+ accounts are
being upgraded.
Bug: 2608483
Change-Id: I571078ae7123b601b53096104c4c5f4ef20da031
* stopPing (in SyncManager) assumes that every mailbox has a serverId
but this is not the case on some servers, in which case we hit an
NPE during a check for the account mailbox
* Check for a null serverId when testing for the account mailbox
Bug: 2606385
Change-Id: Idfa8abd8ef9e2c0a2ac01d0b168a21c934f6fdf3
* The code assumed that if we asked for a remote wipe, that it would
be executed. This isn't the case, however, if we're not a device
admin at that time
* Test for Email app as device administrator before trying remote wipe
Bug: 2603931
Change-Id: I09dcff00e77bcf1e40c742c9dee923e6e07eecae
* 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
* Previously I added a call to updateBanner() during the sequence where
we update the mailboxlist (searching for the requested mailbox to
display.) This was an attempt to provide some error information
for certain corner case security configuration problems.
* This was misfiring during legitimate connections (specifically, initial
sync of valid EAS accounts) and causing a Connection Error message
when none was intended.
* Rather than continue hacking, I'm simply removing the error banner
from updateMailboxList.
* This is essentially a direct rollback of change
c98b64c801, although I've added
a bit more commentary than there was originally.
* The long-term solution, rather than continue band-aiding this, is to
move most of this logic into a service independent of the UI, and
provide more organized error reporting.
Bug: 2585159
Bug: 2599377
Change-Id: I99b7b1c8a7cfaa3fd3ff9b578d5721f05133d88a
* 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
* Monkey is hitting this fairly often
* Multiple fixes that are all good
* We were launching LoadAccountsTask twice
* Don't use a managed cursor for the inner accounts cursor - always
close it manually by calling changeCursor(null) and letting the
MergeCursor handle its sub-cursors.
* Add isCancelled() check
* When replacing adapter, be sure to close cursor
Bug: 2524465
Change-Id: I2309e033d65430810f2856285c1fa9bf2f8fb5e3
* This takes care of *some* of the race conditions where the
account DB is blown away but the Email app is not running, so we
don't get any notification of a change; We have to try and
sort this out early.
* SyncManager is started by Welcome, so this catches many cases of
entering the email app.
Bug: 2567986
Change-Id: I76bea5b636802ba5c1677d8b1825fb3c61f7b2d9
* When account disappears (e.g. delete from Accounts & Sync) the Welcome
activity should launch with FLAG_ACTIVITY_CLEAR_TOP to remove any
stacked activities as well.
* When account disappears entering AccountSetupNames, don't fall out
of Eas Flow Mode.
* Followup to 5e354cd1db
Bug: 2563998
Change-Id: Ifbe086e26205bb28c2514f84cb28e839888b1eb0
The error handling for (mAccount == null) would crash. Use a simpler
path here and just abandon the setup process.
The root cause of this (the account being null) is probably solved
by 3ae84b247d, but still a good idea to
clean this up.
Bug: 2558344
Change-Id: I3167234f99e9d39844f2b56a4d94f25465c7c269
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
