Even more reverts. :(
After additional testing (based on user reports) it seems like this may
still be causing issues. I find it weird and don't understand why, but
I'm reverting this as a precaution so people aren't affected.
Related to #97
This reverts commit da3ac48bbf.
This is not needed for proper deployments where the server properly locks
the database tables. But in some older etesync server versions and possibly
bad databases, this is not the case.
OpenTasks causes EteSync to concurrently try to sync, so this at least makes
sure this race condition doesn't happen for these rare cases.
A lot of reverts. :)
According to more information and testing in #97, this was indeed
unrelated and 1.9.3 was enough to fix it.
This reverts commit 73179318f3.
It seems like this is the cause of #97 as 19b4e2a796
hasn't fixed the issue. Still not sure why it's happening, but reverting
it so no more users suffer from this issue.
This reverts commit 26ea8900a2.
I'm pretty sure this was causing the recent issues with tasks and events
disappearing as described in #97.
Regardless of this, it's not actually needed as SQLite on Android is
already thread-safe. The SQLite locks some users were experiencing were
probably fixed in 26ea8900a2
This reverts commit 9ed172e23c.
Before this change we were fetching the journals 3 times each time (once
for each journal type).
This was wasteful both for the server and battery life. Now we just cache the
requests for a few seconds with the assumption that a burst most mean it's
the same sync operation.
This change was mostly flagging non-real issues, like connection reset
by peer. Revert for now and come up with an alternative solution.
This reverts commit d3ad17e0bb.
They inherit from IO exceptions so were temporarily ignored, but they could
indicate a real issue with the ability of this user to connect to the
server.
This change makes it easier to detect if a debug report was actually due to a
real issue, or is just a user sending the debug activity without any real
issue behind it.
This is to battle the surprising amount of debug info spam we've had to battle
with. Essentially users sending debug info without actually experiencing any
issues and never replying to questions. This is made worse because many of
those emails also have weird addresses in CC which make it look even more
like some weird sort of spam.
iCal support EMAIL event reminders which EteSync doesn't and can't support
due to end-to-end encryption. This commit therefore modifies the event reminders
DISPLAY so reminders are actually shown on the phone.
Fixes#63
This is really just an ugly workaround for a crash. This whole thing needs to
be redone. It's currently quite broken when it comes to lifecycle handling and
a source for many issues.
I'm a bit conflicted about this one because even though EteSync is
end-to-end encrypted, people should be using TLS.
I can't think of a reason why anyone would want to use HTTP over HTTPS,
especially given let's encrypt exists and EteSync supports self-signed
certs, but I guess it's better to allow it for now, at least until we
have a nice error message for it.
Fixes#81
This is somehow a revert of 536bef9815.
It was initially implemented as a workaround for #24, but having
improved all the clients to deal with weird UIDs and matured a lot since
then, I believe this is no longer an issue.
Would have to keep a close eye for regressions.
We've recently started getting exceptions such as:
"java.lang.ClassCastException: java.lang.String cannot be cast to java.util.ArrayList"
I suspect it may be related to using the new email body prefix which is
probably not as well tested upstream as the rest of the code. Removing
it to see if this fixes things.
The exception handling was duplicated across every sync backend.
It was redundant and made it easy to not handle all of the exceptions correctly
everywhere.
I've seen some crashes there. This change brings it inline with
DAVDroid, and looks cleaner regardless.
Based on 1f7298f947a4878e86fcba0c6722e34b03cb63c6 from DAVDroid
With this change, we make it so using a self-signed certificate will
have to be authorised on the first login rather than checked every time
on the background.
This was causing annoying issues with networks that mitm SSL
connections, and anyhow, we shouldn't be asking users to trust bad certs
when in 99.9% of the cases it would either be an attack or a broken
network.
Fixes#36
A lot of the code dealing with collections assumes that the editing is
done by the owner (true assumption, for now), and therefore the encryption
key is derived from the master key (not true anymore, as it could be a
stored version of the old key). This commit removes this wrong assumption.
This fixes a bug with deleting entries that were never synced before. To
reproduce:
1. Turn off wifi + data (to ensure nothing is synced).
2. Add an entry (event/task/contact).
3. Delete that entry.
4. Turn wifi + data back on
5. Hit sync
This was an annoying remanent from DAVDroid. Maybe it makes sense for
DAV, but it defo doesn't make sense for us where we can just create
collections (and anyhow always have existing defaults!).
This should never happen, but it has:
kotlin.TypeCastException: null cannot be cast to non-null type com.etesync.syncadapter.resource.LocalContact
at com.etesync.syncadapter.resource.LocalGroup$Companion.applyPendingMemberships(LocalGroup.kt:66)
at com.etesync.syncadapter.syncadapter.ContactsSyncManager.postProcess(ContactsSyncManager.kt:122)
at com.etesync.syncadapter.syncadapter.SyncManager.performSync(SyncManager.kt:169)
at com.etesync.syncadapter.syncadapter.ContactsSyncAdapterService$ContactsSyncAdapter.onPerformSync(ContactsSyncAdapterService.kt:59)
at android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:259)
We call it at post process exactly because we want to make sure that all
the members already exist.
I guess a deletion on a misbehaving client (maybe even the web client?)
can cause this. Potentially also with some DAV clients.
Anyhow, it's better to be more defensive here.
Fixes a potential crash when e.g. importing a file with a group that has
members that don't actually exist (e.g. importing a partial vcf).
This change also fixes importing files that have the groups show up
before their members.
The way it's done is by changing the password and adding ourselves as
journal members with our public keys. Same way shared journals works.
This should not be used if you believe your encryption password has been
compromised. That would require a much more intrusive action (as the
note there indicates).
The reason for that, is that in some cases it stops working for certain
files, so using a different filename works around that issue.
I haven't managed to resolve that unfortunately.
These are bad, and shouldn't happen, but ignoring them is not
the end of the world, especially since I plan on overhauling this
code very soon (probably remove).
So for now, we'll just ignore them.
This adds support for tasks via OpenTasks.
https://github.com/dmfs/opentasks
Need the OpenTasks client for it to be used.
Currently you can't create new task lists. You can only have the default
one, but that's just a UI thing.
Fixes#7
This is a monster commit because to be honest, it's a monster change. It
was impossible to do it in smaller steps because things just wouldn't
compile.
We couldn't do the migration step by step because they moved to Kotlin
which was causing a lot of troubles.
Now we are all on Kotlin, so things should hopefully work just fine.
It just needs a few tiny wrappers around some public statics. I'm not
doing that because it'll sort itself out the moment we update
vcard4android and ical4android.
Networking is not allowed on the main thread, and on some devices with strict
mode on, even the creation of the http handler is enough to trigger an
exception (i.e even if not used from the thread).
This moves even the creation to a thread which fixes the issue.
HTTP requests and responses are logged when logging to file. Until now,
only the existence of requests was logged. With this change, also the
content and headers of the requests and responses is printed to the log.
Before this change we were printing added/changed contacts and groups
to the adb log. This is not a big deal on its own, but now since we
have ACRA, we share these logs on crash (if user approves) so it's
better to remove personal information to make sure it's not being
accidentally shared.
Android annoyingly kill sync managers that don't have a significant
amount of network traffic within a given minute. This means that if we
have a lot of entries to process, we may get killed by the system if we
have a lot of entries to prepare for pushing. We were sending in chunks,
for network performance, but now we make the whole process work in
chunks.
This should fix an issue reported by a user who imported a significant
amount of contacts in one go.
This is similar to the issue fixed for fetch in:
f7104bbcef
We were doing it to make sure we don't get overridden by
server changes. But we already changed this behaviour in
the past, so this call was just doing nothing and slowing
down the sync.
This was causing issues when importing from a Google account in some cases
because we were getting weird UIDs.
This was also problematic when importing from other sources that
reported weird UIDs.
This will make it easier to identify and fix crashes.
Until now we relied on user to automatically figure out if the app has
crashed and gather debug info manually. This didn't work well,
especially in places like "import" where they just assumed the import
finished successfully if there was a crash.
This change makes it so whenever there's a crash, the email app is
opened with a template email and the stack trace attached.
This should make it easier for us to detect and fix issues.
Important to note: nothing is sent automatically.
