Phase 5 of docs/OWN-STORE.md. The :provider module goes — 84 Java files, 14,555 lines, its <provider>, its two custom permissions, its 13 translated strings and its three dmfs runtime dependencies. Room has been the default since the previous commit and every v0.3.x install has been imported, so nothing reads it any more. StorageMode.LOCAL is gone with it; OWN and EXTERNAL are what remain. ProviderResolver narrows to what it was always really for — discovering external providers — and answers null in OWN mode, where there is no authority to resolve. Callers that need to tell that apart from "External with nothing installed" ask mode(). ProviderStatus is unconditionally READY in OWN mode: the permission gate only ever applied to External, and that is now visibly true rather than a special case inside it. A stored LOCAL is read as OWN rather than as an unparseable value. Left to fall through to autoMode, someone who had explicitly chosen local storage while also having OpenTasks granted would have been sent to OpenTasks instead. ProviderChangeReceiver's manifest filter drops our own authority — safe now, because nothing of ours broadcasts ACTION_PROVIDER_CHANGED. In OWN mode Room's InvalidationTracker covers foreground changes and nothing outside the app can change our data. When SYNC.md phase 3 lands, the sync worker must call ReminderScheduler.sync() itself; that is the replacement for the broadcast and it belongs in the sync work. lib-recur stays as a direct dependency and is still Apache-2.0 dmfs, so the attribution is still owed — now as a normal third-party dependency. provider/PROVENANCE.md is replaced by a postscript in STORAGE-DECISION.md recording that the fork existed, why, and the one detail that still binds us: tasks.org is DB 22 and has no is_recurring, so TaskMapper must keep deriving recurrence from rrule/rdate. BREAKING: the de.jeanlucmakiola.agendula.tasks authority and both custom permissions are gone. Anyone who pointed DAVx5 or another app at that authority loses it; External mode is the answer. Needs calling out in the release notes. Verified: the APK declares no ContentProvider, no custom permission and no agendula.tasks authority, and carries no dmfs provider classes.
Agendula — documentation
Agendula is a Material 3 Expressive task app for Android. It carries its
own task store — the dmfs task provider vendored under our own authority — so
it is complete and local-first with nothing else installed; an external provider
(OpenTasks / tasks.org, synced by DAVx5 / SmoothSync / DecSync) is a user choice
rather than a requirement, and our own CalDAV sync is the 1.x arc. Sibling to
Calendula. See the
top-level ../README.md for the project pitch.
Index
| Doc | What it covers |
|---|---|
ARCHITECTURE.md |
How Agendula is built today — layers, the data seam, provider resolution, the reminder engine, DI, build/tooling, manifest. Start here to work on the code. |
ROADMAP.md |
Status and what's next — milestones (M0–M6 + Posture B), what's done, open decisions, how to build/verify. |
STORAGE-AND-SYNC.md |
Where task data lives — the decision to ship our own provider, the storage modes, permissions, distribution, and the dead ends. Supersedes PLAN.md on storage. |
SYNC.md |
How data reaches a server — the CalDAV sync adapter: the VTODO ↔ TaskContract mapper, Nextcloud sign-in, the engine, libraries and their licenses. Step 5 of STORAGE-AND-SYNC.md. |
STORAGE-DECISION.md |
Keep the vendored provider, or build our own? The measured cost of both. Decided: build our own. |
OWN-STORE.md |
Agendula's own Room store — the schema, recurrence design, migration off the vendored provider, and the six-phase plan that deletes :provider. Supersedes the "keep the provider" position in STORAGE-AND-SYNC.md. |
PLAN.md |
The original implementation plan and design rationale — the A-now-B-later thesis, what transfers from Calendula, the locked decisions. The "why". |
RELEASING.md |
How to cut a release — the git-tag-as-source-of-truth flow, CI jobs, F-Droid repo, required secrets. |
../provider/PROVENANCE.md |
What the vendored :provider module is, where it came from, and every deviation from upstream dmfs. |
Also: ../CHANGELOG.md (Keep a Changelog format; tag sections
feed the release notes).
How the docs relate
- PLAN is the original design decisions (the "why"), left as the historical record. On storage it is superseded by STORAGE-AND-SYNC.
- STORAGE-AND-SYNC and SYNC are the standing decision documents: the first settles where data lives, the second how it syncs. Both record rejected alternatives on purpose, so decisions don't get relitigated.
- ARCHITECTURE is the current shape of the code (kept in sync with the source as it grows).
- ROADMAP is the moving status layer (update as milestones land).
- RELEASING is the operational runbook.