As said, “First it assumes they’re on the server and therefore adds them to the addressbook, later it thinks they are not on the server and deletes them locally”.
First it thinks they (the resources with unencoded @) are on the server:
DAVdroid requests these two (new) members from OwnCloud and adds all resources from the response. The response however does not contain the requested members, but 20140623T00123.086fed@foo.bar.vcf.vcf and /owncloud/remote.php/carddav/addressbooks/test/kontakte/20140623T46782.acdf@foo.bar.vcf.vcf. These resources are added nevertheless (because DAVdroid expects them to be the requested ones, and it has to trust the server-given resource names to distinguish between the resources).
later it thinks they are not on the server and deletes them locally:
In the last step (“delete every local non-dirty contacts that are not on the server anymore”), DAVdroid deletes everything except 20140623T00123.086fed%40foo.bar.vcf.vcf (unencoded) and 20140623T46782.acdf%40foo.bar.vcf.vcf, so the recently fetched resources are deleted immediately (because their names are 20140623T00123.086fed@foo.bar.vcf.vcf and /owncloud/remote.php/carddav/addressbooks/test/kontakte/20140623T46782.acdf@foo.bar.vcf.vcf).
Emphasis mine.
As far as I understand, DavDroid constructs a href-set of resources that are on the server, which contains 20140623T00123.086fed%40foo.bar.vcf.vcf and 20140623T46782.acdf%40foo.bar.vcf.vcf after the initial PROPFIND. However, when the server responds to multiget with 20140623T00123.086fed@foo.bar.vcf.vcf and /owncloud/remote.php/carddav/addressbooks/test/kontakte/20140623T46782.acdf@foo.bar.vcf.vcf, those hrefs should be added to that set too.
Yes, what I’m basically proposing is a sanity-check.
