* CalendarProvider2 has unusual semantics for its delete operation on
Calendars; this caused the user's calendar NOT to be deleted when
the server commanded a wipe of calendar data. The result was
duplication of events after the subsequent resync
Bug: 3361000
Change-Id: I672034a7a444eb7ebdea60cd6dc66a31087cc6f7
* 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
action_bar_current_mailbox: We'll ship with the current design.
colors.xml: Obsolete STOPSHIP.
Bug 3335095
Change-Id: Ic45ef3d0cafb55761b720e1e74c0633012f87e98
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
