Message and MimeMessage were creating a lot of unnecessary sub-objects
even when not needed, so do a bunch of lazy initialization. This should
raise the bar on the size of gigantic inboxes giving us trouble.
* Specific optimizations:
* Replace date formatter with a shared static
* lazy create mHeader (ArrayList)
* lazy create mFlags (HashSet)
* optimize MimeHeader fields class
* lazy create local message-ID (expensive-to-make uuid String)
* make message-id string less expensive to create
* Other cleanups:
* add some override annotations
* privatize some members
* update a fragile test (not a deep fix, it's still fragile)
Side effect, should be faster too.
Bug: 2357564
Bug: 2093422
Change-Id: I8a873879d402e2662339d5398ad0b15da6e580e9
* Add new/changed id's to a list, and only clear the dirty flag for
list members
* The implementation is analogous to how deleted items are handled
Bug: 2492857
Change-Id: I3353100ab307a45a5ab684d402253eb589f22008
* Locally-deleted POP3 messages are handled properly
* Clean up remaining notes about attachments - code is complete
* Add explicit database close calls.
* Measures to prevent early exit or restart (e.g. by monkey):
* Disallow 'back' key
* Synchronize the main worker, and early exit if not first-and-only
* Fix flicker at end of conversion
Bug: 2065528
Change-Id: Id2990183624ff1f062285a13e29f983cbb1c5e1f
This test has been failing since I60974b85, which is obviously correct,
so I modified the test.
Bug 2488770
Change-Id: I5a2eea19d9f3c3647b7c88a1e0db9297727b8e66
* Split account copy loop to do POP3 accounts first, then IMAP
* After upgrading accounts, upgrade folders
* Upgrade messages in those folders
* Preserve attachments on outgoing messages (e.g. drafts)
* Enable composer and start syncing after upgrade
* Fix latent bug in LocalStore (which was not used in Eclair)
* Add tests for upgrade workers in LegacyConversions
Bug: 2065528
* We keep track of sync errors and have an increasing backoff for
failures.
* Make sure that a successful Ping (i.e. one that received a response
at the specified timeout) clears the sync error state for the
pinging mailbox
Change-Id: I35d188aa04618e7604bf6a7905e2ce6992ee3c54
* Only Outbox runs if background data is off
* Calendar/Contacts won't sync automatically if masterSyncAutomatically
is off
* Manual syncs will still operate as usual
Bug: 2099511
Change-Id: I07cd88394caffdd6f2ec475df405058c193116ef
* Apparently, the Exchange server can send event changes that have
incomplete data. This is not documented, and the result is very
bad in that an exception is thrown by CP2, and the sync (and
future syncs) is prevented from finishing
* Wrote some defensive code to detect bad events and simply not
add them
* Open a new bug to track trying to determine why the Exchange
server is sending this kind of data.
Bug: 2455341
Change-Id: Ibcfd412382164351c96f368dc043f38c7b481154
* There are cases in which an HTTP POST can hang indefinitely; this
will eventually be caught, but it could be a long time until this
happens (I've seen hours)
* Set a watchdog alarm for all HTTP POSTs (rather than just PING)
Bug: 2492860
Change-Id: Ifccbb54c191c4164bb3188e0291490276bce25fb
* Help prevent NPEs, especially during testing where the service
is constantly brought up and down
* Generally harden the code and make it clearer
Change-Id: If6c1c74d3fe9a89f67f71c9362a15bfecd70fa58
* Of all crazy things, Exchange 2003 doesn't like uploading the organizer's
email/name in changes. This isn't documented anywhere.
* Don't send up organizer name/email on changes.
Bug: 2492864
Change-Id: I1f2aefb6f9020025578325c5c7b3cf869f17e27f
* When a mailbox syncs, pings should be aborted, or they appear to
end up timing out with a stale connection (observation from logs)
* The result of timing out is lack of push until the heartbeat time
has elapsed and our alarm triggers
* Also refactor code; some of the names of methods was unfortunate
and these methods were being used in this CL
Bug: 2492848
Change-Id: Ib626a5d3cf6d2c61e3b11f4886a3fedbf9727bfa
* We weren't persisting the current heartbeat after the loop finishes,
so we'd end up starting next time with the default start heartbeat
* The new code is a bit more efficient, as we'd start the next pingLoop
with the heartbeat previously in effect
Bug: 2492854
Change-Id: I1d488e3eb05530c452605b25108b35af582e692f
* It turns out that Events don't store null for empty fields like location
and description, but rather an empty string.
* Exchange 2003 doesn't like seeing empty values, so check for this before
uploading.
Bug: 2490068
Change-Id: Ib208f9d6ec116a99adf798939dfbc4d4bdd15edf
* These logging statements haven't been useful in quite a while
* Leave them in the source, commented out, in case we want to
restore them
Change-Id: Ie8bc6497bc2ea3aa3437f9b2aec8c2b12af907bf
* Prune all folders, messages & attachments that won't migrate
* Clean up SSL/TLS values for better connection results & security
* Move account setup lookup code to AccountSettingsUtils to share it
* Cleanup config/auto-rotation settings to prevent relaunch of
auto-discover or account check (from exchange).
* A couple of other very small fixes
Bug: 2065528
If the account specified with an Intent doesn't exist, show the Welcome
activity instead, which will navigate the user to the appropriate activity.
(e.g. account list if there're more than one account)
Bug 2479609
* Included is a (nearly complete) VCALENDAR parser that is
used to verify the contents of the ics attachments we create
* Added a test for meeting invitation
* More to come (always)
Change-Id: I31eeac66eb635f443c85aacf56e67a943cc3d53b
* Unlike EmailProvider, CalendarProvider can return null from queries.
* Put checks for null around code using the result of query to
prevent NPE's
Change-Id: Ia9e8e2f44406dce07dcb2ffa40c22933ec2d4f07
* We needed to check that clientId wasn't null before sending it back
to the server
* Exceptions don't have a clientId
Bug: 2478711
Change-Id: Ic0d42bb699605a7bb77535b050a4d03b4b6b8b09
* We want an NPE to be thrown, since we need to locate/fix errors
of this kind.
* Add logging to help isolate the error
Change-Id: I0f4336b42cbdb88c72459bdeca9c9fc236d9299f