Merge commit 'a094cc259da268ad6f78f50afe5cbbf674418b86' into kraken
* commit 'a094cc259da268ad6f78f50afe5cbbf674418b86':
Collectly preserve the service start-id.
Merge commit 'cf362a48c14ab3ebae55e9735f9cff6e77a4042a' into froyo-plus-aosp
* commit 'cf362a48c14ab3ebae55e9735f9cff6e77a4042a':
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
Merge commit '14812a50a8cacd1166cd2b0d0be0bf2bbeec662c' into froyo-plus-aosp
* commit '14812a50a8cacd1166cd2b0d0be0bf2bbeec662c':
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 '468fe91dd8d3f7c35a2ecd4187dcc38c2e5ad1cc' into froyo-plus-aosp
* commit '468fe91dd8d3f7c35a2ecd4187dcc38c2e5ad1cc':
Prevent account reconcile from running when service is down
Merge commit '4a1565fd7ec426ba4615aedeb3f2ddcb03ecac22' into kraken
* commit '4a1565fd7ec426ba4615aedeb3f2ddcb03ecac22':
Move a bare string to a resource.
Merge commit '5ab7ec7123b5aa6bc9f8fd7e59d2cdf27d716ef5' into froyo-plus-aosp
* commit '5ab7ec7123b5aa6bc9f8fd7e59d2cdf27d716ef5':
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 '44ae6d2fa2e79de533ceb1fdf50c578a4ed84a3f' into kraken
* commit '44ae6d2fa2e79de533ceb1fdf50c578a4ed84a3f':
Update unit tests for invitation creation
Merge commit 'f2d43c39b4f46d560b5f9d331dd238be63abfcf2' into froyo-plus-aosp
* commit 'f2d43c39b4f46d560b5f9d331dd238be63abfcf2':
Update unit tests for invitation creation
Merge commit '220d9107535360b842f1a8ff872b2d22296d98b3' into kraken
* commit '220d9107535360b842f1a8ff872b2d22296d98b3':
Use timezone in exception ics files
Merge commit '8ba07285336c34a1fa454b23c9d4c95af020fa00' into froyo-plus-aosp
* commit '8ba07285336c34a1fa454b23c9d4c95af020fa00':
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.
