At any time, it's possible for the framework to recycle views. Normally it's
not an issue, however, during drag-n-drop a view with "unavailable drop
target" foreground colour may be reused. We need to ensure that the foreground
color is always set.
bug 3398330
Change-Id: I21acd04584a122c19219f3abb6690bb231bad3a6
* 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
Intent-filter's mime-type matching is case-sensitive. We should always use
lowercase letters.
Bug 3375709
Change-Id: Idd4abb41f94c816a5b9150aef5859dd75487a042
The "?limit=" param is only supported by EmailProvider, so don't add
it to other URIs.
Doing so causes a permission error when opening an EML attachment on gmail,
because we're granted the permission only to the passed URI, but not to
the URI with the "?limit=" param.
Bug 3371630
Change-Id: I88fff88a7e48e5bc958124eedec3e592978a40c7
Use a sub-selection to limit the messages from the inbox. Also add a unit
test to ensure the selections are working correctly.
bug 3368613
Change-Id: Ia24ef6028ded27c69f982ecbc6b67f35f84d1b6d
* In AccountSetupNames:
* Add "Field required" error tag to Names display
* In AccountSettings:
* Improve IME behavior in text fields - auto-capitalization
* Prevent empty username
* Reset empty nickname back to default (email address)
* Fix broken hint for signature
* Proper trimming in all fields
Bug: 3338435
Change-Id: I2720c4524303ada6dd228866756fc9c3aac173f3
* Initial account setup screen, password entry field
* When passing the entered password from incoming->outgoing
* When restoring store URI's from HostAuth
This will satisfy the users who insist on leading/trailing spaces
in their IMAP or EAS password. Not supported by POP3 (no quoting).
Bug: 2981433
Change-Id: I16c00bf96382899abb54cb75fcd44cf0f140a660
Current specification calls for the following:
* Droppable targets: do nothing
* Not droppable targets: grey text (hex #999999)
* Hover over droppable: use label/folder list pressed state
* Hover over not droppable: do nothing
* Destructive targets: background (hex #f10000)
We need to copy the resource from the framework as there is no supported way to
fetch the pressed state drawable during runtime. Adam filed bug 3370043 so we
can specify a drag target state directly in the selector.
bug 3154986
Change-Id: Ifd5c24a3dc46b5a1c64a149904657dda297ed047
* Allow, but provide warnings via EditText.setError()
* Remove one last instance of password trim()
Bug: 2981433
Change-Id: I406a4f8b8f27cc5ce90424a8cafe88a677e72f45
Signed-off-by: Andy Stadler <stadler@google.com>
When launching Welcome and MessageListXL, make sure they start
as a "main" activity. This fixes the reported bug.
Bug 3366537
Change-Id: I68facd739bd1dad8eeec52015b0720299d632e11
* Determine load state and allowability of view/save in constructor
* Extend AttachmentInfo in MessageViewFragmentBase to include views,
buttons, etc. and to add extra requirements for view/save as
needed (e.g. availabilty of external storage)
Change-Id: I2ce2b4e71fd784ef0329e391cc0e2d1639f8273c
- Now tapping these To/Cc/Bcc/Subject labels moves the focus to
the corresponding edittext.
- Tapping the bottom part of the screen moves the focus to the
main EditText.
- Also use paddings instead of margins for the main EditText, to
expand the hitarea.
Bug 3366831
Bug 3367100
Change-Id: I9b5d18dcc9d7802bfcbd0160befcb008c784d9f7
* This fixes the case of:
* a device that does *not* support device encryption
* connecting to an account that *does* require device encryption
* but also supports "non-provisioned devices" (making the encryption
requirement optional.)
* Added unit test
Bug: 3367191
Change-Id: I894e68c4119a102dad02d2e0815fccdae1e87189
instead of showing all messages (e.g. messages in drafts, etc...) the "combined
inbox" view now only messages in the inbox folder. This is now identical to
the "combined inbox" view available in the full email UI.
bug 3368613
Change-Id: I0080b56cd2718a3dce82b279277c63c4f43e86dc
* Modified font colours for read/un-read emails
* Add chip colours when viewing mail from multiple accounts
* Add calendar icon if message has an invite attachment
* Update background of read/un-read emails
bug 3351761
Change-Id: Id59573d25a6988e9e869335f95778aad28b43912
After saving an attachment, we no longer automatically start the activity
associated with the attachment mime type. However, we still run the media
scanner to add supported media (e.g. music, pictures, etc...) to the media
content provider.
bug 3266378
Change-Id: I96985438316a33322437ff009fe7e9c597b1c70a
* Use getStorageEncryptionStatus() to check device status
* Also, check granted policy on USES_ENCRYPTED_STORAGE
Bug: 3346641
Change-Id: I9e9a45a6d1d3cf4714e27b69cdb5952c841c640d
We don't need to allow users to install applications directly from the email
client. Instead, application installation is a two step process; the user
must first save the APK and then find it on the filesystem.
If the user does not want to allow installation of applications from unknown
sources, we don't provide the ability to save.
NOTE: After saving, we still try to open the APK which generates an error
toast. We will be removing the auto-open-after-save feature in a separate CL.
bug 3351137
Change-Id: I0eb1bc8224a154792fe852757e4b23a3059f4392
When navigating away from a preferences screen and unsaved settings would be
lost, display a confirmation dialog. The user can either accept or cancel the
action. If canceling, the user is returned to the settings screen they were
currently on. Otherwise, they are taken to a new fragment (the exact
destination depends upon whether the user navigated "back" or selected another
header)
There is one additional change that needs to be made. In the case of navigating
to another header, we are notified _after_ the new header is selected. In this
scenario, the action is not cancelable and the user will lose any changes. We
must display an appropriate message when this happens. [note: this is the same
behaviour as when the user selects a breadcrumb]
bug 3327737
Change-Id: I4bd3b393a6323f3e63510e3ed08e4e1e745b04c4
* Confirmed that policies enforcing encryption are rejected as
unsupported (since full encryption plumbing is not in place)
Bug: 334652
Change-Id: I82340cfbd68a9663714a98824a5d8395f2c0da74
Also show the *total* starred message count (excluding trashed starred)
in the mailbox list, not *per-account* starred count.
Bug 3346872
Bug 2149412
Change-Id: I2274f215f994b62280ac6138982b927cec22c677
Add null check for all mMessageContentView accesses.
Also, addressed Andy's comment on I1374b81f; moved the zoom scale array out
of Preferences.
Bug 3350164
Change-Id: I689bd4146ecfffdbb98dccd433ba0c396996df4c
* Add encrypted-storage to uses-policies
* Add new field to PolicySet
* Add "false" to all constructor callers
* Add unit tests (including fixing some existing unit tests)
* Add new logic to AccountSecurity activity t0 dispatch both password
and encryption requests.
Bug: 3346641
Change-Id: I54f39bc9b6fbe21c033a05b36b83081e5c78a296
It's exactly the same as Marc's I1240f263, except how it sets the zoom scale.
Seems like WebView.setInitialScale() works...
Bug: 3215606
Change-Id: I1374b81fd7799faa261ba6a06df18f6a8ef9d122
* Switch to newer startPreferenceActivity API
* Newer API lets us pass a string for the breadcrumb
* Get rid of newInstance() calls in all three server settings fragments
Bug: 3188951
Change-Id: I86ae91d63ff7bd32fa0eab96ac18686bb5e3e313
* Clear the fetch request list
* Also, make sure we don't try to send local changes during an
initial sync
Bug: 3347078
Change-Id: Idba7bceb5919bea81bf5b48a69cd4331946505fe
If none of the installed activities can handle the attachment type, don't let
the user view or save the attachment to the device.
bug 3338984
Change-Id: I6c158b7dd11ec48eec81f9a96289dd2c914f6a2c
Andy Stadler