Android allows only having one address book per account, so until now
users of EteSync were only able to have one address book. This was
always an annoying limitation, but even more so now that journal sharing
is implemented.
Luckily, DAVdroid recently implemented multiple account support by
creating sub-accounts for address books.
This patch is an import of the DAVdroid changes, with adjustments to
work with EteSync, and a few changes that did not make sense for
EteSync. The original commits' split didn't provide any value over this
squash, and the amount of adjustments and addition needed to be done to
apply them, made me decide to squash this change together.
This commit is mostly based on:
dfec72ce6b8ff5e0780e9ac4418c81d080f4b60b
9817594da14ad8dffae18de386e14aeaf41312b9
This change only works for calendars at the moment, because we don't have shared
address books anyway.
This is currently only implemented in the client, and only as a read-only attribute,
you can't make a journal read-only yet. This requires server support that is not yet
there, but it's better to be ready for this sooner rather than later.
Requery doesn't automatically update column constraints, and there was
an issue with it applying indexes before adding the new columns which
was also causing troubles. This commit, while ugly, just manually
updates the database using raw SQL to what we expect it to be.
Having it in raw sql was slowing down development, and was error-prone.
It's much cleaner now, easier to handle, and enables us to develop
faster.
In this change I also fixed the fetching of journals to be by service
and id, not just id, because just id is not guaranteed to be unique.
The server was changed so the owner of the journal, and the encrypted
key (if a shared journal) would be exposed. This change fetches it, and
saves it.
* move file name/UID generation from SyncManager to LocalContact, LocalEvent, LocalTask
* rename updateFileNameAndUID() to prepareForUpload()
* use random UUID for contacts, UidGenerator with Android device ID for events/tasks
* LocalEvent.prepareForUpload(): use existing UID_2445 if available
The app update broadcast receiver is only called on the first update,
not install, which was causing EteSync to think it was updating from
version 1 on the first update, doesn't matter which version one was
updating from.
This fixes it by saving the version on the first run.
Commit 5d1c90dcba fixed a bug where
entries added from the server were marked as "local only" (null etag)
which was causing issues. That commit fixes it for newly added resources,
but existing resources remained broken.
This commit goes through the database and fixes all of the existing
broken resources. It skips dirty entries because figuring out if they
were just created or updated is complex, and the chances of doing an
update at exactly the same time there are dirty entries is quite low,
so the complexity involved is just not worth it.
I was trying to avoid it, and keep it as davdroid both for attribution,
and making it easy to cherry-pick fixes from DAVdroid.
However, it seems to be causing clashes with the davdroid app, although
every piece of documentation claims otherwise.[1]
At least it seems like cherry-picks can still be achieved using:
git cherry-pick -s recursive -X find-renames=30 COMMIT
1. https://developer.android.com/studio/build/application-id.html
(one such doc)
