This version is hybrid of the old design and what Andy's suggested.
- MessageViewFragment is responsible to show a single message at a time.
- Call MVF.openMessage() to tell it to open another message.
No need to re-create a new MVF to do this.
- MessageView manages the message list, and handles "move-to-newer/older"
buttons.
Reason for not re-creating a fragment when opening another message is:
- Re-using the same fragment doesn't make it as complecated/ugly as I
was initially afraid.
It's basically cancelling all running tasks, re-initializee some views,
and load a message.
- We don't have to run MVF.onCreate() over and over again when moving through
messages.
We may change the strategy later, but I think it's suffice for now.
(Changing this might affect how the back key works, so let's revisit it
when the fragment manager supports back.)
Basically this CL is all about internal changes.
No UI should have changed except for:
- Moved "Move to newer/older" buttons to the bottom.
Also fixes:
Bug: 2849129
Change-Id: I00c05069231afded9d98d3d52dd9a7925ebdee9d
ListFragment shows the "Loading..." animation for us until setListAdapter is
first called. In order to make use of it, setListAdapter should be called
only when the underlying data is ready.
Change-Id: Iac903b1f10ad7ed4be04446ddb2d2172e84bfe16
* Backport from master branch
* Send policy key of "0" when validating; this gets us the policies
even if "Allow..." is enabled (currently, we simply don't see the
policies)
* If we don't support all of the policies, send back the response
code indicating support for partial support. If we get a positive
response back, then we're good to go - the server allows devices
with partial support. Otherwise, we fail as we always have - with
the toast indicating that the device doesn't support required
policies
* Remove PolicySet.isSupported() and ensure proper field ranges
within the constructor
* Update tests as appropriate
Bug: 2759782
Change-Id: Ida5663a9b35c75ecc61a5f442be0bd60b433cb73
* Add this to processSourceMessage in the reply/forward cases
* Add unit tests for reply and forward case
Bug: 2734321
Change-Id: I6be8383fe5f217a4bda8e669cb69f439bc8e96b6
* During refactor of referenced change, a critical line of code
got lost; it's replaced in this CL
Change-Id: Ib6f405cdfa120f5cb5c879ab0f7df52d54970cb7
* Handle status 5 for Ping command (heartbeat of out range)
* Write unit test for heartbeat reset
Bug: 2834195
Change-Id: Ic7952a4b296cf15c6ba895d6579fe7956b171e5b
Introducing MessageOrderManager which maintains a message list for
MessageView. It's used to tell if there is newer/older messages
in a mailbox, and the id of them.
Also, slightly related to this, moved mWaitForLoadMessageId to
ControllerResults where it should belong.
Change-Id: I84e32180c7e84a317f2204bb10ad7245ec022dca
- These tests will probably not make sense with the upcoming UI change.
- Moved testAttachmentWritePermissions to UtilityUnitTests.
It's a test for createUniqueFile, which is now owned by Utility.
- Removed Long.MIN_VALUE hack from MessageView.
New tests should have something better.
Change-Id: I9a09e5e8080a165b010607d1fa3112bcaaab4f90
* Created MockProvider that can be used for testing the results of
ContentProviderOperation's for Calendar/Contacts (we can't use these
within our mock contexts because we can't instantiate the provider
classes within the Email package)
* Wrote some unit tests for MockProvider
* Use MockProvider to test addEvent, in particular how a user's attendee
status is stored, depending on whether the event is new or updated
Change-Id: I97f02d125eb7347726261e12ce70aadc539be1d4
* We need to include the intro text (--Original Message--, etc.) to
SmartForwards, and somehow this got in a past updat
* Add unit test for forwarding
* Fix unit test for reply so that it works localized
Bug: 2477988
Bug: 2685784
Change-Id: I8d92f00d37a434840ec3eb237f3901cd5dc7ad09
* We inadvertently broke this with a recent update that uses Uri
encoding for ItemId and CollectionId in SmartForward/Reply commands.
We need to allow colon (:) however for EAS 2.5; otherwise, sends
fail with HTTP 500
* Update unit test
Bug: 2821684
Change-Id: Ia6bdd2169513d1c13a8174dd599477a35df950f2
* The meaning of a busy status of "Busy" is uncertain; it could mean
"Accepted" or "Tentative", depending on whether the event was
created via OWA/Outlook or EAS
* We have interpreted it as "Accepted", which prevents the user from
actually accepting the event (as a state change is required for us
to send updates to the server/organizer)
* This CL changes the behavior such that a newly arriving event with
a "Busy" status is shown as "No response" in the Calendar, thereby
allowing the user to pick from any of the three possible options.
Bug: 2811859
Change-Id: Ie2c375278b79b47dedac02472dfe6e4cf1182b65
For EML,
- No menu
- No older/newer buttons
- No star
- No bottom buttons.
I've started to feel like the two UIs (one for regular messages and the
other for EML files) shouldn't be handled by one class; we probably
should separate them into two different classes. I'll see if I can
do that after fragmentize it.
Bug 2804147
Change-Id: I5ae162af546bfc21af27352c642d6b2a1e16cf0f
- Removed dead code/dead comment.
- Moved static utility methods to Utility.
- Renamed some methods.
- Changed the timing to call super methods.
Also:
- Internationalized formatSize()
- Added unit tests for createUniqueFile() and formatSize()
- createUniqueFile now uses File.createNewFile() instead of exists().
Change-Id: Ibc30e15b029ed5088954bd6fc9032e25dddf176e
* The code assumed that all accounts used the scheduler in MailService
whereas only those using MessagingController do so (i.e. EAS does
not)
* Change setupSyncReportsLocked to set the syncInterval for accounts
that don't use MessagingController to Account.CHECK_INTERVAL_NEVER
* Add unit test for the changed code
Change-Id: I74a3dae21d9ec16f9903bdf2a1c28092ae89cc50
Dial *#*#36245#*#* on the dialer to activate the debug screen.
"36245" = "email"
It's useful when
- There's no keyboard.
- There's no account set up yet.
(You can do it by entering the special username/password on new account
screen, but that's a bit of a pain.)
It's also easier to tell to people.
Also, removed "sensitive logging", which should never be used.
Change-Id: Id692f8b216f2d85abe1880c452d2067f170dac83
When connecting to an IMAP, POP3, or SMTP server using SSL, perform
an explicit test of the certificate's host name against the server's
host name. Refuse connection if they do not match.
Bug: 2807409
Change-Id: Ib223170f1a5d57323a88037ad30fec15c6bbce20
* During the fix of a previous late-Froyo issue, a change was made that
appeared superficially correct, but was semantically incorrect. This
changed the sense of the test for whether a reply email was required
and caused the referenced bug.
* The trivial fix is to replace the test with the (older) proper one
Bug: 2764551
Change-Id: I7c72366252cf0607aee31ee0d76aca96a7d5fc2b
Note: This does not appear in UX wireframes, this activity is going
away eventually, but it's a good testbed for ActionBar to be tried out.
Open issues:
1. Waiting for progress indicator support, using unattractive hack
2. Subtitle doesn't seem to work so putting account name in title
(which is the wrong font size for phone portrait mode).
Change-Id: Iee3cac7d4f30ea210bd8f3838b69ed12cd498375
* We need to encode the itemId and collectionId for SmartForward and
SmartReply
* Add unit test for the fix
* Small change + test to EasSyncService usage of URI encoding to use
a non-deprecated method
Bug: 2787725
Change-Id: I428b308b56cc359b8cdd9e42bc3f42c65b6797dc
Displays actionbar properly, and the two buttons work.
Submitting with one open issue:
1. The indeterminate progress indicator is not directly supported in the
ActionBar. We're waiting for a UI call or framework support. Until
then there is a placeholder using an incorrect icon to show progress.
Change-Id: Iaf1546931376cc5b540820cd0fc020ebd176dabf
* Use the new Account.getProtocol() method to determine whether an
Account "isMessagingController" (i.e. uses the legacy controller)
* Cache the result of this test, so that it's only done once per
Account
* Add unit test
Change-Id: I6a0ec789a84bdf30b55156e6337a627fb4e81a08
* 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
* We weren't sending the proper protocol version to GAL search, which
causes errors when using 12.1
* The simple fix is to send the agreed upon protocol version, instead
of the default (which is 2.5)
* Replace parsing of protocol version with lookup
Bug: 2793588
Change-Id: Ib2a255d8467004ce985d2d688b37066e1e09d78a
- Long-press an item to go into the selection mode.
- In the selection mode, tap items to toggle selected/non-selected.
This also means:
- No checkboxes any more.
- No context menu any more.
Color scheme hasn't been updated yet, so it looks a bit ugly for now.
Change-Id: I3cb6c45c1dc5461a234c9e9ab9e038c90a9fe8b2
* Minimum complex characters
* Password history (i.e. disallow re-use of past n passwords)
* Password expiration
* Password expiration is NOT yet supported in the framework; there
is a TODO in this CL and a trivial change will be needed when
support arrives; for now, we report this as unsupported
* The two implemented policies are testable
Change-Id: I477adbc000577c57d1ab1788378c97a60018c10c
* 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
- Now open, reply, reply-to, forward are handled by activity.
- Renamed onDelete. (I was thinking about renaming more methods, but I ditched
the idea because the current ones aren't that bad.)
Change-Id: Ie88e8cc3c6bd598199cfd9f4cd61d51e8b7023b7
* Introduce AccountFolderListFragment and its layout
* Extract all list-related UI into it
* Fix leaking cursor in AccountsAdapter and add unit test
Change-Id: Ica566847d97927b736f515d434c6691c82343290
- Introduced EmptyCallback to avoid the flood of null checks.
- Fixed some TODOs in MessageListFragment.
- Notably, sendPendingMessages() is now handled by the fragment itself,
rather than by the activity.
- Moved two DB accesss from the UI thread to a worker thread.
- Replaced the 'mailboxid < 0' check with isMagicMailbox(), which is more
explicit and easier to understand.
- Renamed some methods in preparation of moving to the activity.
Change-Id: Ie730c2c561050bbfa83a38252fcf09d59238f7ea
* Send policy key of "0" when validating; this gets us the policies
even if "Allow..." is enabled (currently, we simply don't see the
policies)
* If we don't support all of the policies, send back the response
code indicating support for partial support. If we get a positive
response back, then we're good to go - the server allows devices
with partial support. Otherwise, we fail as we always have - with
the toast indicating that the device doesn't support required
policies
* Remove PolicySet.isSupported() and ensure proper field ranges
within the constructor
* Update tests as appropriate
Bug: 2759782
Change-Id: I5f354a0e2d81844aff75d8a8a6de3b97f0020c1f
- Extracted MessageListFragment out of the MessageList activity.
- This is basically pure extraction, with the following conceptual change.
- Now the MessageList activity doesn't know the mailbox id or
the account id. If it needs these ids, it needs to ask the fragment.
- MessageListFragment.LoadMessagesTask tries to determine the account ID
if it's unknown.
Most code in MessageListFragment is directly copied from MessageList
with minimal changes (e.g. pass mActivity instead of 'this' as a Context).
There's a few cleaning up oppotunities. I'll work on them later in a separate
CL.
Change-Id: Ie004cc49b429f2cd8f9de73df5abb94f3054ea0a
One thing that bothers me regarding the new ImapStore is that there is no
tests to verify if the way how getImapId() uses a vendor policy hasn't changed.
This part is hard to test with a real vendor policy, and it can easily be
overlooked even if it's broken.
This CL offers ImapStoreUnitTests a way to test the interaction between
getImapId() and a vendor policy.
Also fixed a bug in VendorPolicyLoaderTest where it assumed the test apk
package name is "com.android.email.tests", but it may actually be
"com.google.android.email.tests" now. (Broken since the test makefile
used inherit-package.)
Change-Id: I8feb616ea28cb5cae5b4fba57e363771014ac599
Merge commit '7a358316ae1c52fadf7ce8470fc5d257d1a71eaa' into gingerbread
* commit '7a358316ae1c52fadf7ce8470fc5d257d1a71eaa':
Work around problem w/ large CalendarProvider2 transactions
* We're seeing binder transaction failures when we try to send more than around
1500 CPO's to CalendarProvider2 in a batch (the limit is related to memory
usage in binder transactions)
* When an event has A attendees and E exceptions in an event, we currently must
create A*E CPO's; this number can become very large and cause a binder failure
* The result of a failure is looping behavior, resulting in failed sync and very
much reduced battery life
* The workaround here is to redact all non-organizer and non-user attendees from
exceptions once we reach half of the maximum number of CPO's. This has been
determined empirically and is set to 500 CPO's in this CL
* We also reduce our sync "window" to 4 calendar/contact items per sync command
to help limit the potential size of our batch
* For later releases, we should reconsider this and see if something that is more
of a "fix", rather than a workaround, can be implemented
Bug: 2760514
Change-Id: I06ca1a1ae88c772342a9e46b5997c41678e95144
* We're seeing binder transaction failures when we try to send more than around
1500 CPO's to CalendarProvider2 in a batch (the limit is related to memory
usage in binder transactions)
* When an event has A attendees and E exceptions in an event, we currently must
create A*E CPO's; this number can become very large and cause a binder failure
* The result of a failure is looping behavior, resulting in failed sync and very
much reduced battery life
* The workaround here is to redact all non-organizer and non-user attendees from
exceptions once we reach half of the maximum number of CPO's. This has been
determined empirically and is set to 500 CPO's in this CL
* We also reduce our sync "window" to 4 calendar/contact items per sync command
to help limit the potential size of our batch
* For later releases, we should reconsider this and see if something that is more
of a "fix", rather than a workaround, can be implemented
Bug: 2760514
Change-Id: I2941b392ae1058a9ead8a79f0ac73f4eb345917d
- Controller.Result is now a class rather than an interface,
so subclasses don't have to implement empty methods.
- Replaced Threads with AsyncTasks, which is more light weighted
because it uses pooled threads.
- Removed the Result argument from Controller's methods.
These argumetns weren't used, except in serviceCheckMail.
Regarding serviceCheckMail, the new code behave differenly from the old code.
If there's already listeners registered when it's colled, they wouldn't get
called in the old code, but they will in the new code.
But I think this difference is okay because that's how it works for
POP/IMAP accounts.
Change-Id: I37a857ce7c089c1a411cb7f1fcfcb72c9f5fd2a6
* Moves all list-related implementation to new MailboxListFragment
* One item that remains to be done is to remove the dependency on the
activity for handling context menu (longpress) in the list.
Change-Id: I7b5769d9d81fb685cf480de3d3e18b4e1c078f2d
- Removed Handler.
- Refactored FindMailboxTask so it only does DB access on a worker thread.
(Moved the actual task out of doInBackground)
- Removed unused imports, which I forgot when I extracted the adapter.
Change-Id: Ib76ce2ab7901dd39d2ed51d8a61d7be9df55b337
AccountFolderList, MessageCompose and MailboxList.
Also,
- ControllerResultUiThreadWrapper now takes a Handler instead of an Activity.
So that it can be used from a Service as well.
- ControllerResultUiThreadWrapper.getWrappee() to get the wrapped object.
We'll eventually need this.
- I'll work on MessageList too, but the might be relatively
large, so I'll do that in a separate CL
Change-Id: I281d88d5af1834248ec3f7463f0df3f5635149be
- 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
- Merged all three BroadcastReceivers into one.
(Changed class name because old ones may have been disabled.)
- Use IntentService to perform the tasks in a worker thread.
Note the new receiver will never be disabled. We always need to start
exchange.SyncManager.
Bug 2722155
Bug 2416929
Change-Id: I8241880fc1ee38d85dcdca7e1d46fc2f6b2d375b
Part 1: MessageView
- It's an attempt to get rid of Handlers from Activities, and
reduce the amount of code that runs run a BG thread in them.
- Introduced ResultUiThreadWrapper, which wraps another Controller.Result
and make callbacks get called on the UI thread.
- It'll make the logic in ControllerResults cleaner and more straightforward.
- ResultUiThreadWrapper isn't too memory efficient because it allocates a
Runnable even if the wrappee's target method is empty.
However these callbacks don't get called often, and optimizing it would
make code more complicated, so I don't think it's worth optimizing.
- Now we can assume all the methods in activities except
AsyncTask.doInBackground runs on the UI thread, with some special exceptions
like MediaScannerNotifier.
In my previous abandoned change, I named methods that can run on BG threads
'*OnUiThread', but now there's no need to do that.
This also means we can minimize the use of synchronizations.
Change-Id: Ia6d9d2a266ebf5a4b23d712e9eaea3272adbd2a6
- 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
* Extract AccountAdapter from AccountFolderList
* Use callback instead of hardcoded launch of MailboxList
* Unit tests
Change-Id: Icafce1ef73a99fb61985c649620440656f9b51a3
* To avoid having to use a mock deviceId with FolderSync in validation, we now
simply use the real deviceId with the correct SyncKey ("0" for a new account,
or the actual sync key if the account already exists)
* Rework utility code that finds existing accounts
* Write unit test for findExistingAccount
Bug: 2589243
Change-Id: Ia532b2e209aec3aa01ca06617b4da78c3d986b32
* Support required protocol changes
* Handle new security policies based on current device capabilities
Change-Id: Id1d629d41d957911344e6c503d28418f5e7e1386
Merge commit '77e2161559467ac94ffdbaa2d51716354741ae17' into kraken
* commit '77e2161559467ac94ffdbaa2d51716354741ae17':
Handle case of null organizerEmail in changed event
Merge commit '8c742a4c65e1ff2618e1005803edb65a42994fb6' into froyo-plus-aosp
* commit '8c742a4c65e1ff2618e1005803edb65a42994fb6':
Handle case of null organizerEmail in changed event
* A recent change assumed that organizerEmail couldn't be null while
an event was being added. However, there is an unusual case in
which it CAN be null, and this CL handles that case
* Regression caused by: SHA 7f448dcd47
Bug: 2719254
Change-Id: Idb8fc79c898bcd2e53fcc8b3e42d0ba67ba762fa
Merge commit '17c8b3388c1aceb5a4886f7d783e1db1913d9d05' into kraken
* commit '17c8b3388c1aceb5a4886f7d783e1db1913d9d05':
Remember to store modified organizerEmail
Merge commit 'b6a08f68d7c49835fffed0719e99c13b50fa525c' into froyo-plus-aosp
* commit 'b6a08f68d7c49835fffed0719e99c13b50fa525c':
Remember to store modified organizerEmail
Merge commit 'd3951041f613008dcbd3cd4b3ddebdad5ccab806' into kraken
* commit 'd3951041f613008dcbd3cd4b3ddebdad5ccab806':
Limit the number of attendees in a synced event
Merge commit '7f448dcd470ac509a85368a84f5a55c346ae7e70' into froyo-plus-aosp
* commit '7f448dcd470ac509a85368a84f5a55c346ae7e70':
Limit the number of attendees in a synced event
* If there are over 50 attendees in an event, we only store the
organizer as an attendee (the rest are redacted) and we set
the hasAttendeeData flag to 0
* If the user is the organizer, we reset the owner of the event
to a bogus address, which causes the UI to prevent edits to
the event (we can't upload without losing all of the attendee
information on the server). We also prevent the event from ever
being uploaded (belt & suspenders)
* If the user is an attendee, we allow changes to be uploaded
(this would be attendee status and free/busy), but the list of
attendees on the server is removed.
* We also mark events with redacted attendees, even though we don't
use that information currently. In a future version, however,
we could use this to indicate the redacted state to the user.
Bug: 2709816
Change-Id: I2b44af59c598cedf906af12bf9b4eaf7484b9d20
Merge commit '4c8adbc4aa81308e57ae129e9587ec50483af6a8' into kraken
* commit '4c8adbc4aa81308e57ae129e9587ec50483af6a8':
Fix bugs related to TZ handling for all-day events
Merge commit '027a6ddfaa7228854cb3c4238434f87fc69078b6' into froyo-plus-aosp
* commit '027a6ddfaa7228854cb3c4238434f87fc69078b6':
Fix bugs related to TZ handling for all-day events
* In bug 2703075, all-day events from time zones at GMT or later
appear a day early; this is because the time was calculated from
the GMT date/time of the event rather than the local date/time of
the event; this CL correctly changes this to use local date/time
* In bug 2707966, device-edited all-day events disappear in Outlook
and OWA after upsync; this is due to the fact that we store all-day
events in UTC on device, whereas we need to upload all-day events
using the original (local) time zone. In this CL, we save away
the original time zone and use it on upsync
* In our decoding of Exchange time zone information, we default to
local time when we can't find a time zone that matches the bias
and DST information; we should really default to a time zone with
the same bias, if one exists; we do that in this CL.
* Add/modify unit tests
Bug: 2703075
Change-Id: Id80c481ecc0eae980b2e91dae7f105f924cfca28
Merge commit '5c0f3b332f6104d6526d546a470cf7eb9978de47' into kraken
* commit '5c0f3b332f6104d6526d546a470cf7eb9978de47':
Fix problem w/ sync of large calendars (never syncs)
Merge commit '6bd7a167249727f4b7d4d4cfe713be421f400e51' into froyo-plus-aosp
* commit '6bd7a167249727f4b7d4d4cfe713be421f400e51':
Fix problem w/ sync of large calendars (never syncs)
* While working w/ Microsoft on this issue, we determined that Windows
Mobile 6.0 does not suffer from this issue; when we compared our
logs with those from the WM client, we noticed a difference in the
commands being sent to the server on initial sync (we send some extra
options whereas WM doesnot)
* As an experiment, I removed these options from the initial
sync, and this change solved the problem with a persistently unsyncable
account (time to receive: 60-70 seconds vs. > 240 seconds).
* The fix is to remove all "options" from the initial sync for a given
collection (i.e. with SyncKey=0)
* Note that Microsoft's documentation does not generally address the issue
of what should/should not be sent in an initial sync command
Bug: 2569162
Change-Id: Ib20ea56fb380ee8c9a01b139f7fa98b7ff505e7a
* While working w/ Microsoft on this issue, we determined that Windows
Mobile 6.0 does not suffer from this issue; when we compared our
logs with those from the WM client, we noticed a difference in the
commands being sent to the server on initial sync (we send some extra
options whereas WM doesnot)
* As an experiment, I removed these options from the initial
sync, and this change solved the problem with a persistently unsyncable
account (time to receive: 60-70 seconds vs. > 240 seconds).
* The fix is to remove all "options" from the initial sync for a given
collection (i.e. with SyncKey=0)
* Note that Microsoft's documentation does not generally address the issue
of what should/should not be sent in an initial sync command
Bug: 2569162
Change-Id: I69642cc0097296956029485abb85ac750303c865
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
- 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.
Change-Id: I48e5b89049338f7d4f1ac77cd7ac7243945a9575
* Microsoft has documented cases in which the server can continue to
send MoreAvailable=true even when no new data is received. This
can cause looping behavior, which we stop when we recognize it.
* This workaround, however, can prevent the situation from resolving
itself, and lead to delayed sync (up to a few hours has been noticed)
* In this limited CL, we allow the sync to loop up to a maximum number
of times before stopping it forcibly.
Bug: 2685984
Change-Id: I85981b85b71c4e7d53e69da2520543e8ef04c889
* Microsoft has documented cases in which the server can continue to
send MoreAvailable=true even when no new data is received. This
can cause looping behavior, which we stop when we recognize it.
* This workaround, however, can prevent the situation from resolving
itself, and lead to delayed sync (up to a few hours has been noticed)
* In this limited CL, we allow the sync to loop up to a maximum number
of times before stopping it forcibly.
Bug: 2685984
Change-Id: I2913b7e3438f6180c3c440508fab892176a06540
- Also, fixed a potential crash in getMessages().
It could happen when a client is gettign a message list while
another client is removing messages.
Change-Id: I04b1de6bc384cffb7a5286bcec0a349a3d62a623
Make the date parser accept invalid dates like
"Thu, 10 Dec 09 15:08:08 GMT-0700" which was observed in an email from eBay.
Per RFC, timezone must be either obs-zone (e.g. "GMT") or +/- with 4 digits.
The GMT+/-digits format is not permitted.
Bug 2367124
Change-Id: I59968274160aeadea70223208b463ee692660056
Follow up to I3bf7d340. Make sure temp directory is set before running tests.
Turned out Application.onCreate doesn't seem to be guaranteed to be run
before unit tests.
Without this, some tests may fail saying: "TempDirectory not set.
Application hasn't started??", if onCreate runs too late.
Change-Id: Ic5aee939a2c21f9579a643d0729dd0e9ba81022e
* Move all thread-related startup code into run()
* Move all thread-related shutdown code into new method shutdown()
* Add appropriate synchronization during startup/shutdown
* Add thread names to worker threads
Bug; 2645835
Change-Id: Idbd35892cea3de5fbd365102a62103b2f0bdf6c9
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.
Change-Id: If92dbfe681b78a0eea8125188ede63a8f00dcf49
Merge commit 'c7931b07e605bca3b59f295877fea7f163001a66' into kraken
* commit 'c7931b07e605bca3b59f295877fea7f163001a66':
Test for NPE in EasSyncService during alarm() call
Merge commit 'e0ebcd8e6c04fc3d39844722bce74abe540bfe3c' into froyo-plus-aosp
* commit 'e0ebcd8e6c04fc3d39844722bce74abe540bfe3c':
Test for NPE in EasSyncService during alarm() call
Merge commit '1a9ea35b93f29c589d3e31d70567f076b2bbb26b' into kraken
* commit '1a9ea35b93f29c589d3e31d70567f076b2bbb26b':
Try autodiscover with bare name if we get 401 with address
Merge commit '3778b3ed7ee505c00fa7cd3b1af37cbe54de244a' into froyo-plus-aosp
* commit '3778b3ed7ee505c00fa7cd3b1af37cbe54de244a':
Try autodiscover with bare name if we get 401 with address
* Some autodiscover servers appear to require the bare user name
for authentication rather than the user's email address. This
is apparently common for complex organizations maintaining a
group of email domains
* If we get a 401 when trying to connect to an autodiscover server
using the email address, we try again using just the bare name
Bug: 2682833
Change-Id: Ia07ca336e189069d4f3539e2245b3d53c82e3324
Merge commit 'd40977d14a355fc4d610f4fd8bcbb6196f5cfc96' into kraken
* commit 'd40977d14a355fc4d610f4fd8bcbb6196f5cfc96':
Server sending unsupported policies will cause NPE
Merge commit '8100a2dc5510d0449921895e2af8472d3666fda3' into froyo-plus-aosp
* commit '8100a2dc5510d0449921895e2af8472d3666fda3':
Server sending unsupported policies will cause NPE
- 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.
Change-Id: I3fde73ba5f1f9ff675fff07c510e1e49521dde42
Merge commit '3a07d70b69a579ef839faba3b85171b983bec312' into kraken
* commit '3a07d70b69a579ef839faba3b85171b983bec312':
Fix NPE resulting from attendees-only update from server
Merge commit 'a2496548c6ed07cb6cb3820c9922a0e96ca2b8a4' into kraken
* commit 'a2496548c6ed07cb6cb3820c9922a0e96ca2b8a4':
Start sync ASAP when calendar is re-enabled
Merge commit 'd1e00e8aa69ccad3de61ed638b70bf5a9e5bd937' into froyo-plus-aosp
* commit 'd1e00e8aa69ccad3de61ed638b70bf5a9e5bd937':
Fix NPE resulting from attendees-only update from server
Merge commit 'c901810f84754c80aa3988b26f5ff620373f9a46' into froyo-plus-aosp
* commit 'c901810f84754c80aa3988b26f5ff620373f9a46':
Start sync ASAP when calendar is re-enabled
* Code for updating attendees in CalendarProvider2 wasn't taking
an attendees-only update into consideration
* Fix code to allow for this, including proper updates for our
selfAttendeeStatus and attendees ExtendedProperty values
Bug: 2668682
Change-Id: I8c7deb971cd0b6846c09ee3cd603f6fc762a9407
* It turns out that, in addition to other requirements of the
CalendarProvider, there is another - that the ORIGINAL_INSTANCE_TIME
also be set with hour, minute, and second as zero (in UTC)
* Change setTimes() to properly modify ORIGINAL_INSTANCE_TIME
* Also, there was a regression due to an incorrect validity test
for events; this regression caused all exception downsyncs to fail
* Changed isValidEventValues() to be correct for both exceptions
and original events
* Update tests for setTimes and isValidEventValues()
* This CL also fixes 2658988
Bug: 2664229
Change-Id: I9c8aea08e606ff58e5be37ca81a2d86a181c46f6
Merge commit '630758ef898964814072467454bea615d31fc4ff' into kraken
* commit '630758ef898964814072467454bea615d31fc4ff':
Shut down Email process when sync is totally blocked
* When sync threads get blocked by SSL/Socket code, we detect this
and shutdown the ClientConnectionManager, hoping this will solve
the problem.
* Apparently, this doesn't always work. The result is that syncs
are frozen until the device is rebooted (certainly) or until the
Email process is stopped and restarted (hopefully)
* This CL kills the Email process after an unsuccessful attempt to
clear blocked threads using ClientConnectionManager.shutdown()
Bug: 2615293
Change-Id: I8445b278817e508a855adeb88d6b2f969d28858b
