Merge commit 'de3ae17246bc011eff61e18ee1013e146ec53a3d' into froyo-plus-aosp
* commit 'de3ae17246bc011eff61e18ee1013e146ec53a3d':
Add additional test for likely NAT timeout
* 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
Merge commit '1880ad6a83120b89ed239858d27d3e63242160e6' into froyo-plus-aosp
* commit '1880ad6a83120b89ed239858d27d3e63242160e6':
Send correct busy status information in upsyncs to EAS
* 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
Merge commit 'bb11c91175a4beee207324d67b913b91a41bbea7' into froyo-plus-aosp
* commit 'bb11c91175a4beee207324d67b913b91a41bbea7':
Fix NPE sending mail on servers without Outbox folders
* 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
Merge commit 'a90bb03c259a9cf2e1ca15ef90b00759cd555987' into froyo-plus-aosp
* commit 'a90bb03c259a9cf2e1ca15ef90b00759cd555987':
Use METHOD_ALERT instead of METHOD_DEFAULT for reminders
Merge commit '17e8ba7eda1cabf72ac650408abd94f1145397e9' into froyo-plus-aosp
* commit '17e8ba7eda1cabf72ac650408abd94f1145397e9':
Speed up provision notification after security failure
* 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
Merge commit 'a8f7b3e16e97ef8e6d9fb47ae9359f2db5676c94' into froyo-plus-aosp
* commit 'a8f7b3e16e97ef8e6d9fb47ae9359f2db5676c94':
Store all day events w/ UTC timezone
* 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
Merge commit '095eee41565900a2509256ffcbf6cd67a4c4e345' into froyo-plus-aosp
* commit '095eee41565900a2509256ffcbf6cd67a4c4e345':
Set selfAttendeeStatus and busyStatus properly on downsync/upsync
* 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
Merge commit 'a97d85014f3849fe4ab05758857eb7552caaa856' into froyo-plus-aosp
* commit 'a97d85014f3849fe4ab05758857eb7552caaa856':
Properly decode a uid from the globalObjId in invites
* 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
Merge commit '186aa619dca002790c38b4dd8649bfe2b3a96f6e' into froyo-plus-aosp
* commit '186aa619dca002790c38b4dd8649bfe2b3a96f6e':
Cleanup probable causes of close cursor access
* 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
Merge commit '3b3b5b0f2b65bf7efb9474ece2d8d2821beeadc2' into froyo-plus-aosp
* commit '3b3b5b0f2b65bf7efb9474ece2d8d2821beeadc2':
Run the account reconciler every time we start SyncManager
Merge commit 'd2a0d23380a2751d82f9d1f955a812f94a301e2a' into froyo-plus-aosp
* commit 'd2a0d23380a2751d82f9d1f955a812f94a301e2a':
Use consistent device-id even the device is wiped.
* 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
