Previous parts of the saga brought me to a point where I had an upgraded instance of the Radicale CalDAV server talking to my Android phone's CalDAV adapter and still getting nowhere. I decided to debug the Android-side code.
Attaching the debugger was a bit of a trick since the adapter has no Activity. Once I got past that, I discovered the response from Radicale was getting parsed just fine but it was only happening in an authentication context (i.e. while adding the new "CalDAV account"). I generally found that the adapter was basically a bunch of callbacks and I seemed unable to properly trigger them.
I then noticed something funny in the log (i.e. the LogCat view in the DDMS perspective in Eclipse):
VFY: unable to resolve static field 27 (CONTENT_URI) in Landroid/provider/CalendarContract$Events;
According to the documentation, Events.CONTENT_URI is one of the basic constants used when working with calendars - how could it be missing? The question led to a quick series of discoveries:
- My phone runs Android 2.3.7 a.k.a. Gingerbread (well, not really a discovery for me but a key piece of the puzzle).
- Proper support for non-Google calendars was only added in version 4.0 a.k.a. Ice Cream Sandwich; what there was before was unofficial and unsupported.
- The CalDAV Adapter project lists API level 14 (Ice Cream Sandwich) as the minimum required API level in its Android manifest.
- Back when I first tried to run the CalDAV adapter, Eclipse ADT had told me I had no compatible device; I tried modifying the manifest, changing the minimum API level to 10 (Gingerbread).
- Changing the minimum API level of an Android project doesn't trigger a re-build in Eclipse ADT; changing the target API level does trigger a re-build.
- Once prompted to re-build the project, ADT flags usage of higher-than-minimum-level APIs as an error, breaking the build.
- When Dalvik encounters unknown API usage while executing the code, it marks the block where the API was used as dead code and moves on.
So I was trying to use an application that was incompatible with my handset and both the development environment and the runtime responded with silent failures. I think ADT in particular behaved quite impolitely. If using APIs beyond the minimum level is off-limits then changing the minimum level should trigger a re-build, right? As for the Android runtime, the documentation says
...the application will crash during runtime when attempting to access the unavailable APIs.
which seems to be false (or at least no indication of a crash reaches the user). In any case, the approach I'd been taking turned out to be a dead end. Continued in part 5.