The current Google API / OAuth method is not supported by DAVdroid but it’s still possible by using the old format as mentioned by @daniu :
Yet it requires the compromise Allow less secure apps: ON in the Google security settings.
However, delegates don’t sync.
Tested on OnePlus 3t, Android 7.1.1, DAVdroid 188.8.131.52.
I think the option to manually edit the server URL would be a nice feature. It can be in the settings dialog where you can change the password. Maybe it can be handled like creating a mail account in Thunderbird. When you put in you e-mail address it knows the POP/IMAP/SMPT servers but you have still the option to change them.
On issue as an example. I contacted the support of Davdroid for this and get very quick an answer. Thanks for this. My problem was that “web.de” changed the server and the server Davdroid is trying to connect to does not answer in the right way. Create a new account did also not help, because Davdroid setup again the wrong server. Manually set up two accounts, one for caldav and one for carddav, worked.
If someone has the same problem, the server address for carddav is https://carddav.web.de and for caldav it is https://caldav.web.de. Davdroid connect to carddav but for caldav it use https://kalender-bap.web.de/begenda/dav/users/ which is not working.
If I could manually adjust the servers, this would also help when the provider play around with their configuration and change something.
I support this feature request.
RFC 6764 Client “Bootstrapping” Procedures:
If an SRV record is not found, the client will need to prompt the user to enter the FQDN and port number information directly or use some other heuristic, for example, using the extracted “domain” as the FQDN and default HTTPS or HTTP port numbers. In this situation, clients MUST first attempt an HTTP connection with TLS.
But this is part of step 2. Determination of service FQDN and port number.
But we are at step 3. Determination of initial “context path”.
and there it is:
When an initial “context path” has not been determined from a TXT record, the initial “context path” is taken to be “/.well-known/caldav” (for CalDAV) or “/.well-known/carddav” (for CardDAV).
Which is the situation we have: No SRV and no TXT record.
I find it overly strict to read this in a way, that a vaild SRV record is a precondition to trying to use wll-known paths.