* Clicking outside of the dialog actually "cancels" it
* Need to shut down the checker so it doesn't keep trying to
update it or close it when done.
Bug: 3120019
Change-Id: I5faa3c78b64d2aafc472b03b8086695edaf0b3fd
Workaround for the framework issue that the app context doesn't
use the right theme.
Also removed the use of obsolete methods.
Bug 3169944
Change-Id: Ic8d3ba2edb9300df549cb902855025815021ff49
* This happens if an open fails immediately (error message in the
initial banner) followed by a checkSettings.
* The fix is to harden checkSettings to force a clean connection
every time.
Bug: 2170147
Change-Id: If7403bf517477d2b03b21d71caab511fe45e234c
* Check for existence of vibrator, hide option if appropriate
* Notifications with vibration are still OK, they are just ignored
* Minor cleanups & renaming
Bug: 2988758
Change-Id: Ia1fd259f57d33a75a54cf1016f66a1c072aba579
* This CL brings drag&drop move in line with the current document
describing its functionality in the Email app
Bug: 3135124
TODO: Assets and proper creation of the drag thumbnail based on
those assets
TODO: Review long-press behavior re: press on subject vs sender
Change-Id: I6e1ee1a1f055feb041a0338f2f5c775a88620595
- Now it's a menu command rather than a button.
- Also string changed from "Send outgoing messages".
Bug 3166218
Change-Id: I82f6188365f9f6bc5a6d40fb23d774eebe181445
* Add Ymail and RocketMail as generic yahoo-based email providers
* Add SSL to AOL & AIM
* Remove trustallcertificates from mac.com / me.com
* Minor reorganization to group shared providers together
Bug: 2508590
Change-Id: I7e80aaa587609f95c09e4395055bf515ec43e35e
Basic changes for the new UI. At this point we don't know what the new phone
UI will look like, so I didn't bother trying to preserve the old behavior on
the phone UI. The changes will affect both the phone UI and the tablet UI.
- Send, Save Draft, and Discard are now action bar commands.
- Add CC/BCC and Add Attachment are now regular buttons.
- Activity title changed to "Compose"
- Some string changes per new wireframe
Further changes (actual layout changes for the latest wireframe) should be made
only for the xlarge layout.
Change-Id: I68c9c37dfdca6736b1e35053e7f196800fcfce2e
* Drag & Drop "move to folder" preliminary implementation
* Use "drag handle" button to initiate drag
* Use the message list item itself as the drag thumbnail for
one item; "Move N messages" for multiple (not implemented)
* Disable MailboxList update during drag
* Use ListView itself as drag/drop target
Bug: 3138004
Change-Id: I9243e4f583cf91caa1b9dd04fd64d52e8b28fa30
These defaults affect manual setup only. There should be no changes
observed in automatic setup, and no changes observed in EAS setup.
* user $email instead of $user as default login
* guess "imap." or "pop3." for server name
* propagate the incoming server name to the outgoing server name, and
replace "imap.", "pop3." or "pop." with "smtp."
Also, fixed a couple of leftover places where we were trimming
passwords (and should not be, since some people insist on having
spaces in their passwords.)
Bug: 2978634
Change-Id: I9b0e345aa9550b5e1cc29aaa22109f03da61af20
- Make sure an account shortcut really opens the account by
adding the FLAG_ACTIVITY_CLEAR_TOP flag to shortcuts
* Shortcuts have to be re-created for this fix to take effect.
- Remove Welcome.createOpenCombinedInbox/OutboxIntent, which don't work
with the new combined view.
* createOpenCombinedInboxIntent() is not used already
* createOpenCombinedOutboxIntent() is used, but is not final UI, so
removing it is okay.
- Fix MessageListXL.actionOpenMailbox -- now it really uses the passed
mailbox ID.
Bug 3144066
Change-Id: I2ee3f84c62a135351c10266c7ca6d5178c3a0ca2
While monkey is active, any clicks on "send" will be mapped to "save".
Drafts will pile up, but nothing will get out.
Bug: 2799956
Change-Id: I300d50001b43c8b61062143f9a0ac914aa2deaca
* Add preference for default text size
* Move saveSettings logic into onPreferenceChange handler
* Per user tests, default setting is large (not "normal") for XL devices.
* Use setting in MessageView's WebView
TODO: Investigate zooming header (to/from/subject/etc) as well.
Bug: 2282390
Change-Id: If32ed3626244b046941a461f974b3dbdb535f592
* new checkbox in debug fragment
* saved value in prefs so it's sticky
* each Activity calls a helper to enable/disable per that flag
Change-Id: I1af1ae9f401bc746cc97da00dfb0e06407b79d46
We're getting an NPE in restoreMessageWithId(EmailContent.java:670)
called from MessageFileViewFragment.openMessageSync().
However, there're only two things that can be null in this line,
context and context.getContentResolver(), and either one really
can't be null. Add explicit null checks to investigate what's going
on.
Bug 3134403
Change-Id: I463b039b6afeda32729f7e6a93edfdb9abf12093
We need to pass the actual class loader. Passing null makes it use
the boot class loader, which can't find our classes.
Bug 3073304
Change-Id: I1c72c1d352cfc0a730aba1d83eb048a8cfa95b67
- Don't show combined mailboxes with regular mailboxes in the mailbox list.
- Add "Combined view" to the account selector instead.
- "Combined view" has all the combined mailboxes and accounts.
- Renambed these combined boxes. (e.g. "Combined inbox" -> "Inbox")
- Regular account view still has "Starred" mailbox, but it's actually
"combined" and not per-account.
- Re-order special mailboxes per latest wireframe.
Bug 3138004
Change-Id: I4c5860c6774b10c55ba0ca599373e51105432cf8
* It appears as if our running multiple sync threads can confuse the
mobile sync server during a remote wipe (the server expects the next
client response to be an acknowledgment, whereas it might well be
a command or response from a different thread)
* To avoid this, we first put the account on security hold and then
shut down all other sync threads for the account
* After this, we send the acknowledgment and the remote wipe proceeds
normally.
* NOTE: It's possible that, due to the vagaries of multithreaded
operation, one of the other syncing threads could still send a non-
acknowledgment response to the server before our provisioning thread
gets a chance to send its acknowledgment. However, since the other
syncing threads will terminate (and not restart, because of the hold),
the provision/remote wipe/ack sequence will work on the subsequent
attempt
Bug: 2844888
Backport From: Ib4ffbbc67b681e69176b6c1d5515fa80c7d1e121
Backport From: Ie9e944bd39f331c2ddc0f0ba303a3d5684f6f033
Change-Id: Ie57f13a5ca2149961a48b99afaebb812f1cbc88e
