* Change Sender definition (remove old Message from API) and update
any existing calls through that API
* Rewrite SMTPSender to use provider messages
* Add attachments to RFC822Output
* Minor bugfixes in RFC822Output
* Unit tests
IMAP messages up to about 25k will be downloaded properly.
* Move Store->Provider message rewrite code to a separate utility.
* Add code to descend a Store message and write provider attachments.
* Unit test basic IMAP attachment handler
TODO:
* handle large IMAP messages.
* unit test for POP
* unit test for large IMAP messages
* Remove all use of Strings in favor of the parser's static final int's
* Strings remain in Tags for debugging output only
* Renamed lots of classes to be more consistent
* Centralized logging behavior in Eas class
* Found and fixed some bugs in the process:
- Account deletion wasn't removing HostAuth's correctly in the trigger
- Adding a second EAS account was trashing the first one
- Fixed looping sync behavior caused by Exchange 2003 bug
* Triggers added for insert/delete/update of Message
* update of Mailbox will never set unreadCount
* Removed old test for unread counts and replaced with on
that tests trigger operation.
* Remove Account.updateUnreadCount (deprecated)
* Modify to work with ContactsProvider2
* Modify to work with system AccountManager
* Modify to work with system SyncManager (for triggering user-change syncs)
* Sync server->client for adds/deletes implemented (CP2 doesn't handle delete yet)
* Sync server->client changes handled efficiently (only write changes)
* Some fields still not handled
* Rewrote most of the CPO code to handle server->client changes
* Sync client->server works for supported fields
* Change service API to allow caller to supply complete target path/file
* Also allow caller to supply the final content_uri
* In MessageView, use full integration with EAS service API and
attachments content provider to enable:
* Save: Only works on SD card
* View: Works w/o SD card using content provider & intents
* Thumbnail previews
* Rewrite internals to use EmailProvider instead of raw db access
* Minor changes to APIs as necessary (and scattered changes to follow)
* Convert unit tests and check them
No change in functionality. Just getting a test infrastructure in place
before rewriting to use new EmailProvider. Provides tests for:
* get type (raw & thumb)
* open file (raw)
* open file (thumb)
* query
* resolveAttachmentIdToContentUri
* Moved logic into Controller:
* toggling read/unread
* toggling favorite status
* some new unit tests
* load attachment
* Completed logic for EAS to save attachments and MessageView to
begin and complete that process.
NOTE: Until EAS has a mode for saving the attachment locally (and I
rewrite the attachmentprovider to handle the new database) I am
implementing "view" attachment to just call "save". This means that
attachments "viewed" will be dropped onto the SD card, instead of
cached and flushed.
TODO: Controller is not properly working in its own thread, yet, so
we are not properly preventing ANR's yet.
* Numerous classes modified to deal with this change
* Fixes bugs 1993292 and 1994671
* Renamed various setter and getter methods to reflect the underlying
field names
* Renamed syncFrequency to syncInterval in Account and Mailbox
* Convenience method added to AccountSettings to save only user settings
* Calls to content.update(context, content.toContentValues()), which save
all fields, should be double-checked for correctness, making sure that
content has current data and will not conflict with other threads that
might modify that data
* Ran all unit tests to confirm proper function
NOTE: The logic to enforce single default account no longer works,
because that logic is in Account.save() and does not run via
Account.update(). I have patched out a small section of the relevant unit
test and will file a bug to come back for this fix.
* Remove all references to Account.mIsDefault, which was not the right
way to find the default account (it is lazy initialized)
* Change Account.getDefaultAccount to getDefaultAccountId, which is more
efficient and suitable in most uses.
* Wrote unit tests for provider default account handling
This should resolve bug 1983390 as well as a few other issues with default
account management.
* Added HTML support for Exchange 2007 and later
* Modified MessageView to show HTML parts of body (if present)
* Replace some unused convenience methods in Body to be ones that are more
useful (i.e. retrive body for a given message id)
* Made EAS sending operational
* Updated SyncManager to recognize the creation of new messages and check
for work to be done (i.e. starting Outbox sync)
* Modified MessageView to remove EmailContent.X references
* Also changed the pattern EmailContent.getContent(cursor, class) to the better
new ClassName().restore(cursor)
* Add a test of the utility to determine mime type from file name (since
EAS doesn't provide this with attachment header information)
* Fixed bug in ProviderTestUtils in which the base (EmailContent) fields weren't
being checked for equality in the various subclass equality testers. Fixed a
bug in saving emails that was caught by fixing this bug.
* clean up provider URI's in this area
* minor bugfix in EmailContent, and add auto-writeback of messageId into
saved attachments
* clean up existing attachment unit tests
* add new tests
* EmailProvider now saves Attachment records atomically with Message (and Body,
of course) if an ArrayList is stored in mAttachments
* Update EAS code to support attachment discovery
* Update EAS code to support attachment download via service API (preliminary)
* Add test for atomic attachment save
* Add test for unique file creation (external)
* Scan folders and write into child cursors
* Clicking a folder takes you to MessageList
* Remove most links to FolderMessageList (nearly dead!)
* Repair 1-account startup behavior (takes you directly to inbox)
* Cleanup a few basic things like context menus & refresh
TODO: Magic mailbox section at the top
TODO: As always, better linkage to sync engine(s)
TODO: Menus, context menus, etc.
TODO: Proper handling of expandable list - accounts should stay open?
* Longpress delete in MessageList
* Delete or Menu-Delete in MessageView
* Add deleteMessage() to Controller
* Unit tests for the new code in Controller
Merge commit '4f23ebd3dcca596533a33e6faedb446a814d32e3'
* commit '4f23ebd3dcca596533a33e6faedb446a814d32e3':
Fixed Pop3Store to be able to delete message in Inbox.
When delete policy is DELETE_POLICY_ON_DELETE, PENDING_COMMAND_TRASH
will be invoked. But in POP3 account, because of 1) Inbox is
OpenMode.READ_ONLY, 2) getMessage(uid) just after open() is not work
correctly, 3) remote Inbox folder is not closed after deleting message,
PENDING_COMMAND_TRASH does not work. And also the fat that some POP3
server use UID with '-' prevents PENDING_COMMAND_TRASH to recognize
the message is remote message.
Internal Bug: 1651709
Uses a mock provider to avoid touching production databases.
Includes utilities for creating accounts, mailboxes, and messages.
Tests basic object creation & readback, object deletion, and some
forms of hierarchical deletion. Has many TODO notes for additional
tests to be written.
In EmailContent, found & fixed a few fields that weren't being written to
the database properly.
Merge commit 'a492673609111fe8c41ae152d62547b267346502'
* commit 'a492673609111fe8c41ae152d62547b267346502':
Review Email tests annotations (small/medium/large) and change some annotations based on time.
delete attachment cache files if these are inline images.
The purpose of original logic of loadAttachmnet() is to keep
at most one attachment cache, probably to limit the size of
cached file. But it also purges all inline images.
Integrates CL 149551 from DocomoEmail.
BUG=1884385,1860250
Automated import of CL 149714
What works:
* All unit tests
* Editing existing accounts
* Create new accounts
* Checking account settings against server
* Mail sync using accounts
* Viewing mailboxes
What breaks (in approx order of planned fixes)
* Viewing messages
* Composing messages
* Some details of account editing
* Import of existing accounts
What works:
* Unit tests, except for com.android.email.activity.setup.*
* Editing existing accounts
* Create new accounts
* Checking account settings against server
* Mail sync using accounts
* Viewing mailboxes
What breaks (in approx order of planned fixes)
* Unit tests in com.android.email.activity.setup.*
* Viewing messages
* Composing messages
* Some details of account editing
* Import of existing accounts
Integrate CL 144586,145919 from imode.
Remove the Emoji escaping/workaround for WebView.
Also integrate MimeHeader.java from CL 143064 from imode.
BUG=1785319,1860250
Automated import of CL 149564
This extension is necessary to support some vendor specific
extended header, such as X-NoRtn-Addr of i-mode.net mail.
This change will update LocalStore database version to 24.
And it should be consistent between donutburger Email and DocomoEmail.
BUG=1741969
Automated import of CL 149328
mail into the "Sent" folder, thus eliminating the need to perform a 2nd
upload into the server's Sent folder. IMAP and POP3 do not support
this (although IMAP could when it recognizes Gmail IMAP servers.)
BUG=1807499
Automated import of CL 148230
combine it with the same code that handles folder persistent data (in
the database). The schema is really simple; Rows with a folder id of
-1 are store data. This also adds the ability to use keys to store
multiple values, instead of a single string per account. Added/updated
unit tests.
3rd party stores will need slight code changes because the persistent
callbacks now accept keys.
BUG=1807499
Automated import of CL 148145
Folder.getVisibleLimit(), which used local copies of the data from the
DB. If there were two Folder objects associated with a single actual
folder, updating one wouldn't be reflected in the others.
BUG=1812798
Automated import of CL 148027
(e.g. EAS) can limit itself to n (usually 1) accounts per device.
The UI for this is really simple - don't show the EAS button when the
limit is reached. More work would be required in
AccountSetupAccountType.java in order to do a more sophisticated UI
(e.g. show the button but pop a toast if the limit is reached.)
BUG=1740626
Automated import of CL 148019
to the set that are stored in their own columns (and thus can
be quickly selected from). Add code to migrate old style
flags into new flags. Add tests.
BUG=1786939
Automated import of CL 148002
MessagingController to accept and track a Context, instead of the
unnecessary Application object, which makes this fix more testable.
BUG=1790798
Automated import of CL 147868
due to API change, but still has a smaller footprint. Also fixes the
bug in the original, which is that we actually needed to udpate the
local trash folder, not the remote one.
BUG=1807499
Automated import of CL 147714
*** Reason for rollback ***
We figured out a simpler solution affecting fewer files - we
don't actually need the new remotestore API.
*** Original change description ***
Some stores require changing the UID of a message when it is
copied to a new folder (I'm looking at you, EAS). Add a callback
to Folder.copyMessages() which allows the store to report back
such changes. Then, add a new api to record the new values:
Folder.updateMessages().
For now, the two APIs are linked by a common callsite in
MessagingController, so the existing stores can use a minimal
implementation - if they don't call the callback, nobody will
call the update.
BUG=1807499
Automated import of CL 147708
copied to a new folder (I'm looking at you, EAS). Add a callback
to Folder.copyMessages() which allows the store to report back
such changes. Then, add a new api to record the new values:
Folder.updateMessages().
For now, the two APIs are linked by a common callsite in
MessagingController, so the existing stores can use a minimal
implementation - if they don't call the callback, nobody will
call the update.
BUG=1807499
Automated import of CL 147620
deeper database-style operations with them. This enables two
new LocalStore APIs to be provided: A new version of
GetMessages() that can retrieve only flagged (or un-flagged)
messages, and a new method to set flags for an entire set of
messages, in a single SQL transaction.
BUG=1786939
Automated import of CL 147401
of the role-specific folders such as Drafts, Sent, or Trash.
This allows us to properly target these folders even on
systems where they have different names. I capture the
tagged names into the existing columns in the account data,
where they are used elsewhere in the code (no changes
necessary).
Use default implementations on POP3 and IMAP for now -
no change from original behavior. The new code is
primarily to support EAS (for now).
BUG=1790798
Automated import of CL 146360
The default values are 25 (default) and 25 (increment). This is fine
for Stores that control downloads by # of messages, but won't work for
stores that use other measurements - e.g. EAS windows the download in #
of days. So for this change:
1. Allow the StoreInfo to provide non-default values
2. Remove the hardcoded references to the default values
3. Use StoreInfo values everywhere
4. Set the values to 1,1 in EAS store info
BUG=1789913
Automated import of CL 146331
syncing. This provides a key-value store, per folder, that
can be used by network Stores to record persistent data such
as sync status, server keys, etc.
Note that, by definition, this only applies to remote folders
(e.g. IMAP, POP3). You'll see everywhere that LocalFolder is
passed null, and this is correct - LocalFolder *is* persistent
storage and does not need external help.
Note to reviewers: The core changes are Folder.java,
LocalStore.java, and LocalStoreUnitTests.java, so please give
them the bulk of your reviewer attention. The other files
are just following along with minor API changes. Of those,
the one worth close examination is MessagingController.java,
which is the only place in the system where remote Folders
are bonded with Local Folders and thus where this new API
comes into play.
Note to jham: Can you please take a look at
LocalStore.LocalFolder.setPersistentString() and recommend
better SQL foo than my primitive test-then-update-or-insert
logic, which is not transactional or threadsafe.
BUG=1786939
Automated import of CL 146134
The current design for Store classes (e.g. IMAP) did not provide for
any persistent storage. This is the beginning of a mechanism to
provide that. It's quite simplisitic - each Store can read/write one
persistent string - but that's enough for the first simple use case
(saving some sync data for EAS).
The core changes here - suggest reviewing first - are in Account.java,
Store.java, and AccountUnitTests.java. Everything else is just
following the API change that was necessary.
Note that, by definition, this only applies to remote stores (e.g.
IMAP, POP3). You'll see everywhere that LocalStore is passed null, and
this is correct - LocalStore *is* persistent storage and does not need
access (so far, at least).
BUG=1786939
Automated import of CL 146061
1. Generalize the code for the various spinners that control
account check frequency.
2. Provide an API for looking up store attributes (and refactor
existing instatiateStore logic to use it).
3. Cleanup the old code that was used to setup frequency spinners.
4. Hardwire Exchange accounts to default into push mode.
Notes to tester:
1. For each account type (POP, IMAP, EAS) we need to check that
auto & manual creation "do the right thing" for frequencies.
POP & IMAP should offer "none" or time intervals, while EAS
should offer "push", "none", or time intervals.
2. EAS accounts should default to "push", all others to "15 min"
3. Make sure that you can edit existing account settings and see
the right choices (only EAS should be offered push).
4. I couldn't write an automated test for the mail checker service,
please confirm that POP & IMAP accounts are checked at the right
intervals (or never, if set for "none".)
BUG=1776149
Automated import of CL 144953
