# jtx Board puts journals, notes and tasks in one iCalendar app

> jtx Board is an Android application for meeting minutes, notes and tasks that maps them onto the iCalendar standard, with journals and notes as VJournal components and tasks as VTodo, and it synchronises through DAVx5 against any CalDAV server. The source is GPL-3.0 and there is an open source edition that is the recommended flavor to build yourself.

**TechbeeAT/jtxBoard** — jtx Board allows you to manage your Journals (like meeting minutes), Notes and Tasks in one Android app. The app is compatible with the iCal standard (RFC5545) and is integrated with DAVx5 to allow the synchronisation of entries through CalDAV.

- Repository: https://github.com/TechbeeAT/jtxBoard
- Website: https://jtx.techbee.at/
- Stars: 701 · Forks: 29
- Language: Kotlin
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/techbeeat-jtxboard

## Three kinds of note, one app, one standard

jtx Board is an Android app for managing journals, like meeting minutes, notes and tasks together. The project's own framing is that it elevates the power of the iCalendar standard, using the combination of journals, notes and tasks from one app and synchronising through DAVx5 with the CalDAV server of your choice.

The design decision is in the component mapping. Journals and notes are compliant to the definition of the VJOURNAL component, and tasks are compliant to the VTODO component. Both halves of the app therefore use the same underlying iCalendar data model, which is the point of the standard compliance.

Why that matters is interoperability. The README states that using the iCal standard ensures compatibility and interoperability with other apps and services independent of a dedicated provider or infrastructure. A meeting note saved as a VJournal and a task saved as a VTodo are objects that other CalDAV clients understand, so a phone app does not become the only place the data can live.

The app also supports linking entries to each other, with the example given being to create meeting minutes and link your tasks to them, rather than keeping notes and task lists in separate applications that cannot relate to one another.

## DAVx5 does the synchronising, not jtx Board

The synchronisation story is a division of labour that needs stating clearly, because it shapes what you have to install and what you can change.

The app does not implement CalDAV itself. Synchronisation is handled by DAVx5, and the README says that by using DAVx5 you are free to choose your preferred provider for CalDAV, and that you can even use your local server to store and synchronise your data. The note that follows is important: DAVx5 is an independent app and must be acquired separately.

The consequence is a two app workflow. You install jtx Board for the notes, tasks and journals, and DAVx5 for the account and the sync, and DAVx5 is where you point at a server. That is a real advantage over apps that hardcode one provider, and it is also a real cost in setup, because the account lives in a different application and the two have to agree on the calendar set you are working with.

The permissions list shows how the two talk. GET_ACCOUNTS is used to determine if there are accounts set up in DAVx5 and show them in the interface, and READ_SYNC_STATS is used to show a progress bar when a synchronisation through DAVx5 is currently in progress. So the app reads the DAVx5 account list and the sync state rather than doing any account handling of its own.

For troubleshooting, the README points to a support article on synchronisation problems before you open an issue, which is a reasonable thing for a project with this many moving parts to ask.

## Five build flavors, and one of them is the honest one

The flavors section is the most revealing part of the README for anyone thinking about building this from source, because the distinction between the editions is explicit.

The gplay flavor is for the Google Play store and comes in a standard and a pro version, where the pro version is paid and enables editing options for remote entries. The huawei flavor targets the Huawei app gallery with the same standard and pro split, and the amazon flavor targets the Amazon app store in the same way. A generic flavor existed for other app stores and is marked deprecated, and it contained only open source libraries and was meant to be paid for before downloading.

The ose flavor is the open source edition, and the README is explicit that it is the recommended flavor if you want to build the app from source. It contains only open source libraries, and instead of an in-app purchase it has an additional page for donations. It also makes a specific technical substitution: since Google Maps is not open source, the ose flavor uses OpenStreetMap.

That single difference changes the behaviour of the map features, which is worth knowing before you build. The permission list ties location to moving the map to your current position and setting coordinates for an entry, and in the open source build that map is OpenStreetMap rather than Google Maps.

So there are effectively two different applications under one name, and the paid editions are not upgrades of the open source one so much as the same application with a proprietary map and remote editing enabled.

## The permission list is a feature list in disguise

Applications that ask for a long list of permissions usually look evasive about it. jtx Board does the opposite, and the permission section is effectively a feature specification with the reasons attached, which makes it a good place to understand what the app really does.

RECORD_AUDIO can be used to access the microphone for adding audio notes and to use the speech-to-text engine, so voice input to a meeting minute is a first class path. READ_CONTACTS can be used to get suggestions when selecting attendees or a contact for an entry, which is what makes attendee selection bearable. INTERNET is used to retrieve the list of contributors for translations from Crowdin, the code from GitHub, and the release notes from GitHub.

The remaining permissions are about alerting and location. POST_NOTIFICATIONS lets you receive notifications when an alarm is due, and SCHEDULE_EXACT_ALARM with USE_EXACT_ALARM are used to show a notification when an alarm is due. RECEIVE_BOOT_COMPLETED is used to restore notifications and geofences after restart. ACCESS_COARSE_LOCATION and ACCESS_FINE_LOCATION can move the map to your current location and set the current coordinates for an entry. ACCESS_BACKGROUND_LOCATION is used to trigger a notification for a geofence, and it is marked as applying to the gplay flavor only. VIBRATE gives haptic feedback when moving an entry on the Kanban board, which is the only mention of the board in the permission list and a hint at a task view organised by state.

