* Provides GAL autocomplete in email address fields in message composition.
General TODO list:
UI: Implement divider in adapter, not in GAL provider
UI: Use listview_separator for divider
UI: Clean up strings, move all to resources
UI: Only have one GAL lookup in flight at any time
UI: Unit tests
GAL: Use side channel for status, not a row
GAL: Shorten timeout for interactive GAL lookup
GAL: Make watchdogs work
GAL: Figure out why some calls never return (conn pool exhaustion?)
GAL: Unit tests
Bug: 2249514
Change-Id: I513e25628bc2f5ed0920e0ee509cd598b1817b3a
- In memory attachments are now stored as byte[], not String.
We can store any type of contents now.
- Added blob content_bytes to the Attachment table.
The content field is now deprecated and not used.
- Explicitly convert ICS files to UTF-8.
- Added Utility.to/fromUtf8().
Bug 2509287
Change-Id: I3785a365a9a34039ec12ba82bd857dcdbc4de92d
* Upsync fails if we try to send more than one reminder time
* CalendarProvider allows an unlimited number of reminders
* If there are reminders, send the largest number (i.e. the earliest
reminder)
Bug: 2513106
Change-Id: I90a2fb145446e403edeabc654f725cc88ef1656e
* CalendarProvider does NOT delete exceptions for deleted Events
because the server handles this; this isn't right for Exchange
* Add a second delete operation to delete Exceptions
* Remember to cancel this second deletion for invalid events
Bug: 2512985
Change-Id: I848c8937945b3774251e517071c81a334a77f1a8
* When "Done" is pressed in AccountSetupOptions and the Account is
EAS, the finish() isn't called until an async method's callback
is invoked (system account creation)
* This allowed the user to execute onDone() multiple times, each
one of which would attempt to create an account
* The net effect was the referenced bug, which can manifest in a
number of ugly ways
* The fix is to prevent multiple calls to onDone()
Bug: 2501574
Change-Id: I61057bbb8c1f85da07e83ed6c56474bfe4e23f6c
* We needed to copy some more columns, and also copy reminders
and attendees to the Exception
* Also found a bug in which Description was referenced as a boolean
rather than a String
Bug: 2511405
Change-Id: I485b8d44a6090f8190e681838d2141551227d8f3
* We weren't sending out appropriate emails for exceptions and other
event updates
* Write exception specific ics file code in CalendarUtilities (in
the existing ics file creator)
* Send appropriate Update: subject for updated events/exceptions
* Compose simple message text consisting of:
When: <time>
Where: <location>
* Prepend message text for exceptions to indicate that the message
relates to a particular instance of the event:
This event has been canceled for: <date>
The details of this event have been changed for: <date>
* New strings were added in CL#44141
* Updated CalendarUtilities tests
Bug: 2501270
Change-Id: I920de8120bc56d5bd565cbde26ff4807be41579f
* Ignore CR and change LF into backslash + n
* Write unit test for handling of CRLF's
* Rename mLineCount to mColumnCount, which is more appropriate
Bug: 2508283
Change-Id: I8b2081aa474cb07b6cb09383ff6ac58a1dab1bba
* The bug is that we shut off sync of the adapter when a calendar is
disabled by the user.
* Instead, we should change the sync interval to never (and set it
back to push when the calendar is re-enabled)
Bug: 2507421
Change-Id: Ieb61e458a0372e40e402691fc4d20b1b85b3a664
I missed a case where message-id should not be set locally, which is
the case where the Mime parser clears all headers *and* does not find
a message-id. The parsed MimeMessage should accurately reflect this.
In the old code, the local id was created at construction time and then
immediately discarded by the parser (calling headers.clear()).
In the new code, I was generating a message-id any time I couldn't find
one. Now, when explicitly cleared or removed, I set a boolean to inhibit
automatic generation of a new one.
I also missed the fact that a missing message-id no longer throws an
exception, it simply returns null, and so I changed the code that was
catching that exception to simply check for null.
(Note: Clearly, modeling of legacy behavior is becoming annoying here;
It would be better to do away with all of the automatic logic, and simply
generate message-id locally when appropriate: On locally-generated
messages. I don't want to touch this for the current release, but I left
a note in the code to this effect.)
Bug: 2504774
Change-Id: Ibfcbd2363c7ae39ee6d44e4c3295f88258cb4945
Added DiscourseLogger, which stores last N (currently 64) lines of IMAP
commands sent to the server and responses received from the server.
We dump it to logcat when the IMAP parser crashes, that is, a) getting a
RuntimeException in ImapFolder.fetch() or b) getting a Runtime/IOException
in ImapResponseParser.
Bug 2480227
Change-Id: I6b5a728a7df106627ec29bb3c7c04a97a99b444b
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
Andrew Stadler