Sadly, I have quite a few tasks, so that going over each item one by one to find the faulty one is not practical. So right now, I’m left with no working sync.
I would like to suggest two things
Improve logging to a point where I can easily identify the faulty task. The log output could just also dump the plain text it’s trying to parse below the stack trace. That would be immensely helpful. Other helpful Solutions would be to include the faulty timestamps if it’s easier. Basically: include anything that allows me to narrow down the faulty tasks.
(From the stack trace i’m not sure it falls within the domain of DAVdroid.) I do realize that DUE < DTSTART is against the specs. Warn about it all you want. But please don’t throw everything else under the bus by throwing an exception.
Steps to reproduce
Have a VTODO on your server that has DUE < DTSTART.
See this message in your notification area
See this log messageSYNCHRONIZATION INFO
Synchronization phase: 9
Account name: ---redacted---
java.lang.IllegalArgumentException: DUE must not be < DTSTART
DAVdroid version: 1.3.1-ose (116) Wed Sep 21 08:17:52 GMT+02:00 2016
Installed from: org.fdroid.fdroid
JB Workaround installed: no
System-wide synchronization: automatically
Address book sync. interval: x min
Calendar sync. interval: x min
OpenTasks sync. interval: x min
WiFi only: x
[CardDAV] Contact group method: CATEGORIES
RFC 6868 encoding: x
[CalDAV] Time range (past days): x
Manage calendar colors: x
| locale |
| x |
| setting | value |
| hint_OpenTasksNotInstalled | 0 |
| _id | accountName | service | principal |
| 3 | ---redacted--- | carddav | ---redacted--- |
| 4 | ---redacted--- | caldav | ---redacted--- |
| name | seq |
| services | 4 |
| collections | 52 |
| homesets | 11 |
| _id | serviceID | url |
| 10 | 4 | ---redacted--- |
| 11 | 3 | ---redacted--- |
| _id | serviceID | url | readOnly | displayName | description | color | timezone | supportsVEVENT | supportsVTODO | sync |
| 44 | 4 | ---redacted--- | 1 | ---redacted--- | ---redacted--- | -54 | <null> | 1 | 1 | 0 |
| 45 | 4 | ---redacted--- | 0 | ---redacted--- | ---redacted--- | -6306073 | <null> | 1 | 1 | 1 |
| 46 | 4 | ---redacted--- | 0 | ---redacted--- | ---redacted--- | -1146130 | <null> | 1 | 1 | 1 |
| 47 | 4 | ---redacted--- | 0 | ---redacted--- | ---redacted--- | -16777216 | <null> | 1 | 1 | 1 |
| 48 | 4 | ---redacted--- | 0 | ---redacted--- | ---redacted--- | -1605516 | <null> | 1 | 1 | 1 |
| 49 | 4 | ---redacted--- | 0 | ---redacted--- | ---redacted--- | -8355840 | <null> | 1 | 1 | 1 |
| 50 | 4 | ---redacted--- | 0 | ---redacted--- | ---redacted--- | -4989844 | <null> | 1 | 1 | 1 |
| 51 | 4 | ---redacted--- | 1 | ---redacted--- | ---redacted--- | -32944 | <null> | 1 | 1 | 1 |
| 52 | 3 | ---redacted--- | 0 | ---redacted--- | ---redacted--- | <null> | <null> | <null> | <null> | 1 |
Android version: 6.0.1 (---redacted---)
I understand the single address book per account issue and agree with keeping it as is. However, it would be nice to have the capability of copying an account so if there are numerous books it’s not necessary to enter there login information over and over. This may be an Android limitation, but the ability to change the name of the account would also be nice.
I would love to see an export function in the app.
Since I have to clean-install Android for every Update it would help me set up the device even faster.
But also if I switch to a new phone it would be awsome to be able to Ex- & Import the DavDroid and ICSDroid settings and just have to reenter the Password when setting it up.
What do you thing?
Is there a way bitfire will implement this feature to thair apps?
What exactly do you think should be encrypted and where/when/how?
If you want to protect the transport layer, you have to use TLS. Just using a symmetric cipher won’t bring any benefits because well-negotiated symmetric encryption is the essential part of a TLS connection.
On the application layer, a CalDAV/CardDAV server has to know all data, because it needs to understand and process it. This is how CalDAV and CardDAV work. It’s not possible to send encrypted data to a CalDAV/CardDAV server and it wouldn’t make any sense, too. For instance, a server must be able to filter all events and return only the ones of the last 90 days. This can’t work if the server doesn’t understand the data (because it’s encrypted).
So, if you want to protect your server, you will have to protect it physically and use disk encryption.
If you want to protect your Android device from unauthorized usage, you can use full-disk encryption together with an appropriate locking mechanism.
But maybe this was already the case before the patch…
Yes, it was.
That’s because AccountsActivity uses Toolbar widget while AccountActivity uses old action bar. The former makes a true shadow via the elevation API, the latter–a fake shadow via a drawable. Why Google can’t make them look similar is a different question.
Hello, it would be nice, if I can configure two links in davdroid for the same calendar.
As example, if you have an owncloud at home, you can use your internal address 192.169.XXX.XXX
And on tour davroid switches automatically to the external address https:yourdamoin.de
It looks like even applying the patch given in the FAQ on an AOSP build of Contacts no longer works as it seems Google has removed group support totally. I’ve also tried the OmniRom version of Contacts and a number of third party address book/contacts apps found on Play Store. Some that claim support for groups or categories turn out to only be able to hide/show various accounts.