* preference screen for debug settings
* allow to disable HTTP compression
* verbose network logging only when activated
* single HttpClient for all threads (before: single HttpClient per adapter)
* bump version to 0.5.13-alpha
* store unknown VCard properties in an extra column and load them when generating a new VCard (closes#118)
* upgrade to ez-vcard/0.9.3 (fixes sync error reported via Play Store)
* (re-)enable stale collection check, RetryHandler to retry idempotent CalDAV/CardDAV requests (hopefully fixes#225)
* always set FN/display name (take organization if no structured name is available) (hopefully fixes#227)
* Account settings are now read/set using AccountSettings
* AccountSettings upgrades old account settings when necessary
* Settings v1: use absolute URLs instead of paths and discard principal path
(required for future implementation of well-known URIs)
* relevant RFCs go into the doc/ directory for reference purposes
* read-only calendar collections are set as read-only in Android
* HTTP exception refactoring to mark 4xx HTTP errors as hard sync errors (numAuthExcetions/numParseExceptions) for Android sync manager
* query current-user-privilege-set for resources, detect read-only resources
* show read-only resources as read-only in SelectCollectionsFragment
* minor refactoring (DavProp.*)
* generalized InvalidResourceException for parsing errors
* only iCals with both DtStart and DtEnd/Duration are processed (DtEnd will be derived by iCal4j when not present in .ics)
* all-day events must last at least one day (fixes#166)
* other DtEnd/Duration rewriting + tests
* work-around for crash when remote ETag is empty (shouldn't happen but happens sometimes)
* fetch multiple contact URLs (not only the first one) from contacts provider (fixes#150)
* support primary (preferred) phone numbers/email addresses
* fix (crash) bug in URI sanitation
* don't set calendar properties not supported by device's Android version
* require already-set remote file name when finding updated records
* version bump to 0.5.6α
Docs say that TransactionTooLargeException is thrown when the buffer reaches 1 MB. Because we can't know
how large a single insertion/update is and there may be contacts with larger photos, it's only safe to
commit after every insertion/update. If photos exceed ~ 900 kB it would be required to write the photos
to an asset file (maybe I'll do this later, then we can group insertions/updates again).
