We were hiding the search icon from the actionbar but didn't take into
account the use of a hardware button.
Bug: 5051691
Change-Id: I2e0bfd1d0bb4faa3238e567c02189894db5f6c44
On second thought, it's probably best to stick with the same account if
I can't find a particular folder. This at least is less jarring if the
user has multiple accounts.
Change-Id: Ifd5d631b220e260399681008ac17203f5451c8ff
- ensure that the commitAllowingStateLoss is actually not dangerous - we
only had one case I could see where we were actually doing a transaction
from a loader callback and I fixed that just now to not do any
transactions.
Change-Id: I21e11138f70eb2ce953a5ba54119ca46555f465d
* This CL fixes the referenced bug, but it does NOT explain how
mAccount; best guess is that the process was killed and then
restarted when the result from DPM was available.
* Assuming this is the case, we remove the background task loading
mAccount, avoiding a possible race.
* Also, it's not clear why clearNotifications didn't use the
account id argument; what if there's more than one account that
uses security? Filing a bug about this.
Bug: 5048912
Change-Id: I734834337ab6e409d77624e7c7370350de76becb
* Move AccountReconciler to the Email app (from EmailCommon)
* Ensure that Controller.deleteAccountSync() performs ALL actions
needed to clean up after an account deletion (delete attachment
files, reset policies, refresh the UI, etc.)
* Add reconcileAccounts() API to AccountService
* Remove accountDeleted() and restoreAccountsIfNeede() from the
AccountService API
* Remove unused callback
Bug: 4883073
Bug: 4767084
Change-Id: I43ffaf009db1a6f306bb0f2a74fb4dd3b2c4b966
* Not sure how this could have happened, except possibly for some
race condition
* Let's make sure it's impossible
Bug: 5032454
Change-Id: Ibd4de22dc5298fbaaf224cf4286f63bdc50aa7b9
- include settings in menu in message view
- remove "show all mailboxes" from message view
- rename "Account Settings" to "Settings"
Bug: 5039294
Change-Id: Ic2dcbe8fe6e2bd10cc5d790a74c49a7159b59cab
* This prevents the possibility of RejectedExecutionException when
selecting large numbers of items
Change-Id: I8f9ba287d69021fdb99b4a8a30cc79755f669b97
- since listContext can be null, this code was not safe.
we also filter out the search mailbox too, so it's no longer needed.
- don't ask to highlight a mailbox if doing a search
- remove a call in MailboxListFragment that was unconditionally telling
callbacks that something was selected when we started loading - this was
technically lying and if the item isn't in the list that was selected,
nothing should be called (as in the case of search). This was just an
optimization anyways and that callback is invoked later when the mailbox
list load completes.
Bug: 5037629
Change-Id: Id31c6795af9e64fa8682b67de9ab90540ee660df
Note: all unicode sending unit tests are broken due to chip issues. I've
filed a separate bug on that.
Bug: 5012204
Change-Id: I17392f65e5bd8349780b79d9cbe10492d8e7a7d9
* We waited to clear the incomplete flag until security was agreed
to, but this can lead to accounts left incomplete; we now clear
the flag as soon as the AccountManager account is created (by
convention, this is when the EmailProvider account is complete)
* Also, allow onDone() to be called more than once with a saved
account, leaving cleanly, rather than throwing a runtime
exception
Bug: 5016792
Change-Id: Ib5fc44ac045a1dd9bd5d63f922c037ed637d5341
