This is not related to updating Android. Please follow up at https://forums.bitfire.at/topic/1259/rev-must-not-appear-more-than-once-in-a-vcard-component/
I’m using it and have not encountered an issue with the sync so far.
I have a Nexus 5 and flashed it myself and did not the OTA update. Is there a Testsuite that I could run or provide some other proof other than my written word.
For me everything works fine. I set up my dav from scratch after i updated to Android 5.
the only thing that does not work (and i do not know if it is an android 5 problem at all) is the VCF Import.
I got send a VCF file by mail and clicked on it in the gmail application (using an IMAP account there). It said “Create new contact in account: <gmail> / <davdroid>”, i selected the davdroid. Then you get a toast message that the vcf will be imported shortly but nothing happens.
FWIW I’ve been running davdroid without problems on a Nexus 5 and a Nexus 4 without problems.
CM12 (current self-built nightly) running on Moto G (falcon) here - unfortunately, DAVdroid stopped working for me after I updated both Android (5.0.2) and EGroupware (14.2). I used to run this setup (using older versions) for a long time and did not expect any problems. The new EGroupware version syncs fine with Lightning, etc. - this is why I suspect the problem may be DAVdroid on Android 5.
To rule out any problems in the F-Droid build I use I have built master for testing. CM privacy guard is disabled for DAVdroid. The setup process runs fine without errors (it also detects calendars and addressbooks). Also, DAVdroid does not throw any errors afterwards. I could not find any uncommon log entries, just the usual URL probing - the last thing I see is
I/davdroid.LocalCalendar( 9452): Inserting calendar: calendar_color=-3937682 canOrganizerRespond=1 sync_events=1 ownerAccount=testuser canModifyTimeZone=1 visible=1 account_type=bitfire.at.davdroid allowedAttendeeTypes=0,2,1,3 allowedAvailability=0,1,2 name=https://example.org/egroupware/groupdav.php/testuser/calendar/ allowedReminders=1 calendar_timezone=Europe/Berlin account_name=testuser calendar_access_level=700 calendar_displayName=Kalender Testnutzer -> content://email@example.com&account_type=bitfire.at.davdroid&caller_is_syncadapter=true
It does not sync any calendar or contact entries afterwards. Nothing in the logs, neither server nor logcat. Let me know if I should post full logcat. I would be glad about any hints - starting with, if I should open a seperate issue for this.
It does not sync any calendar or contact entries afterwards. Nothing in the logs, neither server nor logcat.
Is sync enabled? Did you try to force a sync process manually in the Settings? Is there “Sync calendars” and “Sync contacts”? Is there a status like “Last sync on …”?
Sure, automatic data sync is enabled. It states “Synchronization: ON” for my account when I select DAVdroid in Account settings (This is the first page, also offering the DAVdroid-Website). If I then select the account, I see entries for calendar and contacts, each with (sometimes) active sync symbols and (always) active checkmarks.
Unfortunately, I see no possibility to manually force sync in the new Settings UI. Accessing the three-dot menu I only get the options to “Abort Sync” or “Remove Account”. Also, there is no “Last sync on” status displayed. Let me know if I can provide further debug info.
Screenshots of the account settings: https://clbin.com/HovcEM.png, https://clbin.com/B01HjD.png
I just tested with current DAVdroid 0.6.12 and the same EGroupware Server mentioned above but using CM11 (Android 4.4.4) instead of CM12, the sync works flawless for both contacts & calender. By now I’m pretty confident we are facing some kind of regression here.
EDIT: I could also reproduce the problem described above with a test account, so the problem is not with my account.
No problem on Nexus 9 (5.0.1) and latest baikal server. Works like a charm.
Running on Galaxy Note 4 (5.0.1) with OwnCloud on the server side. Smooth, no problems.
Works here with (unofficial) Lollipop ROM (Galaxy S II), too, so I’ll close this issue.