* 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
* VTIMEZONE blocks must be sent in our ics files for meeting
invitations that are recurring, as the originator's time zone
is critical in making attendee's calendars accurate
* Created a utility to convert TimeZone to VTIMEZONE data; the
utility successfully generates data (including recurrence rules)
for the entire tzinfo database (the source of TimeZone).
* Updated our ics files to include VTIMEZONE when appropriate and
send DTSTART/DTEND in local time in that case
* Wrote some unit tests, but more are needed
Change-Id: Iccbdd00cd3b2be2da058b344ebacd17ed6fb0e3d
* My Calendar observer registration code was storing the wrong id
in the hash map. Because of this, the code could be called again
and again, generating lots of extraneous queries and generally
creating a lot of havoc, including ANR's
Bug: 2450322
Change-Id: I03db8156ee99a0c7243a9188558dffc6a843a65a
We've observed that the secure.emailsrvr.com email server returns an excess
FETCH response for a UID FETCH command. Excess responses don't have the
UID field, even though we request, which led the response parser to crash.
This patch fixes it by making the parser ignore response lines that don't
have UID.
Bug: 2441065
Marc Blank