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
Merge commit 'ab4daabd5ec99da549407ce87d46e24be261c4a6' into kraken
* commit 'ab4daabd5ec99da549407ce87d46e24be261c4a6':
Add checks for Event validity before commit
* Enforce CalendarProvider2's requirements for valid Events
* Add unit tests for the new code
* Backport of change I42ad7acb from master
Bug: 2658149
Change-Id: I8151d035247a7dbb1fda3eae163b24ccfe055299
* Enforce CalendarProvider2's requirements for valid Events
* Add unit tests for the new code
Bug: 2658149
Change-Id: I42ad7acbcee3b6b831f805c59436017a32651f3a
Merge commit 'a094cc259da268ad6f78f50afe5cbbf674418b86' into kraken
* commit 'a094cc259da268ad6f78f50afe5cbbf674418b86':
Collectly preserve the service start-id.
* IMAP/POP rely on sender to set mime type of attachments
* Which doesn't always work, because senders don't always provide it
* Remap using filename extensions, when needed
* This is applied as late as possible - in the MessageView, and in
the content provider getType(). No changes to how we write databases,
and no change to existing attachment rows.
Bug: 2356638
Change-Id: Ie69e3fd12f406aac803583f9d1299a8af4fba010
Merge commit '01cc30c9d8327c6172036c1e15455d305423c718' into kraken
* commit '01cc30c9d8327c6172036c1e15455d305423c718':
Workaround for IllegalArgumentException in SyncManager
* There is a race condition in which the AccountManager listener
isn't properly unregistered when SyncManager is shut down
* In this case, SyncManager tries to register a new listener
(i.e. registering again), which causes an IllegalArgumentException
* The quick workaround is simply to catch and ignore this exception,
as it's really more of a warning than a true error
* A bug will be filed for the underlying issue
Bug: 2631561
Change-Id: I139d24ae045d402d4d8cb006406ef96ccc768566
Merge commit 'c9f923959eb7987db4f12dc7e2a1103e600d9eeb' into kraken
* commit 'c9f923959eb7987db4f12dc7e2a1103e600d9eeb':
Prevent account reconcile from running when service is down
Merge commit '4a1565fd7ec426ba4615aedeb3f2ddcb03ecac22' into kraken
* commit '4a1565fd7ec426ba4615aedeb3f2ddcb03ecac22':
Move a bare string to a resource.
* We were previously storing the user's attendee status in the
SYNC_ADAPTER_DATA column of the Event, but it turns out that
this data isn't available in the Entity we retrieve when
uploading changes to the server
* The result is that we often thought the user's status had
changed when in fact it had not; in these cases, we sent email
to the organizer, often with the wrong information.
* As of this CL, we store the user's attendee status in an
ExtendedProperties row (these values are already exposed in event
entities)
* The logic otherwise remains the same; we now get correct data,
however
Bug: 2638762
Change-Id: Ibe8db90c16b4ca06203f77fd010aa26dde89a556
Merge commit '220d9107535360b842f1a8ff872b2d22296d98b3' into kraken
* commit '220d9107535360b842f1a8ff872b2d22296d98b3':
Use timezone in exception ics files
* Exchange seems to require time zone information in ics files containing
event exceptions, although this is NOT the case for iCalendar, and appears
not to conform to VCALENDAR specifications
* This causes exceptions to be placed on the wrong date or perhaps even
ignored, depending on the circumstance
* This CL simply adds time zone information to all exception ics files
Bug: 2640878
Change-Id: Ibc614eb7a2c45e9e782b10be979d9892bbfc0029
* The regression is caused by a check on whether the calendar is
syncable, as determined by the status of the Calendar (via
CalendarProvider2).
* Unfortunately, if there IS no calendar, we were disallowing sync,
which prevents the calendar from being created in the first place
Bug: 2619755
Change-Id: I1e94a129413bdbe9bc9bfb3608d3ca95f23d8dfb
Merge commit '773dc43cc2caf7638c610ac85711eed89a06efa5' into kraken
* commit '773dc43cc2caf7638c610ac85711eed89a06efa5':
Allow more time for HttpPost watchdog timeout
Merge commit '8ed23be08f34ba11e5bf0acd98d1419df893a0bc' into kraken
* commit '8ed23be08f34ba11e5bf0acd98d1419df893a0bc':
Shutdown all connections when sync service is hung
Merge commit '78d3c6022ccf87566261faf694ff506a68ec6b6f' into kraken
* commit '78d3c6022ccf87566261faf694ff506a68ec6b6f':
Skip security check when account id is unknown.
* The current timeout is triggering more often than it should, which
causes delays and inefficiency. Increase it from 10 to 30 seconds.
Bug: 2615293
Change-Id: I54b74cc7ad9f1c8286af49b957584670c071640c
* When a sync thread receives an alarm due to a missed socket timeout
on an HttpPost, we try to abort the HttpPost.
* At times, however, the HttpPost cannot be aborted and the thread
hangs indefinitely.
* In this CL, we try to break this vicious cycle by shutting down our
ClientConnectionManager when this case is detected. This should, in
turn, close all of our socket connections, causing the sync threads
to generate IOExceptions and terminate.
* After appropriate IOException waits, new sync threads should then be
able to run normally.
Bug: 2615293
Change-Id: Idea6c3653cd60822d6260e0c5a7dad790ee25858
Doing the check caused:
IllegalArgumentException: Unknown URI content://com.android.email.provider/account/-1
at com.android.email.provider.EmailProvider.query(EmailProvider.java:1092)
at android.content.ContentProvider$Transport.query(ContentProvider.java:163)
at android.content.ContentResolver.query(ContentResolver.java:245)
at com.android.email.activity.MessageList.isSecurityHold(MessageList.java:1146)
Bug 2635060
Change-Id: I80e7c00ef2dd74ceae24a88daf43a0681124a9d4
* When SyncManager starts up, it reconciles the AccountManager sync settings
with its own
* This works for Contacts, but Calendar has a second setting that needs to be
checked - the sync_events column in the Calendar table (in CalendarProvider2)
* Before turning on Calendar sync, we now check this second setting; if
sync_events is 0, we won't re-enable Calendar sync
Bug: 2619755
Change-Id: Iea6c99dce228d2c111a529a6c9b865ed1577b19e
Merge commit 'd718abd38c12a902b85ba6341c4eda1c778d68b7' into kraken
* commit 'd718abd38c12a902b85ba6341c4eda1c778d68b7':
Increase service call timeout to 45 seconds
Merge commit '17733f228ec131900acd7e5ff883bb0150025c42' into kraken
* commit '17733f228ec131900acd7e5ff883bb0150025c42':
Fix upsync of DAILY rrule with UNTIL
* When a sync thread triggers an alarm by failing to return from
an HttpPost beyond the socket timeout, we call abort() on the
HttpPost to force it to stop
* It appears that there are cases in which this is insufficient,
and the thread remains hung in a blocked state
* The result of this failure is to prevent the syncing mailbox from
ever syncing again, and is typically seen by a failure to receive
new mail (as reported in the referenced bug)
* In this CL, we add code to wait for 10 seconds after calling the
abort() method. If the HttpPost is still hung, we interrupt() the
thread, and have SyncManager release the Mailbox, so that another
thread can be started.
Bug: 2615293
Change-Id: I6a48195fc68bb950126006326a5b30448d3bbb63
* Make sure we send UNTIL with FREQ=DAILY as appropriate
* Also to help debug this in the future...
Add logging capability to utilities via SyncManager
Add public log methods so that CalendarUtilities can log properly
Change Log.d's to SyncManager.log in CalendarUtilities
Bug: 2623787
Change-Id: I3d651f00a3f7522e25c8d6e389469770c733953f
* Change "broken pipe" behavior to simply run through the ping loop
again, rather than be treated as a NAT timeout
Bug: 2615293
Change-Id: I67c3200f148a8c2beda58f812c29af8a726a4b9c
Merge commit 'f1fa44bdc064a6c01813c5380839b90bd0290d46' into kraken
* commit 'f1fa44bdc064a6c01813c5380839b90bd0290d46':
Fix upload/download of attendee status
Merge commit 'b11ea045e994d80c49d0a80ca08582554a1c5823' into kraken
* commit 'b11ea045e994d80c49d0a80ca08582554a1c5823':
Add checks for null in SyncManager
Merge commit '819de68b01ec9f8d44e4fa1e16bf4900abf90b16' into kraken
* commit '819de68b01ec9f8d44e4fa1e16bf4900abf90b16':
Add additional test for likely NAT timeout
* When you have 2 or more accounts configured, MessageList gets confused.
* If you are viewing a mailbox from account A, and account B does a
background sync, MessageList gets confused by the reports coming back
from the Controller. It gives up and returns to the Accounts list.
* This change adds a check for the current account and ignores the
MessageList updates if we weren't actually waiting for them.
* To test the positive case for this code (make sure we didn't break it),
verify that the inbox on an IMAP account is displayed properly
immediately after you add it.
Bug: 2619513
Change-Id: Ib31254b4099ba6b7922b06d42e2b7928551e4fb2
* This prevents unnecessary delays in receiving push mail
* At present, there is a likely 5 minute delay on receiving new pushed
mail on the network displaying the behavior we're testing for
Bug: 2615293
Change-Id: Ic42e576fa683790f96434fcbad5ee873d0730f6d
* It turns out that the UI uses selfAttendeeStatus and the attendee's status
from the Attendees table in confusing and undocumented ways
* selfAttendeeStatus is used in the UI, but only in certain cases. Generally speaking,
the Attendees table status is definitive. However, when the user sets his status
from the UI, this data is reflected in the event's selfAttendeeStatus, since for EAS,
the user is always the owner of his calendar
* On downsync, we'll put the user's busy status into the Attendees table
* On upsync, we'll send busy status based on the user's attendee status in the
Attendees table
* We'll use selfAttendeeStatus only to determine whether the user has manually changed
his status via the UI (as before)
Bug: 2615586
Change-Id: I3a82474cfd07cbf5aa595e5214807cb55005cefa
Merge commit 'd764ce7e4442b0027a891582cbdd728487a49f97' into kraken
* commit 'd764ce7e4442b0027a891582cbdd728487a49f97':
Send correct busy status information in upsyncs to EAS
* Harden each of the major upgrade steps so any errors (e.g. NPE) are
caught and that account goes into error state.
* Make sure that any account in error state is abandoned properly - all
steps skipped except the final delete/cleanup.
* Bugfix: The variable that indicates that an account has gone into an
error state (upgrade failed) state was being set in the UI thread and
tested in the worker thread, so it was not properly stopping the
upgrade of any given account. Split that variable into two, one for the
UI thread (set/read by the handler) and one for the worker thread.
* Bugfix: Report errors against the correct account, when 2+ accounts are
being upgraded.
Bug: 2608483
Change-Id: I571078ae7123b601b53096104c4c5f4ef20da031
Merge commit '9c85a39b82d0691f3c057dc00dbab87a2b68452e' into kraken
* commit '9c85a39b82d0691f3c057dc00dbab87a2b68452e':
Fix NPE sending mail on servers without Outbox folders
* stopPing (in SyncManager) assumes that every mailbox has a serverId
but this is not the case on some servers, in which case we hit an
NPE during a check for the account mailbox
* Check for a null serverId when testing for the account mailbox
Bug: 2606385
Change-Id: Idfa8abd8ef9e2c0a2ac01d0b168a21c934f6fdf3
* The code assumed that if we asked for a remote wipe, that it would
be executed. This isn't the case, however, if we're not a device
admin at that time
* Test for Email app as device administrator before trying remote wipe
Bug: 2603931
Change-Id: I09dcff00e77bcf1e40c742c9dee923e6e07eecae
Merge commit '5e80b90e399b70c6dd93ddd7f5b66279277cf861' into kraken
* commit '5e80b90e399b70c6dd93ddd7f5b66279277cf861':
Use METHOD_ALERT instead of METHOD_DEFAULT for reminders
Merge commit '6d09bd247b0b5bf48a88bafc2ef28e25d0148bb7' into kraken
* commit '6d09bd247b0b5bf48a88bafc2ef28e25d0148bb7':
Speed up provision notification after security failure
* Exchange has been using METHOD_DEFAULT for reminders, but it turns out
that this doesn't work.
* Changed to use METHOD_ALERT
Bug: 2604156
Change-Id: Ia76bb2fc150202de9c49af9ab8caf86c9bda775f
Merge commit '401ae927e62a237f76c7dd1dde83f4ff8f27be91' into kraken
* commit '401ae927e62a237f76c7dd1dde83f4ff8f27be91':
Store all day events w/ UTC timezone
* All day events are supposed to be stored w/ UTC as the time zone
* We already zero out hour, minute, and day
* Use DTEND for non-recurring and DURATION for recurring all day events
Bug: 2440161
Change-Id: I31f2e5a355b721c06b4022b57ccc8a29b288a5d9
Merge commit '825999f815979519d8d80334a8c1ce0223a89ef2' into kraken
* commit '825999f815979519d8d80334a8c1ce0223a89ef2':
Set selfAttendeeStatus and busyStatus properly on downsync/upsync
* Set selfAttendeeStatus on download from busy status
* Set busyStatus on upload from selfAttendeeStatus
Bug: 2587076
Change-Id: I34eaa0d3861bcec0cbfd51761b31965e44f5162b
* Previously I added a call to updateBanner() during the sequence where
we update the mailboxlist (searching for the requested mailbox to
display.) This was an attempt to provide some error information
for certain corner case security configuration problems.
* This was misfiring during legitimate connections (specifically, initial
sync of valid EAS accounts) and causing a Connection Error message
when none was intended.
* Rather than continue hacking, I'm simply removing the error banner
from updateMailboxList.
* This is essentially a direct rollback of change
c98b64c801, although I've added
a bit more commentary than there was originally.
* The long-term solution, rather than continue band-aiding this, is to
move most of this logic into a service independent of the UI, and
provide more organized error reporting.
Bug: 2585159
Bug: 2599377
Change-Id: I99b7b1c8a7cfaa3fd3ff9b578d5721f05133d88a
Merge commit 'b8ef8a2c1d18421a7d537dbc8d1ea88ffca95898' into kraken
* commit 'b8ef8a2c1d18421a7d537dbc8d1ea88ffca95898':
Properly decode a uid from the globalObjId in invites
* Meeting invitations in EAS include a globalObjId. It turns out
that this id is EITHER the actual uid (if Exchange created it)
or a wrapper for the actual uid (if some other client created it)
* To find out which case we're dealing with, we have to look at
the base64 decoded string for the magic "vCal-Uid" substring
* If it's there, we pull the real uid out of the decoded string
* Otherwise, we build a hex strong from the decoded bytes
* Write unit test for this process
Bug: 2598201
Change-Id: I1cc40af6d1e45be44c19465eb8a4c31851ec8157
Merge commit '1bf66bb8fcb4fcb74706d8e0917b7ac9f62d6710' into kraken
* commit '1bf66bb8fcb4fcb74706d8e0917b7ac9f62d6710':
Cleanup probable causes of close cursor access
* Monkey is hitting this fairly often
* Multiple fixes that are all good
* We were launching LoadAccountsTask twice
* Don't use a managed cursor for the inner accounts cursor - always
close it manually by calling changeCursor(null) and letting the
MergeCursor handle its sub-cursors.
* Add isCancelled() check
* When replacing adapter, be sure to close cursor
Bug: 2524465
Change-Id: I2309e033d65430810f2856285c1fa9bf2f8fb5e3
Merge commit 'a55d27bae112429348090be7fa262d7acc1b69e8' into kraken
* commit 'a55d27bae112429348090be7fa262d7acc1b69e8':
Run the account reconciler every time we start SyncManager
Merge commit 'ad383ff1231319c6ded4077b0d1415bf77bec70b' into kraken
* commit 'ad383ff1231319c6ded4077b0d1415bf77bec70b':
Use consistent device-id even the device is wiped.
* This takes care of *some* of the race conditions where the
account DB is blown away but the Email app is not running, so we
don't get any notification of a change; We have to try and
sort this out early.
* SyncManager is started by Welcome, so this catches many cases of
entering the email app.
Bug: 2567986
Change-Id: I76bea5b636802ba5c1677d8b1825fb3c61f7b2d9
* When account disappears (e.g. delete from Accounts & Sync) the Welcome
activity should launch with FLAG_ACTIVITY_CLEAR_TOP to remove any
stacked activities as well.
* When account disappears entering AccountSetupNames, don't fall out
of Eas Flow Mode.
* Followup to 5e354cd1db
Bug: 2563998
Change-Id: Ifbe086e26205bb28c2514f84cb28e839888b1eb0
The error handling for (mAccount == null) would crash. Use a simpler
path here and just abandon the setup process.
The root cause of this (the account being null) is probably solved
by 3ae84b247d, but still a good idea to
clean this up.
Bug: 2558344
Change-Id: I3167234f99e9d39844f2b56a4d94f25465c7c269
Merge commit '8dffa087db44e27e5f0e5672b19fdb6975e614a7' into kraken
* commit '8dffa087db44e27e5f0e5672b19fdb6975e614a7':
Change account colors to what aren't used in Calendar.
Merge commit 'dc283b1b399da1543d57b8eae8ffcbc72f1deca0' into kraken
* commit 'dc283b1b399da1543d57b8eae8ffcbc72f1deca0':
Exit most activities when accounts are deleted
Merge commit 'f9890942bc4a61d14d65f38a16a8bb53bc979880' into kraken
* commit 'f9890942bc4a61d14d65f38a16a8bb53bc979880':
Final cleanup for account provisioning failures
Merge commit '595ebcebfaf937434dd797f0423819dae147b0d6' into kraken
* commit '595ebcebfaf937434dd797f0423819dae147b0d6':
Only set ORIGINAL_INSTANCE_TIME in exceptions
This resolves cases like this: You are in the inbox of an Exchange
account. You click home, settings, accounts & sync, and you delete
the account. Now re-enter the Email app. You'll be left in a strangely
empty inbox, for an account that no longer exists.
* Set a flag any time the reconciler deletes an account
* Check that flag in onResume of any activity that depends on the account
list and could be left in an "empty" state if account(s) are deleted.
* The Activities in which we check it are:
* AccountFolderList
* AccountSettings
* MailboxList
* MessageCompose
* MessageList
* MessageView
* Clear the flag any time we come in through Welcome, which will dispatch
to other activities properly based on the number of accounts found.
Bug: 2563998
Change-Id: I00fc542581c2bed92d744a4c2e48a88f83737f11
* We were setting this for all events, but apparently CalendarProvider
does not approve, and generates warnings
* Only set this for exceptions
Bug: 2550631
Change-Id: I8a7152eb0d4233432b1a5b5664da964d5433fbae
* Now that we get proper callbacks on updateMailboxListCallback(),
show the error banner if there's a problem
* Follow-on to 63186a5442
Bug: 2585159
Change-Id: I2b4f365d02b639bc3ceff9f8938333185d5ba693
Merge commit '58f7daac64a105f0607bf0cf64dba9d2ad523b31' into kraken
* commit '58f7daac64a105f0607bf0cf64dba9d2ad523b31':
Try a longer timeout for initial sync
* It turns out that this bug is due to a bad rebase/merge for a previous CL
in which the changed code appears in its new form AND old form
* Fixes change SHA c3aa318200 (CL 48406)
* Don't say it.
Bug: 2587775
Change-Id: I3f70a97e498db30345452b942909448049680fdf
* We are still seeing an issue with at least one user on initial
calendar sync.
* Increase the read timeout a great deal for initial sync, as it
can a very long time for the server to respond
Bug: 2569162
Change-Id: I495c38dc58d9a80c5a21e40b6fc5d165d10a3c1a
Merge commit '772758177e3dd4fcb1c9d534afec3007b59c8bf7' into kraken
* commit '772758177e3dd4fcb1c9d534afec3007b59c8bf7':
Show device id on the exchange setting screen.
I've attached a screenshot on the referenced bug.
Also fixed a bug in SyncManager.getDeviceId() where sDeviceId cache wasn't
working.
Bug 2591124
Change-Id: I4b58517c095a96d47fb57179d70091b2c7af5249
* We weren't sending a proper ics file for the deleted attendee, and
this caused Exchange to send a message to the wrong people (the
referenced bug)
* Split out code that adds attendees to outgoing mail
* Changed the optional last argument to createMessageForX to be a specified
attendee, i.e. the only addressee to be used for the message
Bug: 2548465
Change-Id: I629fcfaffe621408ea460d42c9c7c283929f7e79
* SecurityPolicy: Fix bug that prevents any notifications after the
user hits "cancel all" from the notification pane.
* AccountSecurity: If the user cancels the device admin acceptance
activity, repost the notification.
* MesageList: Catch security hold condition when entering a mailbox, and
launch security setup activity.
Bug: 2585159
Change-Id: I60d5d8c693cc5f00fe98a9cc69265802f5bee813
Merge commit '9edec6478cbb3cd3720077acfaaa950160eea128' into kraken
* commit '9edec6478cbb3cd3720077acfaaa950160eea128':
Always check serverId AND calendarId in queries
* With multiple accounts, serverId's are not guaranteed to be unique
(indeed, they rarely are)
* There were two queries in CalendarSyncAdapter that checked only
serverId and this has caused the referenced bug PLUS others that
would have turned up later on
* This is a critical fix
Bug: 2589815
Change-Id: I49bc6cb5bb4708f4bf4ca60a891ff78f0b25e989
* We weren't sending up the event description with exceptions, so
changes to description were being lost on upload
* Move the code uploading description so that it happens with
exceptions as well as top-level events
Bug: 2590020
Change-Id: Ifab556bed68671f3ee8cab02b657adbd8ba9c50c
* It's reported that 50% of third party users have issues syncing
Calendar in Exchange
* In testing, it was determined that the server takes > 30 seconds
to respond to a sync request initially, which is beyond our timeout
limit
* Also, I found that the system SyncManager was trying to trigger an
upload sync at the same time (i.e. before the sync session was
established with the server)
* There are four changes here:
1) Prevent upload syncs while the sync key is null or "0" ("0"
is the initial state)
2) Increase timeout for connection; at worst, this will
cause a short extra delay in syncs with a bad connection, but this
will be unnoticable to users
3) Increase the read timeout for initial sync to twice that of
regular syncs (the initial sync always seems to take longer)
3) Reduce the lookback for calendar to two weeks (from one month);
this is a better default anyway, and it probably reduces the server
and client load a great deal
* Empirically, this solves the bug for a known completely repeatable
case.
Bug: 2569162
Change-Id: I36b1c3e1e0b65f50d42e05f1830fed912191651f
Merge commit 'b0690302bfc486ae76002179de11df0537090c30' into kraken
* commit 'b0690302bfc486ae76002179de11df0537090c30':
Set CLEAR_WHEN_TASK_RESET flag when launching Calendar
and Contacts, so that when you relaunch Email from Home, you always see
the Email app, not Calendar/Contacts.
Note as stated in the corresponding bug, this CL itself won't fix the issue,
because CLEAR_WHEN_TASK_RESET will be lost when Contacts/Calendar apps handle
the intent.
There's a feature request against the framework (bug 2586404) which should fix
this losing flag problem.
Bug 2584792
Change-Id: I34ac3707b99926fc07529ea2229f2a6b3c4f93e4
Merge commit 'ef01261a8909ea3fe3e40b06cc537e0032d47898' into kraken
* commit 'ef01261a8909ea3fe3e40b06cc537e0032d47898':
Try TOP even on POP servers that fail to report CAPA
* Ignore the results of CAPA and always try TOP
* If TOP returns -ERR simply fall back to (bad old slow) RETR
* Unit tests for positive & failure cases
Bug: 2588432
Change-Id: Ife4b551217de1025e14efc46074f16ef4ae99c6f
Merge commit 'dc0f9ee7ed36947414b37bb8d303f6ca0b768a8a' into kraken
* commit 'dc0f9ee7ed36947414b37bb8d303f6ca0b768a8a':
Always add changed exceptions to the upload list
* We were adding deleted exceptions to the "deleted" list; this is bad,
because the exception then gets deleted from the database after the
sync. The symptom is that the deleted exception reappears on the
calendar.
Bug: 2587837
Change-Id: If497f82ba0b2b817d1cef6165ded23d19876528f
Merge commit '605433f78dfacc6c634c6313832c9e1f475bcd99' into kraken
* commit '605433f78dfacc6c634c6313832c9e1f475bcd99':
Only allow the account mailbox to attempt provisioning
Merge commit '6155bc2b10316b5257692b2e4c540c24f5f49836' into kraken
* commit '6155bc2b10316b5257692b2e4c540c24f5f49836':
Fix upload of multi-day all day events
* We were allowing all sync services to attempt provisioning, but this
could potentially lead to a race condition in which two different
policy keys are created on the server (this is speculative)
* Change to allow only the account mailbox to attempt provisioning
* Log policy keys when verbose exchange logging is enabled
* We'll see if this solves the referenced bug
Bug: 2569162
Change-Id: I36c60098a4866882a8f9f4c288da54ea378d9aee
* We were assuming a single day for all-day events
* Use the actual end date
* Make sure we send date/time back to server in local TZ
* Also fixes#2500863
Bug: 2578776
Change-Id: I58767a574248935b9840ce93e634a24e54abe62f
* We need to send name & email for Exchange 2007
* For Exchange 2003, only name & email if the event is new
Bug: 2586661
Change-Id: Ia35c2c7a645a3d20b7031e9a43b8b5044a40f005
Merge commit '13cc00239e958647312b26deae7e62e3c4b27fdf' into kraken
* commit '13cc00239e958647312b26deae7e62e3c4b27fdf':
Send meeting status with all upsynced changes
Merge commit '6445efb6497348f4fc0b2c7ca5c78634626dfa3f' into kraken
* commit '6445efb6497348f4fc0b2c7ca5c78634626dfa3f':
Check for active device admin before each ping loop
Merge commit '7ac1a975c470f1a41e589e2a223467bf564fafc9' into kraken
* commit '7ac1a975c470f1a41e589e2a223467bf564fafc9':
Add organizer to Attendees before handling exceptions
* Meeting status differentiates between appointments and meetings,
which is important in Outlook and OWA
* Fix older, completely incorrect code for upsyncing categories
Bug: 2586071
Change-Id: I277252ef2c31e5b8ec7ceda69c229f5fd100ecdb
* Accounts that require security need to check that the Email app
is still an active device admin from time to time
* Add a check for this before each run of the ping loop
Bug: 2583282
Change-Id: I1491821b7d0c1a341b1fe7ef1002c8b21aed12c2
* Exceptions take a copy of Attendees when they are created, but
we weren't adding the organizer to Attendees before exceptions
were parsed
* Fix this by adding the organizer just before exception parsing
* If there aren't any exceptions, we add the organizer as before
Bug: 2585817
Change-Id: Ie894682977e38a55d975135c8fc2fd8f2d4b1365
* First, make sure we catch the cases of DELETED=1 and eventStatus=cancelled
* Second, only send email updates if the user is the organizer
Bug: 2583054
Change-Id: I886efa0f28931dc815bc31d4d6adb3d700f83c6b
Merge commit 'ce3aabde3a590345e2e6f29d419455432966c643' into kraken
* commit 'ce3aabde3a590345e2e6f29d419455432966c643':
Fix GAL lookup for provisioned EAS accounts
Merge commit '8ee5858cb820dec68a4c266cdeb46172654901a3' into kraken
* commit '8ee5858cb820dec68a4c266cdeb46172654901a3':
Fix auto-send of invites when attendee status changes
* Use AS_SYNC_ADAPTER flag when changing attendee information in
downsyncs
* Allow DTSTAMP to come before new attendee information in the case
in which only attendees are changing
* Add _SYNC_DATA of "0" for all newly synced events
Bug: 2582513
Change-Id: Iacde0ddf3f2a99d108e00ef1991edfc34613f5c7
It's unfortunate but some of the fields we cleared in I34451000 are accessed
in BG threads or after the activity is destroyed. We could add != null checks
everywhere, but it'll be a mess. I also think it's safer to simply remove
the "= null" lines.
On the other hand, clearing AsyncTasks are relatively safer because they are
kept only so that we can cancel them afterwards, so I kept them. But let me
know if you want to revert the original CL.
Bug 2570603
Change-Id: I04a10dd7382bfcceb686c3e9af92f8949caf619e
* Write MIME-Version: 1.0 in all outbound messages, not just those
with multiparts. This is required by RFC 2045.
* Unit tests
Bug: 1678296
Change-Id: Icf37d93b8b0150f490791792499865a60744adea
* Handle the case in which a Mailbox to be synced doesn't have
a serverId (rare case which happened to a Zimbra user)
* Tweak logging to improve debugability of similar issues
Bug: 2551196
Change-Id: Id61cee5c4b33eb2f87455fbae0899fec8ff3748f
Merge commit '59cf1d05c111e3b5fb18417db41ce47b623b5b1e' into kraken
* commit '59cf1d05c111e3b5fb18417db41ce47b623b5b1e':
Clear references to inner classes in onDestroy().
Merge commit 'c94c077a668fe3eb78dfeec797a175571a47b1c6' into kraken
* commit 'c94c077a668fe3eb78dfeec797a175571a47b1c6':
Send busy_status = 2 on all upsync's
* Right now, we only send this for 2.5 (where it's required)
* If we don't send this for 12.0 and later, the status will be
set to "free", which is almost always going to be wrong
* So always send busy status = 2 (we can't know differently, as
we don't track free/busy)
Bug: 2575611
Change-Id: I11d952b68ac0ef7a022b030037ce6408f72d4a90
Merge commit 'be4287970b4218bbcd01955677117110eb1d1d03' into kraken
* commit 'be4287970b4218bbcd01955677117110eb1d1d03':
Show a less-generic error message for security errors
* Simplify the logic in the onDisabled() receiver. Make sure
security policy keys are *always* disabled.
* Eliminate unused variable and unused receiver.
Bug: 2576145
Change-Id: I3665a1d300edfb77e02737c08aee22bc977f4968
It's a preliminary change for IMAP bug fixes.
Also,
- Fixed a potential bug in ImapFolder.setFlags where it'd throw
StringIndexOutOfBoundsException if flags is empty.
- Added a generic flag to proguard.flags so that now all methods with
the "ForTest" sufix are automatically preserved.
Turned out it wasn't needed for this CL, but it should come in handy
someday.
Bug 2538076
Change-Id: I49a08afc196c7b7f1f30477dfc38ac5381045d84
When receiving the EHLO response from the SMTP server, the multiline
answer has "-" prefix in all lines except the last line, where the
prefix is a blank. This is according to RFC 2821 section 4.2.1. This has
also been reported as issue 2309 at code.google.com.
Bug: 1744768
Change-Id: I3feccabed30767d2fa5b06352cd7d1c803e8d59c
* Track whether the user clicked "manual" vs. clicking next (and falling
into "manual" because the account is not found in the providers list.
Convert this into an "allowAutoDiscover" parameter.
* Pass "allowAutoDiscover" down into AccountSetupAccountType and through
into AccountSetupExchange. (Note, it's unused/ignored for POP & IMAP
accounts and should not affect them.)
* In AccountSetupExchange, use the existing EXTRA_DISABLE_AUTO_DISCOVER
(previously only for testing) to suppress autodiscover in manual mode.
Bug: 2570919
Change-Id: I2583e00d1e6cc26bbd4b85134eddae8cc3a1f91e
* Split out network operations w/ timeout and watchdog from send HttpClientPost
* Use this in autodiscover calls
* Add logging to help debug this issue, in case there are additional problems
Bug: 2568077
Change-Id: I2a2e1abca2c4dab02c8e04c304f67db2a7b4cb22
* In Controller, map EmailServiceStatus.SECURITY_FAILURE
to MessagingException.SECURITY_POLICIES_REQUIRED
* In MessageList, map MessagingException.SECURITY_POLICIES_REQUIRED
to string account_setup_failed_security
Bug report will be forwarded to next release to get a more specific
string with proper translation.
Bug: 2563988
Change-Id: Ia1e6e947e3c0c7e6bd37301de2ea8ef4d641ef14
* If the server asks for more than we can support, don't throw
and error from PolicySet creation. Let isSupported() do that.
* Overlong password lengths cannot be supported and isSupported is false.
* Overlong timeouts & max wipes can be reduced to supported
amount (this actually increases security) and isSupported is true.
* Clean up an obsolete comment
* Unit tests
Bug: 2567804
Change-Id: I2d664a7f2a315b9f9bdcb867fe2cd98f74de6f66
* When the sync state of Calendar/Contacts is changed, a number of observer calls
are triggered. In addition, we might have a running sync.
* The syncKey operations need to be synchronized, because we may otherwise
inadvertently use stale data when syncing, which would cause symptoms
as seen in the referenced bug
Bug: 2561864
Change-Id: I03db58fe01c45778d271fad34d8d4940edefe8fe
* resetVisibleLimits can be called via BootReceiver, which isn't in the
Email app process, so it can (and apparently did) get a RemoteException
* This causes the query to return null; we have to check for it or we
get this NPE
Bug: 2564904
Change-Id: I4b75e3c74ac7d1276f609f2fc957afdaa8da2f64
* Turns out that most other clients omit this.
* This has the pleasing effect of fixing the referenced bug
* Update unit tests
Bug: 2561821
Change-Id: I39f7db7e05be590373cd5f3d9b23c7ee21bde4f7
* We were queueing up emails during our upsync, but before the upsync
was complete. If there were connection issues, we could pile up
multiple copies of the same message, each of which would eventually
get sent out
* Fix is to simply queue up the outgoing mail and send it all after
the sync operation is complete.
Bug: 2515975
Change-Id: Ide3eb2deb6e959d0637d28efabd613efb3c6e209
* Because we were sending these in the wrong format, upsynced changes
were failing, with the result that both the original event and
the "new" event (from the UNTIL date forward) remained in the calendar
* Fix is to send the proper format; unit test updated to reflect the
change
* Also, we only send the date of an UNTIL, rather than the to-the-minute
time; it turns out that EAS expects to see only a day for UNTIL.
Bug: 2561818
Change-Id: Ic4eacbe96c713d58c637386ceab2cf22ebe3c2d4
* We need to send date only (without time) in the VCALENDAR file for
all-day events
* Add unit test for this case
Bug: 2561789
Change-Id: I33a43c7a248059c97482ca147a23af083744118a
* Always send up something when upsyncing photo and note
fields
* This allows the client to delete the data, as these fields
are NOT deleted if skipped in an upsync (unlike other
fields)
Bug: 2558998
Change-Id: I9c874432108eedd84a351918f818c32e6e579dd7
* We should be sending CANCEL as the method with cancellations
* Fix this and update unit test
Bug: 2527606
Change-Id: I2b982e4bfd1dbc57660cf578702edf49584d2957
* We now check that the user has verbose debug logging on
before spamming with serializer logging
Bug: 2561834
Change-Id: I5eda2ca5f16cde728b0febaa990d66fc99bb93a0
* Now that observer code has been moved to worker threads, the order
in which various pieces of account creation are executed has become
indeterminate
* Because of this, our EasAccountsUpdatedListener could use a stale
list of EmailProvider accounts when performing reconciliation with
the AccountManager's list of accounts
* The fix is to ensure that EasAccountsUpdatedListener's worker thread
causes the cached EmailProvider account list to be updated before
calling the reconciliation method
Bug: 2558317
Change-Id: Ia94a8301845cf6c06f8efecd408eb237474f781a
- make EntityIterator extend Iterator and thus not throw a
RemoteException, instead converting it into a RuntimeException.
- rename ActiveSyncInfo to SyncInfo
- change getActiveSync to getCurrentSync
- remove the accessors in SyncInfo and instead make the final
fields publicly accessible
Change-Id: Id1a47bba27042de4c21451a91cc43fa70eb68ec6
http://b/issue?id=2553539http://b/issue?id=2553541
* Clean up some code related to connectivity locks and sync holds
* Add logging related to sync holds after we re-establish connectivity
Bug: 2551482
Change-Id: I1b1f03cc1428e25be90c5e60555adf9ab1bf3ab9
* Had to add an optional argument to the email creator for this case,
since there may not be any remaining addressees to send to (if the
only guest was uninvited)
* The optional argument forces the creation of a message, even if there
are no addressees
Bug: 2548465
Change-Id: I88784f49ce7afedce331fc756c5ecef4e73a07bc
* We were starting a sync if there was a dirty event in ANY of
our Exchange accounts
* Change to check for the specific account before syncing; this
saves provider queries and service (i.e. thread) startups
Bug: 2550620
Change-Id: I83e953f1bade9fa269b777e96121a63664e8edc8
* There's an NPE if we downsync a contact containing a piece of
typed data for which there is no type specified in the database
* Check for this and accept "no type" as a match
Bug: 2539843
Change-Id: I155b635a1f9850af9813681f502f3565c3cfcd4b
* The recent change that moves our account change handling out of the
UI thread caused ConcurrentModificationException's during account
creation
* We now synchronize all access to our cached account list to prevent
this
Bug: 2546724
Change-Id: I92b2becedd36a335a81f7e3bd9617f2923e00e6c
* Prior fix used the wrong column when adding time zone information
to downloaded exceptions
Bug: 2548436
Change-Id: Idc1001fd58d2fba51823624a15862fe439c9ff6a
* We weren't checking calendar id along with original event id when
uploading (original event id isn't unique)
* Fix the query selection to ensure finding the correct exception(s)
Bug: 2545659
Change-Id: I276dd10e2be171bd9d4f3300cdc8843bb28f2781
A desktop shortcut to an account created on donut or before points at
com.android.email/.activity.FolderMessageList, which we've already removed.
- Added a dummy FolderMessageList to receive it and redirect to MessageList.
- Removed FolderMessageListUnitTests, which was left unremoved.
Bug 2535335
Change-Id: Ie5ffa158882633a4929c4c47a3d9625fd1626863
* Use one minute before/after for transition checking, instead of the
sloppier early version
* Add tests for additional known time zones
* Change most methods in CalendarUtilities to package private (for use
with unit tests)
* Clean up a little bad formatting
Change-Id: I9e5be5e1c859f2294adf06874459f7db15fb8c22
* EAS 2.5 doesn't like seeing bare LF's in Calendar location
and description, and Events including them won't sync back to
the server
* Create a utility to replace bare LF's with CRLF and write
unit test for the utility
* Fix the bug by using this utility
Bug: 2542220
Change-Id: I2c72d23f15e3a922ebe3585e063abe9fa9e2366f
* AccountObservers do a fair amount of database access, and all of
this should be done in a background thread, so we'll move it there
Bug: 2545753
Change-Id: I5a38677213a923d44eadade75ae32e151e9100da
* Calendar observer code does database access (sometimes quite a
lot), so it shouldn't be run in the UI thread
Change-Id: Ib6ec5ac3105df6d3fc45004dc2b09be4e33a11ac
* Fix the transition times so that they occur at the hour
* Remove an unused variable
* Fix a reference to Calendar.HOUR that should have been
Calendar.HOUR_OF_DAY
* Confirm that unit tests work properly
Change-Id: I3eaf31d160e97b5f3ba59c83878359085aea960d
* Remove some very old code that updated the Account in the database
when finishing an EAS FolderSync. The old code saved away the entire
Account structure using getContentValues(), which has long been recognized
as dangerous, since the data being saved might be stale.
* In this case, we were clearing the INCOMPLETE flag in another thread, but
FolderSync was saving away the old value (with INCOMPLETE set) along with
all of the other columns.
* Ironically, the old code is entirely obsolete, so the solution is to
simply remove the update call.
Bug: 2501574
Change-Id: I9eccbde40e05c83ec5f0ab1d3387289286acc5f3
* Previously, we would send "0", which is just wrong. Better to
send nothing
* Make sure that all tests pass
Bug: 2531679
Change-Id: I01412c6c6f7a2570fafadede75671012b917d25b
* Previously, we handled the error case for security related errors
* Add code to fail on ANY error, and in particular to recognize the
error in which an OWA server address is used instead of an EAS
server address
Bug: 2494110
Change-Id: Iab7df56e82f5ff73b1f58d386ec6f844db26a312
There are a few places where we don't do the check in restoreMailboxWithId,
but they don't look trivial enough for me to fix.
Bug 2530534
Change-Id: I77b37a87ef108048077f14c1e8a3457ee494100a
* Properly parse the server's supported versions
* Choose the highest server version that we support
* Fail with MessagingException if we don't support any server
versions
Bug: 2527408
Change-Id: I0a2822c8fab31a65c8fea9b78b4a8c23df1804a3
* We were sending cancellations with a request for reply, which is
incorrect
* Send the correct dats in the ics attachment
* Update unit test to reflect this
Bug: 2527606
Change-Id: I4cea0bb8f1c29a3cad8d09fd6a4750f7ab067229
* An ANR was reported in MailboxAlarmReceiver
* The reciever calls into SyncManager, which does some database
operations, and may abort an I/O operation in a sync service
thread
* Move this potentially long-running code into a background
thread
Bug: 2215045
Change-Id: Id65c51f706b212d6b50af3921f3ba3dc2d014ce0
* There was a TODO for this... :-)
* First, I added some logging to help debug this kind of situation
in the future
* I also now forcibly stop any ongoing sync of the calendar being
disabled; this appears related to the problem of Events not
reappearing
* Added a kick() after the calendar is re-enabled to make sure it
starts resyncing immediately.
Bug: 2526924
Change-Id: Ib18f4c3c4e016f5cb5205fea5f3f12c0782b5e54
* Add "vibrate when silent" choice in UI
* Add storage for it in Email's provider. Existing accounts default to
their current settings (always vibrate / never vibrate).
* Respect new mode when notifications are posted
* Updated existing unit tests
Bug: 2457183
Change-Id: I5c933ac39dbef8b2028255f330e0b084a445421a
* We now keep track of attendees in the Event's extended properties
* When a message is updated, we compare current attendees with the
original list, and send cancellations to those who have been removed
Bug: 25623726
Change-Id: I7b3df99e62fb3d4a1482bd6d4612647f5bdb756a
* Yahoo! is not supporting search by UID so I can't identify the new
the UID after I upload. This inability to correlate the local and
remote messages means that we wind up syncing the same message back
down, in a loop, which spawns more messages.
* Yahoo! has partial support for UIDPLUS, and reports the new UID when
I append (upload) messages.
* Modify IMAP parser to parse response lists
* When APPENDUID is reported, use it (and skip the search)
* Modify the few other existing users of response lists to use the
parsed versions instead. Provided a couple of lightweight utilities
to make it easier to work with ImapList.
* Unit tests for most of it.
* Optimization: share a static date/time parser for all IMAP connections
Bug: 2448220
Change-Id: Ic10fc1a195ccf4671a498188cc8b17848c8d9df7
* There are serious issues with showing consistent and accurate attendee
status for Exchange 2007 events
* Unless and until these can be resolved, it is better to simply not show
the user the supposed attendee status (since it might well be wrong)
* In this CL, I never set the attendee status; therefore, it will appear
"unknown" and be shown simply as "Guest" when viewing the Event in the
Calendar app.
* Will create tracking bug for this, so that we can revisit for a later
release.
Bug: 2524410
Change-Id: I97fdd26750c68ff25bbb102547071c728e4124a9
* Most clients send name= in the content-type, but a few clients
send only filename= in content-disposition.
* There was code to handle both cases, but due to two typos, it didn't
work.
* Most easily reproduced by sending from hotmail/live web client.
Bug: 2366961
Change-Id: I1d9a00b9b5fd1094cfb8566c3248d94286a8ae91
* Quick fix for the bug that notifications may be stale after
and account is deleted.
Bug: 2202317
Change-Id: I950d173d20dee443b03b40ee04618afb98a95f38
It's useful to debug MIME related problems.
- New MimeStreamParser.LOG_MESSAGE flag
- Cleaned up LoggingInputStream, which now supports all InputStream methods
(e.g. close, available, etc.) properly.
- LoggingInputStream now dumps non-printable ascii chars as '\xXX'.
Change-Id: I4391e125abd418defc1dc21e4f35cf6ef8448acb
* Turns out that Exchange 2003 requires the ics attachment to be in a
multipart/alternative, rather than a multipart/mixed MIME message
* Exchange 2007 accepts both types
* Therefore, we change our output for this particular situation, i.e.
a single attachment that is an ics file, to multipart/alternative
* Rename FLAG_SUPPRESS_CONTENT_DISPOSITION to FLAG_ICS_ALTERNATIVE_PART
and make this flag do double duty - 1) suppress the Content-Disposition
header (also required by Exchange) and 2) send the message as
multipart/alternative
* Add unit tests for Rfc822Output to check that mime parts are composed
properly
Bug: 2516394
Change-Id: I60e26f57b8ecaf01d0340e7828533334e0e7d45a
* Disabling a Calendar is supposed to delete all events from the
database via CalendarProvider
* We didn't call the delete method with the CALLER_IS_SYNCADAPTER
parameter, so the deletions were propagating to the server, which
is VERY bad
* This CL adds the parameter to the URI used for deletion
Bug: 2521196
Change-Id: Ib366979fe32ebff0f8cfa3e3f0843ad7e2af4d47
- Now SimpleIcsWriter does the UTF-8 conversion, and folds lines according
to the number of bytes in UTF-8.
- It now escapes special chars in TEXT values. You can safely put , ; \ or
line breaks. in summary, location, and description.
- Quotes all CN. (leftover from Ibb8f155a)
- Replace "s in CN with 's (rather than removing them)
Bug 2508283
Bug 2515768
Change-Id: Ibdced53ee32bba950608d63f507b11b24eaad7b0
* Clean up logging
* Clean up TODO's
* Clean up some unused code & warnings
* Bugfix: trim query string before calling provider
* Bugfix: use correct # for "First n results..."
* Bugfix: tie separator position tracking into cursor, to avoid
some concurrency problems when multiple cursors are in flight.
Bug: 2249514
Change-Id: Icf26599ecb9b27cbf88cd80e9abf4a3428598193
* The code was hard-wired to accept (ancient placehold code)
* Send code that depends on the user's actual response
* Rename inappropriately named method in Controller
Bug: 2515961
Change-Id: I8985a3206fc8c4498521b08806a1093abaf4a42c
* Add the (recurring) text when the invite is for a recurring
meeting
* Add a test for message text creation
Bug: 2515474
Change-Id: Ifefbc2ba1ac444175180cb7a58f4ec554d9674a3
Provider:
* Move UI (e.g. separator) out of provider, create it entirely in adapter
* Remove timestamp based disambiguation (TODO throttling some other way)
* Add cursor "extras" to report total # of results on server
UI:
* Rewrite background-foreground threading to be more efficient and
signal changes back to UI by calling notifyDataSetChanged())
* Separator strings per Rich's UI (not using real strings yet)
* Remove link back to AutoCompleteTextView
NOTE: There's a bug in ACTV that is causing the window size not to
change properly on notifyDataSetChanged(). Framework team to investigate.
Bug: 2249514
Change-Id: I183b200dcdaa268f0612d2de6442db28e1491d40
* Check for null when retrieving Mailbox
* Fix other two spots where we needed checks; thanks, Makoto!
Bug: 2516857
Change-Id: I56ccca16b5f85521e67ef6f92d1cd8f10e5f4a44
* The utility wasn't handling commas properly, causing the referenced
bug
* Fixed the utility and updated the relevant test case
Bug: 2515488
Change-Id: Id229e50fcaaed1a0142db301eedaaba9209bed13
* 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
