What assumptions does one make about addresses? I would be cautious before making very many.
In Japan there are areas larger than cities but smaller than regions. There are areas smaller than cities but larger than neighborhoods. There are areas smaller than neighborhoods. And you need all of them to form a proper address. What this means is that Android’s database is overly restrictive. It fails for Japan.
And other countries have even more screwy address schemes. Did you know in Nicaragua it’s common to describe places using the old names of buildings and the old names of streets followed by some basic directional notation? Crazy stuff!
Except that you can do what in fact people have done. You can just make one data column hold a ton of data. Sure, it’s a type error, but at least you gain the functionality you want.
As you say, this doesn’t affect the issue, but I’d be careful before assuming too much about address structure.
Sounds reasonable to me to look e.g. for a “BEGIN: VCALENDAR” and a “BEGIN: EVENT” as well as for a closing “END:VEVENT” and “END:VCALENDAR” as a basic validation. I think from a user perspective this should be fine, the subscription would be fast and as it can happen at any time that a once valid resource becomes invalid (maybe due to an error while the .ics file was created, or a failed file download, or…) I don’t see a drawback in validating the whole file only when synchronizing.
The problem vanished
I think it was related to an OwnCloud problem that also lead to degrading contact pictures in my case. After updating OwnCloud from 7.0 to 7.0.1, the issue with the contact pictures is gone and since then no speed dial assignment got reset. I also updated DAVdroid to the current version in between.