There's no need to create a URI just to rip in appart again. Additionally, to
support additional changes (i.e. to use Mailbox instead of Folder in the
MessageController), we need to store the actual Account.
NOTE -- This change only affects IMAP and POP3. SMTP will come in a follow-on CL
Change-Id: I400036a17271c99272fd9c603547dcd713b50b9d
If an IMAP server supports the UIDPLUS capability, it can return the new UID
as part of the response to the "UID COPY" command. However, if the server does
not support UIDPLUS, we perform a SEARCH to try to determine the new message
UID.
This is the second of a couple modifications.
bug 4092301
Change-Id: I1f548b63becfec8733cb8ba9a3fe6ff4be6fdd83
When copying messages between mailboxes using standard IMAP, we must perform
a QUERY or FETCH in order to determine the new message UID. However, if the
server supports the UIDPLUS capability, the server will return the new UID
as part of the response to the "UID COPY" command.
This is the first of a couple modifications. We still need to fallback to a
less efficient QUERY/FETCH if the server does not support UIDPLUS.
bug 4092301
Change-Id: I9279f7fd70daf85adba3b3e202c12d67ddf91f22
* There are three pieces to this CL (sorry):
1) Move and/or rename some constants into emailcommon
2) Move Utility to emailcommon, moving the few UI
related utilities back into Email (FolderProperties
and UiUtilities)
3) Remove all references to resources from emailcommon
* The three pieces relate in that, between them, they allow
the emailcommon static library to compile cleanly
Bug: 3442973
Change-Id: Ic5e3abaa2a1b36999e0b6653c6c2134ea1bd544f
We support two different ways for an IMAP prefix to be specified:
1. A text field on the IMAP configuration page. This is the most obvious to
the end user. It is also an explicit, manual configuration.
2. RFC2342 defines a NAMESPACE IMAP command to be able to query the prefix
from the IMAP server. This is an automatic configuration without any
user involvement (i.e. the UI will NOT change if a prefix is loaded in
this way)
If the user goes to the trouble of specifying a prefix, we will always honour
it instead of the namespace returned by the IMAP server -- even if the user's
configuration is wrong.
bug 1592696
Change-Id: I6b94c7aaac538f6cd9dc4694b0f1634e8c956bc1
* No code was harmed, er, changed in the making of this CL
* All that's happened is that code that is needed by both Email and
Exchange have been moved into emailcommon
* This required import changes to many files, which explains the
length of the CL
Change-Id: I4e12455ba057a4a8054fdbd0b578c73afa411c8a
* Remove LocalStore (pre-2.0 mail database) and its unit test
* Remove UpgradeAccounts (converted pre-2.0 accounts to Provider)
* Remove FolderMessageList (receiver for pre-1.6 desktop shortcuts)
* Remove "upgrading" paths through LegacyConversions
* Clip out dangling references to everything above
Bug: 3292310
Change-Id: I5654d55a0879b00b05b63055b94651855a8ee3ef
Fixes deprecation warnings
NOTE: This does not resolve hostauth deprecation; that will be fixed
in a separate CL.
Change-Id: I47115516da34effbf885615cb439c9d3e6f95b84
Only send IMAP ID to servers that include ID in the CAPABILITY response.
Always sending IMAP ID was found to cause problems with some servers.
Better compliance with RFC 2971.
Thanks to Samsung for debugging & reporting this.
Change-Id: I495f80949f9f811470853a1f2f8e506d8236d8cf
* Update MockTransport to allow TLS connections
* Test TLS connection in ImapStore unit tests
* The bugfix: Re-query capabilities after closing/reopening parser for TLS
(Note: Actually, this is required by the IMAP RFC 3501, 6.2.1)
Bug: 3315939
Change-Id: I51f838043e87750b5712a1bd2e4f9c821b58c808
* This is the fix to bug 3008626 that was created in Gingerbread
and backported to Froyo for an MR release
* The bug prevented validation of EAS w/ Exchange Server 2010 SP1
* For some reason, this fix did not get merged forward into master
resulting in the bug referenced below
Bug: 3254512
Change-Id: I4e48a8f95b31048f09a036cc16db867da4116f04
* 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
* For now, clicking on the notification takes the user to the
Welcome activity, as we don't have final flows for the new
account setup UI
* Need comment on strings; the problem is that notification
text must be rather short if we're to use the standard
notification display. It looks like newer UI will allow
3 lines instead of 2, however.
* Tested w/ IMAP, POP3, EAS, and SMTP
Bug: 2322253
Change-Id: I7ed6fa5599179870cbcdb14af062e956eff37ec5
- mConnection.destroyResponses() should be protected with
if (mConnection != null).
When we get an IOException, we close the connection and null it out in
ioExceptionHandler(). So mConnection can be null at any point after
where ioExceptionHandler() first appears.
- ioExceptionHandler should close its parent ImapFolder only if the argument
connection is mConnection.
Methods like exists() may pass an ImapConnection which is not mConnection
to ioExceptionHandler. In which case we don't have to close the ImapFolder.
Bug 2898211
Backport of I8f9f45d91f596bb8da1a1575593e652d66deb643
Change-Id: I070458b5535540aba69ad7eee88bd2af8ad5f7b1
Apparently IMAP servers may return multiple SEARCH responses for a
single SEARCH command, and we need to handle all of them.
Before the IMAP rework there was 3 methods that issued the SEARCH command.
Two of them ware doing it right, but the other wasn't, which was what
I copied from, unfortunately!
In case you're wondering, originally the test for this method was done through
upper methods, e.g. getMessage().
Bug 2911647
Backport of Ia50072944d5b01c1e59541c3a966067b13910cc4
Change-Id: Iab5d3fa21e403f2e1043990112154fbb72322b02
- This is to make sure we're not touching any ImapResponse that's
already been destroyed.
- I didn't add "is it already destroyed?" check to them
(except for ImapTempFileLiteral), because it can be costly.
Just let NPE be thrown.
Backport of Idc7b88c4844727922841cbad8a106bf781181d45
Change-Id: I9932e78a49784e4218e939a12ebcb9a497c4eb57
Unfortunately it's hard to write tests for this change, but at least
all tests pass with Idc7b88c4.
Backport of If0335a848dfcc23aecea22c21b2cce73dac7ff6f
Change-Id: I6cb3525bc3c67bbf2fb101488bf95edbead5d299
- Replace string literals in ImapStore with constants.
- Simplifies ImapStore.en/decodeFolderName
- Mix cases in the test data to test for case-insensitivity
Backport of I88424357227bcf78528df5e6a1c4ba45d54cc65b
Change-Id: I254fe82324f6ff530e40ca0cff7073f670cf9aa3
- Almost completely re-wrote ImapResponseParser layer
- We no longer use simple ArrayList and String to represent
imap response. We have classes for that. (Type safe!)
These classes are also NPE-free.
(which isn't necessarily a good thing, though)
- A lot of clean-ups and fixes in ImapStore.
- More tests for ImapStore.
Now ImapResponseParser moved to com.android.email.mail.store.imap.parser,
but inside, it's 99% new code.
This CL introduces many new classes, but most of them are small classes
to represent the IMAP response.
Problems that this CL fixes includes:
- Special characters in OK response
- Handling BYE response
- Case sensitivity
- ClassCast/ArrayIndexOutOfBound/NumberFormatException
- Handling NIL/literals at any position
Bug 2480227
Bug 2244049
Bug 2138981
Bug 1351896
Bug 2591435
Bug 2173061
Bug 2370627
Bug 2524881
Bug 2525902
Bug 2538076
Backport of I7116f57fba079b8a5ef8d5439a9b3d9a9af8e6ed
Change-Id: I38b6da7b82110181dc78a2c63c6837c57afa81ae
- A few new tests in ImapStoreUnitTests.
- Added TODOs to ImapStoreUnitTests (for mainly NO response handling)
- Renamed ImapStore.releaseConnection to poolConnection.
- Fixed a bug in getConnection where it'd return a closed connection.
- Now getConnection() hanles BYE response for NOOP correctly and treat the
connection as closed.
Backport of I48e5b89049338f7d4f1ac77cd7ac7243945a9575
Change-Id: I529c6667a1e60c67285b7050b2b1e4b67eccc104
- Also, fixed a potential crash in getMessages().
It could happen when a client is gettign a message list while
another client is removing messages.
Backport of I04b1de6bc384cffb7a5286bcec0a349a3d62a623
Change-Id: I227ecbf5bd68c999ba0ab8cd50ef798ef4ef35e4
Main motivation: not to make the new IMAP parser too complecated.
- Removed messageRetrieved.
Motivation:
- It's not easy to call messageRetrieved() at the proper timing
from the new IMAP parser, and this method wasn't used anyway.
- Renamed messageFinished to messageRetrieved.
And removed the "number" and "ofTotal" arguments.
Motivation:
- They weren't used. Also there was inconsistency about
what to pass as "numebr". (i.e. 0-based or 1-based?) There was
even a bug that caused passing a wrong number.
Backport of If92dbfe681b78a0eea8125188ede63a8f00dcf49
Change-Id: Icdea45e0a9ac567b1cdfb44e975e60bb11815472
- Fix misnomered fields. (e.g. static mMember -> static sMember)
- Reduce visibility. (e.g. mark as private)
- Mark final / static if possible.
Note it's on master.
There's a lot more cleanup oppotunities in the activities, but they're going
to go through a major overhaul, so I didn't bother.
Backport of b3f7dd0169
Change-Id: Ic33f9518f23805716e2aec0ab42edb92107e066c
Apparently IMAP servers may return multiple SEARCH responses for a
single SEARCH command, and we need to handle all of them.
Before the IMAP rework there was 3 methods that issued the SEARCH command.
Two of them ware doing it right, but the other wasn't, which was what
I copied from, unfortunately!
In case you're wondering, originally the test for this method was done through
upper methods, e.g. getMessage().
Bug 2911647
Change-Id: Ia50072944d5b01c1e59541c3a966067b13910cc4
- mConnection.destroyResponses() should be protected with
if (mConnection != null).
When we get an IOException, we close the connection and null it out in
ioExceptionHandler(). So mConnection can be null at any point after
where ioExceptionHandler() first appears.
- ioExceptionHandler should close its parent ImapFolder only if the argument
connection is mConnection.
Methods like exists() may pass an ImapConnection which is not mConnection
to ioExceptionHandler. In which case we don't have to close the ImapFolder.
Bug 2898211
Change-Id: I8f9f45d91f596bb8da1a1575593e652d66deb643
There are two major, interrelated parts to this CL:
1) Clean up the activities to reduce the use of Intents to pass
information between activities; instead, we use a common
SetupData structure that automatically saved/restored as necessary
during the setup flow. A fair amount of code and inconsistent
use of Bundle extras has been eliminated in the process.
* Create SetupData structure, setters/getters, and initialization
methods to simplify the preservation of state during setup flow
* Remove all state/flow extras from Intents; Intents now only
specify the Activity to be started, which should greatly simplify
the transition to Fragments.
* Remove all state/flow fields from Activities
* Modify existing setup activity unit tests and confirm tests pass
2) Create AccountManager accounts for POP/IMAP email accounts to
provide consistency in user experience. Also, internal flows are
now identical as between account types.
* Move account reconciliation from SyncManager to MailService, so
that reconciliation is consistent between email and exchange
accounts; move unit tests as appropriate
* Add a "Sync Email" setting for POP/IMAP/EAS
* Change MailService to respect the "Sync Email" setting in
Settings -> Accounts & sync
* Create PopImapSyncAdapterService to handle manual POP/IMAP sync as
requested by SyncManager; add EmailSyncAdapterService to perform
the same function for EAS
* Use new PopImapAuthenticatorService to add AccountManager accounts
for POP/IMAP accounts; setup appropriate stanzas in AndroidManifest
and add related xml files
* Update AccountSettings to use SetupData
Miscellaneous other changes:
* Only allow valid port numbers in incoming/outgoing setup
Bug: 1712475
Change-Id: Ibdac52fb2c5578b86bf3992ddb1acd10f162391a
* The setup flow is changed such that the user is asked to activate
device administration before leaving the setup flow, rather than
having to wait for the notification to appear, etc.
* Accounts requiring security are created in a security hold state
to prevent initial sync until device administration is active
Change-Id: I7e33cf98466370ae27414b99018f7aee71e9e237
* Add intent filter for application/eml and message/rfc822 mime types,
launching MessageView with a Uri
* Modify loadMessageTask to handle the Uri by parsing the attachment's
input stream with Pop3Message.parse(), and then creating an
EmailProvider message in a special Mailbox created to hold
"attachment" messages
* Delete all "attachment" messages after the parent message is closed
* Add unit tests
Change-Id: I20276ee006b9f05b889f3c808d3dc407cde26d49
- This is to make sure we're not touching any ImapResponse that's
already been destroyed.
- I didn't add "is it already destroyed?" check to them
(except for ImapTempFileLiteral), because it can be costly.
Just let NPE be thrown.
Change-Id: Idc7b88c4844727922841cbad8a106bf781181d45
Unfortunately it's hard to write tests for this change, but at least
all tests pass with Idc7b88c4.
Change-Id: If0335a848dfcc23aecea22c21b2cce73dac7ff6f
- Replace string literals in ImapStore with constants.
- Simplifies ImapStore.en/decodeFolderName
- Mix cases in the test data to test for case-insensitivity
Change-Id: I88424357227bcf78528df5e6a1c4ba45d54cc65b
- Almost completely re-wrote ImapResponseParser layer
- We no longer use simple ArrayList and String to represent
imap response. We have classes for that. (Type safe!)
These classes are also NPE-free.
(which isn't necessarily a good thing, though)
- A lot of clean-ups and fixes in ImapStore.
- More tests for ImapStore.
Now ImapResponseParser moved to com.android.email.mail.store.imap.parser,
but inside, it's 99% new code.
This CL introduces many new classes, but most of them are small classes
to represent the IMAP response.
Problems that this CL fixes includes:
- Special characters in OK response
- Handling BYE response
- Case sensitivity
- ClassCast/ArrayIndexOutOfBound/NumberFormatException
- Handling NIL/literals at any position
Bug 2480227
Bug 2244049
Bug 2138981
Bug 1351896
Bug 2591435
Bug 2173061
Bug 2370627
Bug 2524881
Bug 2525902
Bug 2538076
Change-Id: I7116f57fba079b8a5ef8d5439a9b3d9a9af8e6ed
We have singletons that store a Context passed to getInstance().
The problem is that when we call them, we casually pass any Context at hand.
If it's an activity (which is often the case), it'll never be GCed.
This CL make them store the application context insteaed.
Change-Id: I1abcc2c08d3f8201416d6c14720f041693823b4e
Todd Kennedy