* 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
* When the sync state of Calendar/Contacts is changed, a number of observer calls
are triggered. In addition, we might have a running sync.
* The syncKey operations need to be synchronized, because we may otherwise
inadvertently use stale data when syncing, which would cause symptoms
as seen in the referenced bug
Bug: 2561864
Change-Id: I03db58fe01c45778d271fad34d8d4940edefe8fe
* resetVisibleLimits can be called via BootReceiver, which isn't in the
Email app process, so it can (and apparently did) get a RemoteException
* This causes the query to return null; we have to check for it or we
get this NPE
Bug: 2564904
Change-Id: I4b75e3c74ac7d1276f609f2fc957afdaa8da2f64
* Turns out that most other clients omit this.
* This has the pleasing effect of fixing the referenced bug
* Update unit tests
Bug: 2561821
Change-Id: I39f7db7e05be590373cd5f3d9b23c7ee21bde4f7
* We were queueing up emails during our upsync, but before the upsync
was complete. If there were connection issues, we could pile up
multiple copies of the same message, each of which would eventually
get sent out
* Fix is to simply queue up the outgoing mail and send it all after
the sync operation is complete.
Bug: 2515975
Change-Id: Ide3eb2deb6e959d0637d28efabd613efb3c6e209
* Because we were sending these in the wrong format, upsynced changes
were failing, with the result that both the original event and
the "new" event (from the UNTIL date forward) remained in the calendar
* Fix is to send the proper format; unit test updated to reflect the
change
* Also, we only send the date of an UNTIL, rather than the to-the-minute
time; it turns out that EAS expects to see only a day for UNTIL.
Bug: 2561818
Change-Id: Ic4eacbe96c713d58c637386ceab2cf22ebe3c2d4
* We need to send date only (without time) in the VCALENDAR file for
all-day events
* Add unit test for this case
Bug: 2561789
Change-Id: I33a43c7a248059c97482ca147a23af083744118a
* Always send up something when upsyncing photo and note
fields
* This allows the client to delete the data, as these fields
are NOT deleted if skipped in an upsync (unlike other
fields)
Bug: 2558998
Change-Id: I9c874432108eedd84a351918f818c32e6e579dd7
* We should be sending CANCEL as the method with cancellations
* Fix this and update unit test
Bug: 2527606
Change-Id: I2b982e4bfd1dbc57660cf578702edf49584d2957
* We now check that the user has verbose debug logging on
before spamming with serializer logging
Bug: 2561834
Change-Id: I5eda2ca5f16cde728b0febaa990d66fc99bb93a0
* Now that observer code has been moved to worker threads, the order
in which various pieces of account creation are executed has become
indeterminate
* Because of this, our EasAccountsUpdatedListener could use a stale
list of EmailProvider accounts when performing reconciliation with
the AccountManager's list of accounts
* The fix is to ensure that EasAccountsUpdatedListener's worker thread
causes the cached EmailProvider account list to be updated before
calling the reconciliation method
Bug: 2558317
Change-Id: Ia94a8301845cf6c06f8efecd408eb237474f781a
- make EntityIterator extend Iterator and thus not throw a
RemoteException, instead converting it into a RuntimeException.
- rename ActiveSyncInfo to SyncInfo
- change getActiveSync to getCurrentSync
- remove the accessors in SyncInfo and instead make the final
fields publicly accessible
Change-Id: Id1a47bba27042de4c21451a91cc43fa70eb68ec6
http://b/issue?id=2553539http://b/issue?id=2553541
* Clean up some code related to connectivity locks and sync holds
* Add logging related to sync holds after we re-establish connectivity
Bug: 2551482
Change-Id: I1b1f03cc1428e25be90c5e60555adf9ab1bf3ab9
* Had to add an optional argument to the email creator for this case,
since there may not be any remaining addressees to send to (if the
only guest was uninvited)
* The optional argument forces the creation of a message, even if there
are no addressees
Bug: 2548465
Change-Id: I88784f49ce7afedce331fc756c5ecef4e73a07bc
* We were starting a sync if there was a dirty event in ANY of
our Exchange accounts
* Change to check for the specific account before syncing; this
saves provider queries and service (i.e. thread) startups
Bug: 2550620
Change-Id: I83e953f1bade9fa269b777e96121a63664e8edc8
* There's an NPE if we downsync a contact containing a piece of
typed data for which there is no type specified in the database
* Check for this and accept "no type" as a match
Bug: 2539843
Change-Id: I155b635a1f9850af9813681f502f3565c3cfcd4b
* The recent change that moves our account change handling out of the
UI thread caused ConcurrentModificationException's during account
creation
* We now synchronize all access to our cached account list to prevent
this
Bug: 2546724
Change-Id: I92b2becedd36a335a81f7e3bd9617f2923e00e6c
* Prior fix used the wrong column when adding time zone information
to downloaded exceptions
Bug: 2548436
Change-Id: Idc1001fd58d2fba51823624a15862fe439c9ff6a
* We weren't checking calendar id along with original event id when
uploading (original event id isn't unique)
* Fix the query selection to ensure finding the correct exception(s)
Bug: 2545659
Change-Id: I276dd10e2be171bd9d4f3300cdc8843bb28f2781
A desktop shortcut to an account created on donut or before points at
com.android.email/.activity.FolderMessageList, which we've already removed.
- Added a dummy FolderMessageList to receive it and redirect to MessageList.
- Removed FolderMessageListUnitTests, which was left unremoved.
Bug 2535335
Change-Id: Ie5ffa158882633a4929c4c47a3d9625fd1626863
* Use one minute before/after for transition checking, instead of the
sloppier early version
* Add tests for additional known time zones
* Change most methods in CalendarUtilities to package private (for use
with unit tests)
* Clean up a little bad formatting
Change-Id: I9e5be5e1c859f2294adf06874459f7db15fb8c22
