* After deleting an account, we need to actually update
the list of known accounts - it's not sufficient to simply
rebuild the headers with one account marked deleted.
* Also remove a couple of obsolete TODO's
Bug: 3382965
Change-Id: I1aa6d88f869f0192b564b538817381efdc5fffe0
* Add check for null Account, as this method can be called from a
background thread, and the Account might have been deleted by the
time we're called
Bug: 3396365
Change-Id: Ie125ed714c73d51beaedc818b6b731cea941666f
If there are no email accounts defined, the widget should show a single string
that allows the user to create a new account. Whenever there are changes to
the defined accounts, the widget(s) will update their headers to ensure they
are only displaying valid information.
bug 3296594
Change-Id: I156c20cfc90692174297a2aededd85775e0ea196
The problem was that CombinedMailboxesLoader used the cursor returned by
super.loadInBackground() (which contains accounts), to build a matrix
cursor (which contains special mailboxes and accounts and will be returned),
and *it closed the first cursor* after building the matrix cursor.
However, because this first cursor is the one that CursorLoader sets an
observer, it shouldn't be closed until the returned matix cursor closes.
In other words the two cursors should have the same lifecycle.
Fixed it by using ClosingMatrixCursor that used by AccountsLoader, which
is doing a similar thing, but properly.
Bug 3387730
Change-Id: I554ade001dc25afa869eefb4dcf9887495e6753e
* Rework the interaction with the Account Manager
* Remove unneeded call to response.onRequestContinued()
* Store response in SetupData so it can survive the entire account
setup flow.
* Explicitly report exit status to acct mgr at known exit points:
* AccountSetupBasics.finish() (fail/cancel)
* AccountSetupOptions.finish() (fail/cancel)
* AccountSetupOptions.optionsComplete() (success)
Bug: 3335128
Change-Id: Ia55724eb1e938f2633c5ff7afb719a879be16a1b
For now just show the account name in parens. I'll ask the design
team for a better layout.
(I don't want to change code too much at this point, so didn't add a
new view for the account name.)
Bug 3366546
Change-Id: I3a5314be4bdfacc2720093511eb03571e91fa963
If the server reports an attachment's mime type as either text/plain or
application/octet-stream, we will try to infer the real mime type using
the attachment's extension. If one cannot be found, we either synthesize
it (if original mime type is application-octet-stream), or, we use the
server specified mime type (if the original is text/plain).
bug 3379416
Change-Id: I331e767ed36e4e17756025cc816bdb7b5a8f0868
The various selection strings were missing a test to only show messages that
have been loaded. This is only important for POP3 accounts.
bug 3377041
Change-Id: I3efe366d09dd547878dc0bf57dff58f76de5cca9
While fixing bug 2981433 in Gingerbread, I discovered one additional
place where passwords were being trimmed. This brings the fix forward
into honeycomb, as well as a new unit test for the fix.
Bug: 2981433
Change-Id: I566f5c0c6693ca7c0069bca9e74f320fca48e600
When creating the list of attachments to be automatically downloaded in the
background, exclude any attachments that are not in an inbox. Also added unit
tests to ensure the query URIs behave as expected.
NOTE: This is a partial fix for general background attachment downloading issues
bug 3373982
Change-Id: I13ef56cd280c028fa966ab9e655acce28b0b9b91
* Add multiline flag to preference xml
* Also, remove display of actual signature in summary, as it
does not properly handle long or multiline signatures.
Bug: 3379235
Change-Id: I84894dbdccee2cd8a8ece05d0b8f7fdcf7b92406
* Bug to fix was that it was looping if the user canceled
password or encryption setup (instead of simply re-notifying.)
* Solution was to refactor all code into a single sequence of checks,
rerun the sequence each time, and set markers to prevent looping.
* Rework needed after the changes in I54f39bc9 which added
encryption support but introduced the looping behavior.
* Removed a UI-thread DB access
Bug: 3346641
Change-Id: I0791d7a16287efecc7121b5ffa0db26ca2b05151
Do not retry downloading attachments infinitely. After some number of failures,
black list the attachment and move on. The black list is not persisted, so,
restarting the app will again try to fetch the attachments. In this way, any
transient network failures will not permanently affect the ability to download
attachments in the background
NOTE: This is a partial fix for general background attachment downloading issues
bug 3373982
Change-Id: I7f3ad9667ebebb95fbba95278b62bf40c5fce67c
* Use ConcurrentHashMap; check that this provides enough protection
for all uses
* This resolves known deadlock issues in ExchangeService
Bug: 3371039
Change-Id: Ie4ccbe7cdfe8c3d4ec7a0f789409126c8c09f8c4
When downloading attachments in the background, do not display any errors
on the display.
NOTE: This is a partial fix for general background attachment downloading issues
bug 3373982
Change-Id: I874ed902bde293303e10308f38b992b2bb15b6aa
