The format string "The server %s requires that you allow it to remotely
control some security features of your phone." was being displayed with
the account name instead of the server name.
Bug: 3011124
Change-Id: I1aadb5790297777831dd69f04ea89641240b7b87
* Makes the side-scrollable again
* Required after making them non-long-clickable
Requires companion change in WebView, to allow touch events while
clickable or long clickable (it had been requiring both)
Bug: 3036477
Change-Id: I4cae46d047f825d2aab08d254287855b187e9207
* Check array returned by split("=")
* Add unit tests for this case
* Also add unit tests for quoting removal
Bug: 3040796
Backport from: I170f3cd483fe35186194edeb0c3142fb0e2e9b75
Change-Id: I32ccbdbc7264a95a9cd279218cae390e65e82eeb
* The meaning of a busy status of "Busy" is uncertain; it could mean
"Accepted" or "Tentative", depending on whether the event was
created via OWA/Outlook or EAS
* We have interpreted it as "Accepted", which prevents the user from
actually accepting the event (as a state change is required for us
to send updates to the server/organizer)
* This CL changes the behavior such that a newly arriving event with
a "Busy" status is shown as "No response" in the Calendar, thereby
allowing the user to pick from any of the three possible options.
Bug: 2811859
Change-Id: I321f714e54e66ee8f40f5e2c00587b98bad71a63
* This gets very confused by the new text copy logic
* Downside is that copy from received message does not work at all
(it didn't work anyway).
* Will fix in next release by redesigning MessageView layout and no
longer wrapping in ScrollView
Bug: 2998892
Change-Id: Icd1219f3c45fd4da9259499e9c8a31ed0d3c4c30
- Merged all three BroadcastReceivers into one.
(Changed class name because old ones may have been disabled.)
- Use IntentService to perform the tasks in a worker thread.
Note the new receiver will never be disabled. We always need to start
exchange.SyncManager.
Bug 2722155
Bug 2416929
Backport of I8241880fc1ee38d85dcdca7e1d46fc2f6b2d375b
Change-Id: I9835cf86846d842e6f2d23014bc0912c3b888a05
* We need to include the intro text (--Original Message--, etc.) to
SmartForwards, and somehow this got in a past updat
* Add unit test for forwarding
* Fix unit test for reply so that it works localized
Backport of I8d92f00d37a434840ec3eb237f3901cd5dc7ad09
Bug: 2477988
Bug: 2685784
Change-Id: I2b6654413a8eb5ca900f958f49ec9eee5161a365
* Add this to processSourceMessage in the reply/forward cases
* Add unit tests for reply and forward case
Backport of I6be8383fe5f217a4bda8e669cb69f439bc8e96b6
Bug: 2734321
Change-Id: Ia59e8c4e2f9663f2a10cff066eddeff80bc06cef
- mConnection.destroyResponses() should be protected with
if (mConnection != null).
When we get an IOException, we close the connection and null it out in
ioExceptionHandler(). So mConnection can be null at any point after
where ioExceptionHandler() first appears.
- ioExceptionHandler should close its parent ImapFolder only if the argument
connection is mConnection.
Methods like exists() may pass an ImapConnection which is not mConnection
to ioExceptionHandler. In which case we don't have to close the ImapFolder.
Bug 2898211
Backport of I8f9f45d91f596bb8da1a1575593e652d66deb643
Change-Id: I070458b5535540aba69ad7eee88bd2af8ad5f7b1
Apparently IMAP servers may return multiple SEARCH responses for a
single SEARCH command, and we need to handle all of them.
Before the IMAP rework there was 3 methods that issued the SEARCH command.
Two of them ware doing it right, but the other wasn't, which was what
I copied from, unfortunately!
In case you're wondering, originally the test for this method was done through
upper methods, e.g. getMessage().
Bug 2911647
Backport of Ia50072944d5b01c1e59541c3a966067b13910cc4
Change-Id: Iab5d3fa21e403f2e1043990112154fbb72322b02
One thing that bothers me regarding the new ImapStore is that there is no
tests to verify if the way how getImapId() uses a vendor policy hasn't changed.
This part is hard to test with a real vendor policy, and it can easily be
overlooked even if it's broken.
This CL offers ImapStoreUnitTests a way to test the interaction between
getImapId() and a vendor policy.
Also fixed a bug in VendorPolicyLoaderTest where it assumed the test apk
package name is "com.android.email.tests", but it may actually be
"com.google.android.email.tests" now. (Broken since the test makefile
used inherit-package.)
Backport of I8feb616ea28cb5cae5b4fba57e363771014ac599
Change-Id: I59536bc9a0e5c09c23eab21cdfb2f8283ef01a42
- This is to make sure we're not touching any ImapResponse that's
already been destroyed.
- I didn't add "is it already destroyed?" check to them
(except for ImapTempFileLiteral), because it can be costly.
Just let NPE be thrown.
Backport of Idc7b88c4844727922841cbad8a106bf781181d45
Change-Id: I9932e78a49784e4218e939a12ebcb9a497c4eb57
Unfortunately it's hard to write tests for this change, but at least
all tests pass with Idc7b88c4.
Backport of If0335a848dfcc23aecea22c21b2cce73dac7ff6f
Change-Id: I6cb3525bc3c67bbf2fb101488bf95edbead5d299
