* This is is a minimal implementation that only supports the external
encryption policy when there is no physical/removable storage, and
the emulated external storage is located within an encrypted backing
store.
Bug: 3351426
Change-Id: Id96e9277f810beeebf816a914acd3d733eb713ea
If the account supports smart-forward. The old code assumed
attachments are not removable if the account supports smart-forward,
which is not true. Locally-added attachments should still be removable.
Bug 3505684
Change-Id: Ie6703551800c617dd224957a098311f0c279b3f1
The problem was:
- MessageFileViewFragment.clearContent (A) is called in onDestroy
- MessageFileViewFragment.openMessageSync (B) is called in a bg thread
to load an eml file
- And both try to hold the same lock. (mLock)
- If EML is large enough, B takes _seconds_. If you press back during this,
onDestroy gets blocked trying to lock mLock.
- This could also cause a crash, because the task that runs openMessageSync
won't get cancelled in this case, because that's done in clearContent.
Because of this, the task's onPostExecute tries to touch a UI element
when the fragment is actually being destroyed.
The lock was introduced to protect mFileEmailUri, only to keep the same
semantics for openMessage() as MessageViewFragment. i.e. openMessage can be
called multiple times for the same instance of the fragment.
However, in practice, this won't happen. Unlike the regular message view,
we never reuse MessageFileViewFragment. MessageFileViewFragment instances
are created per message. This lock was just reminiscence from the early
developmen stage.
So, fix is simple -- just remove the lock.
Bug 3500487
Change-Id: If2b22a683666de535454bb1293563796fa7acfd7
For now it only enables it for the main process. I've added a flag
to EmailServiceProxy for EAS, but it's not used in the exchange side.
Bug 3500292
Change-Id: I5b27c69fe7cc995a430e9def54b2463076032c78
Slight API change to make it more clear what the method parameter is for.
Also add some additonal test conditions to the Rfc822Output tests.
Reapply changes in CL https://android-git.corp.google.com/g/#change,99090
Change-Id: I7a48c9544e48cbdf44b14f4b1f8d92fe01f7861e
* When a connectivity wait was added to processQueue, I neglected
to consider that a lock was held during this time
* The fix is to move the check for connectivity out of processQueue
Bug: 3500702
Change-Id: I646cf899ff895d9838612e89b15b66f1084840b1
Slight API change to make it more clear what the method parameter is for.
Also add some additonal test conditions to the Rfc822Output tests.
Change-Id: I8888d6201e79136fa3420aa9d5f921772f374e56
On multitouch devices, the zoom icons are not needed (the user can pinch to
zoom in/out). So, we should disable the display of these icons on multitouch
devices.
bug 3405875
Change-Id: I45484cfc622f11c25d3ea7f4c378c3133d7f7de0
There were two TODO's from a prior CL where deprecated HostAuth methods
were removed.
1. Do not use a generated URI to determine if account settings have changed.
Instead, use the HostAuth structure for this purpose.
2. The account key in the HostAuth structure has been deprecated. Remove as
much of it as possible (until the schema of the host auth database changes,
we must still refer to it when adding rows).
In the process, HostAuth tests were broken out into a separate unit test
file.
Change-Id: I4075da09af168f734db7b20a9ef63d4178ac2064
* In the case where there are no Exchange accounts, we can stop ExchangeService
while restoreAccountsIfNeeded is still running, which can cause us to leak
the connection
* Change the call to be synchronous.
Bug: 3495601
Change-Id: I4a396e8b1650bd15fabd2802d2ec8d4276c6e43a
This happens when
- two accounts are configured
- select account 1
- remove account 1, and account 2 becomes active
In this case we failed to select account 2, and the fragments would keep
thinking account 1 was active. (So no mailboxes would be shown--beacuse there
was of course no mailboxes for account 1!)
When the account list changes, the account loader (created in loadAccounts())
automatically reloads the account list, and calls updateAccountList(). If
there're still more than 1 account at this point, updateAccountList() updates
the account spinner on the action bar. This will result in
ActionBarNavigationCallback getting called, which then updates the current
account as expected.
However, if there's only one account left, we hide the spinner and just
set the account name to the action bar title, so
ActionBarNavigationCallback won't get called and the current account
never changes.
In this case we shouldn't rely on ActionBarNavigationCallback but have to
explicitly update the current account.
Bug 3491567
Change-Id: Ia9ba3e1c11248ad5a1ba7e055717c5519d6e4884
Original CL comment:
Always set a delete policy for legacy accounts
The delete policy can only be set for POP3 accounts. However, the delete
policy is used for all legacy accounts (that includes IMAP). As such, we
need to make sure IMAP accounts also have their policy set; even though
the setting is not configurable by the user.
The delete policy does not mean anything for Exchange accounts, so, we do
not need to modify the account setup code for them.
bug 3074164
Original Change-Id: Iab10d2997404b3b0c10a60a64fb652540c0d2d1a
Change-Id: Idc290aa1b8ff4f17a0c8fd57333523becef0c8e5
Removed the ugly doAutoRefresh() and byExplicitUserAction.
The intention for these was to supress auto-refresh when the message list
opens without any explicit user action, e.g. due to screen rotation.
However, now that we have the RefreshManager.isMailboxStale check with 5
minutes duration, this check is not really necessary. Let's just always
refresh mailbox if it's stale.
Bug 3493134
Change-Id: I6d0365ed7f8092304117d5f619d570b828edf76f