Note the two permissions that are not there. There is no camera permission and no contacts write permission, and the location permissions are described as optional capabilities rather than core requirements.

## Three distribution channels and a published signing key hash

jtx Board is distributed through the Google Play store, through F-Droid, and as official APKs on the GitHub releases page. The presence of all three is the interesting part, because the F-Droid build and the Google Play build are not the same artefact.

The README states that the official APKs provided on GitHub releases are currently signed with a key with a specific SHA-256 hash, and it prints the hash so that anyone can check it.

```
8C:52:4F:E3:CF:6C:48:27:0D:A0:2A:F3:CD:9C:89:90:38:D7:B0:0D:2E:8C:9F:C1:C4:E2:6B:F3:2E:E8:69:70
```

Publishing the hash of the signing key is the practice you want to see from anyone distributing an APK outside a store, because it lets you verify that a build came from the project rather than from someone who repackaged it. It is a small detail that removes an entire category of doubt.

Around the distribution there is a community structure. Translations are managed through Crowdin, with the project linking its Crowdin page and the app fetching the contributor list over the network at runtime. Contributions are welcomed in a broad sense, covering financial support, translations, code changes, bug reports and feature requests, with the contribution page on the project website. There is a PayPal donation button, a ko-fi button, and the project asks that questions go to the forums on GitLab or through the support form on the site rather than to issue trackers, which keeps the issue tracker for defects.

## A develop branch, a beta tag and a busy release line

The default branch of the repository is develop, which is the branch the fastlane metadata paths point at as well, and the release tags tell a familiar story. Version 2.17.00 was published on 2026-07-23, a beta of the same line, v2.17.03-beta01, followed on 2026-09-11, and v2.17.03 shipped on 2026-10-05. The last push to the branch was on 2026-10-18.

So the project runs a numbered release line with betas ahead of the stable build, and it publishes to Google Play, F-Droid and GitHub releases from that line. The pace is regular enough that a user can expect a release every few weeks.

The repository layout confirms what kind of project this is. There is an app/ directory for the application, a baselineprofile/ directory for baseline profiles, a fastlane/ directory for the release automation and store metadata, gradle.properties, build.gradle.kts and settings.gradle.kts for the build, gradlew and gradlew.bat for the wrapper, and a crowdin.yml at the root for the translation pipeline. There is also a .gitlab-ci.yml, which is a leftover from an earlier CI setup, and a CODE_OF_CONDUCT.md.

The licence is GPL-3.0, with the text in LICENSE.txt.

One feature is announced as future work rather than shipped. The README says future features will also include import and export functionalities to and from .ics files, and marks it with a smile. Until that lands, the interoperability argument rests on the CalDAV sync through DAVx5, which is a real constraint for anyone whose existing notes live in .ics files rather than on a server.

## Conclusion

jtx Board suits an Android user who wants one place for meeting minutes, notes and tasks, stored as standard iCalendar components so that the data is not locked to one app, and it does not suit someone who wants the app to talk to a CalDAV server on its own, because DAVx5 is a separate application. Before adopting it, build the ose flavor rather than the store flavors if you want to avoid proprietary components, and read the permission list first, since the app asks for contacts, microphone, location and background location, each for a stated purpose.

## FAQ

### What is jtx Board and which iCalendar components does it use?

jtx Board is an Android app for managing journals, notes and tasks in one place. Journals and notes are compliant to the VJOURNAL component and tasks to the VTODO component, and the app is compatible with the iCal standard, RFC5545.

### How does jtx Board synchronise with a CalDAV server?

It does not synchronise on its own. Synchronisation is done by DAVx5, which is an independent app that has to be acquired separately, and by using it you can choose any CalDAV provider or run your own local server. The app reads the DAVx5 accounts through GET_ACCOUNTS and the sync progress through READ_SYNC_STATS.

### Which jtx Board flavor should I build from source?

The ose flavor. It is the open source edition, it contains only open source libraries, it replaces the in-app purchase with a donation page, and because Google Maps is not open source it uses OpenStreetMap instead. The gplay, huawei and amazon flavors come in standard and pro versions, and the generic flavor is deprecated.

### Why does jtx Board ask for contacts, microphone and location permissions?

The README gives the reason for each one. RECORD_AUDIO is for audio notes and speech to text, READ_CONTACTS is for attendee and contact suggestions, the location permissions are for moving the map and setting coordinates for an entry, and the alarm and boot permissions are for notifications, including geofence notifications after a restart.

## Sources

- [License: GPL-3.0](https://github.com/TechbeeAT/jtxBoard/blob/develop/LICENSE)
- [Project website](https://jtx.techbee.at/)
- [README](https://github.com/TechbeeAT/jtxBoard/blob/develop/README.md)
- [Releases](https://github.com/TechbeeAT/jtxBoard/releases)
- [TechbeeAT/jtxBoard on GitHub](https://github.com/TechbeeAT/jtxBoard)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/techbeeat-jtxboard