* Add "Accept all certificates" modes to incoming/outgoing secure choices
* Change URI scheme slightly to make "trust" a flag, not part of the
protocol.
* Change Stores to know about new URI scheme
* Slightly rework Transport API to make "trust" an independent flag
* Adapt HostAuth to handle new Uri scheme
* Remove the old ambiguous "optional" code, which was allowing
some unsigned certificates, but was *also* allowing TLS to
optionally start (though not SSL, despite the UI strings.)
* Add a few unit tests to EmailContent
* Add logging and a bunch of comments to TrustManagerFactory, and a bit
of simple cleanup to make it more readable.
* Add missing conversion of SSLException->CertificateValidationException
in TLS so we get the correct certificate errors from TLS too.
* Re-enable TLS for mac.com accounts (which had a certificate problem)
Fixes bug http://b/2119755, http://b/1374780, and probably a raft of
earlier and/or external bugs about certificate problems.
Change-Id: Iaf99a8da3eaadaa4cdeec224737838b5d6813e55
* Remove SSL-Optional and TLS-Optional choices from UI
* Remove SSL-Optional and TLS-Optional choices from providers.xml
* Switch over most SMTP connections from 25 to 587
* Clean up the providers list which has a lot of "optional" cases
that were probably falling back to unencrypted.
Fixes bugs:
2110243 Settings UI shouldn't offer SSL/TLS (if available) options
2089070 Update list of providers
Change-Id: I57be57b349eed33a5284121d904528279a36a91c
* Use concrete declarations, not the old sample code
* Remove unused "sample" code
* Create ExchangeSender.java
* Strip out the unused (old sample code) parts of ExchangeStore.java
* Unit test to make sure EAS is being offered
* Fix "account leak" in AccountSettingsTests
This was triggered by donut bug # 2092944 but the solution is
different because we support EAS here.
* Remove all use of Strings in favor of the parser's static final int's
* Strings remain in Tags for debugging output only
* Renamed lots of classes to be more consistent
* Centralized logging behavior in Eas class
* Found and fixed some bugs in the process:
- Account deletion wasn't removing HostAuth's correctly in the trigger
- Adding a second EAS account was trashing the first one
- Fixed looping sync behavior caused by Exchange 2003 bug
* Modify to work with ContactsProvider2
* Modify to work with system AccountManager
* Modify to work with system SyncManager (for triggering user-change syncs)
* Sync server->client for adds/deletes implemented (CP2 doesn't handle delete yet)
* Sync server->client changes handled efficiently (only write changes)
* Some fields still not handled
* Rewrote most of the CPO code to handle server->client changes
* Sync client->server works for supported fields
* Renamed ISyncManager/ISyncManagerCallback to IEmailService/IEmailServiceCallback
* Restored ExchangeTransportExample to its original state; created ExchangeStore to
handle validation functionality instead; updated stores.xml to reflect these changes.
* Add support for AccountManager in EAS code (this is necessary for the contacts and
calendar providers to work with syncable data); created EasAuthenticatorService to
as our authenticator, which required adding authenticator.xml and modifying the
manifest to register our service with AccountManager metadata
* Created EmailServiceProxy as a convenience for the UI in calling into the EAS
service; created EmailServiceStatus class for status codes in callbacks.
This reverts commit f6ab8aaec8.
Revert because TMO IPs are rejecteb by Cox SMPT server for
spam reasons (spamhouse filtering).
Revert while waiting for a solution to be found by TMO/Cox.
(e.g. EAS) can limit itself to n (usually 1) accounts per device.
The UI for this is really simple - don't show the EAS button when the
limit is reached. More work would be required in
AccountSetupAccountType.java in order to do a more sophisticated UI
(e.g. show the button but pop a toast if the limit is reached.)
BUG=1740626
Automated import of CL 148019
The default values are 25 (default) and 25 (increment). This is fine
for Stores that control downloads by # of messages, but won't work for
stores that use other measurements - e.g. EAS windows the download in #
of days. So for this change:
1. Allow the StoreInfo to provide non-default values
2. Remove the hardcoded references to the default values
3. Use StoreInfo values everywhere
4. Set the values to 1,1 in EAS store info
BUG=1789913
Automated import of CL 146331
1. Generalize the code for the various spinners that control
account check frequency.
2. Provide an API for looking up store attributes (and refactor
existing instatiateStore logic to use it).
3. Cleanup the old code that was used to setup frequency spinners.
4. Hardwire Exchange accounts to default into push mode.
Notes to tester:
1. For each account type (POP, IMAP, EAS) we need to check that
auto & manual creation "do the right thing" for frequencies.
POP & IMAP should offer "none" or time intervals, while EAS
should offer "push", "none", or time intervals.
2. EAS accounts should default to "push", all others to "15 min"
3. Make sure that you can edit existing account settings and see
the right choices (only EAS should be offered push).
4. I couldn't write an automated test for the mail checker service,
please confirm that POP & IMAP accounts are checked at the right
intervals (or never, if set for "none".)
BUG=1776149
Automated import of CL 144953
the shipping client will include the necessary generic pieces for
configuring an Exchange client (e.g. account setup) but will not
include actual Exchange client code (e.g. transport / protocol).
Also added a "sample code" implementation of Exchange for use
as a starting point for implementors. (Note, this will not ship
in Donut, it's a placeholder for working on the "framework"
aspects.)
BUG=1740621,1740626
Automated import of CL 144525
