From 95bb2d14ec1662ac9205b55fb246dac4b07c8351 Mon Sep 17 00:00:00 2001 From: Jean-Luc Makiola Date: Thu, 22 Oct 2026 10:59:35 +0200 Subject: [PATCH 01/10] docs(roadmap): record why a Wear OS companion is blocked on Play Services A companion needs Google's Wearable Data Layer, which is a proprietary service the privacy policy and the F-Droid build rule out. The roadmap entry now records that constraint, what the bridged notifications already give a watch, and the options if it is picked up. Refs #27 --- docs/ROADMAP.md | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index bb7731b..b1a6398 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -617,4 +617,19 @@ Deferred deliberately, in rough priority order: notification surface is known (`PLAN.md` §3). - **Migrate Calendula and Agendula onto `core-prefs` + `core-di`**: tracked in the kit's roadmap, not here. -- **Wear OS companion**: unscoped. +- **Wear OS companion** ([#27](https://codeberg.org/jlmakiola/clockula/issues/27)): + unscoped, and blocked on one constraint. A companion that shows and controls + the phone's timers and next alarm needs a phone-to-watch channel, and the only + practical one is Google Play Services' Wearable Data Layer + (`play-services-wearable`). That is a proprietary third-party service, so it + would break `PRIVACY.md`'s "no third-party service of any kind" and the + F-Droid build. What already works without it: ring, timer and snooze + notifications are bridged to a paired watch by the system, so the wrist + already gets the ring and its actions. The options, if this is ever picked up: + - **Standalone watch app**: its own timers, stopwatch and alarms on the watch, + no Play Services and no sync. Fits the privacy promise but does not control + the phone. + - **Play-only companion**: the Data Layer confined to a Play Store flavour, so + F-Droid builds stay free. It means two flavours with different features and + a privacy policy that has to describe the difference. + - **Leave it**: rely on the bridged notifications and do nothing more. From 0213af1260e13e4b76995df2aa240524965ea23d Mon Sep 17 00:00:00 2001 From: Jean-Luc Makiola Date: Thu, 22 Oct 2026 11:01:02 +0200 Subject: [PATCH 02/10] docs(roadmap): correct what a watch gets today Ring and timer notifications are ongoing, which Wear OS doesn't bridge, and bridging needs Google's Wear OS app anyway. Quote the privacy policy exactly, drop the unchecked "only channel" claim, and list bridging the ring as an option of its own. Refs #27 --- docs/ROADMAP.md | 28 +++++++++++++++++----------- 1 file changed, 17 insertions(+), 11 deletions(-) diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index b1a6398..303676d 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -618,18 +618,24 @@ Deferred deliberately, in rough priority order: - **Migrate Calendula and Agendula onto `core-prefs` + `core-di`**: tracked in the kit's roadmap, not here. - **Wear OS companion** ([#27](https://codeberg.org/jlmakiola/clockula/issues/27)): - unscoped, and blocked on one constraint. A companion that shows and controls - the phone's timers and next alarm needs a phone-to-watch channel, and the only - practical one is Google Play Services' Wearable Data Layer - (`play-services-wearable`). That is a proprietary third-party service, so it - would break `PRIVACY.md`'s "no third-party service of any kind" and the - F-Droid build. What already works without it: ring, timer and snooze - notifications are bridged to a paired watch by the system, so the wrist - already gets the ring and its actions. The options, if this is ever picked up: + unscoped. The part the issue describes, a watch that shows and controls the + phone's timers and next alarm, needs a phone-to-watch channel. The usual one + is Google Play Services' Wearable Data Layer (`play-services-wearable`), a + proprietary service that `docs/PRIVACY.md` ("no analytics, tracking, + advertising, crash-reporting SDK or third-party service of any kind") and the + F-Droid build rule out. Other channels (a Bluetooth link of our own through + `CompanionDeviceManager`) haven't been looked into. + Today a watch gets little: ring and timer notifications are ongoing, which + Wear OS doesn't bridge by default, and bridging itself goes through Google's + Wear OS app on the phone, so a degoogled phone gets none of it. Only the + "Snoozed until" notification reaches a watch on a Google phone. The options, + if this is picked up: - **Standalone watch app**: its own timers, stopwatch and alarms on the watch, - no Play Services and no sync. Fits the privacy promise but does not control - the phone. + no Play Services and no sync. Not blocked by anything; it just doesn't + control the phone. - **Play-only companion**: the Data Layer confined to a Play Store flavour, so F-Droid builds stay free. It means two flavours with different features and a privacy policy that has to describe the difference. - - **Leave it**: rely on the bridged notifications and do nothing more. + - **Bridge the ring**: let the ring and timer notifications reach a watch + (not ongoing, or a separate bridged notification), keeping in mind that a + dismiss challenge makes Dismiss open the phone's ring screen. From cb5cd5123be7eda7037f662e4980be6789b51aa7 Mon Sep 17 00:00:00 2001 From: Jean-Luc Makiola Date: Thu, 22 Oct 2026 11:03:44 +0200 Subject: [PATCH 03/10] docs(roadmap): keep the Wear OS note to what holds Ringing notifications are foreground-service notifications, so making them non-ongoing wouldn't bridge them; CompanionDeviceManager carries no data; and watches pair through their makers' apps. Say only what holds and note that a watch build has no F-Droid channel. Refs #27 --- docs/ROADMAP.md | 35 +++++++++++++++-------------------- 1 file changed, 15 insertions(+), 20 deletions(-) diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index 303676d..a8ad4f7 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -618,24 +618,19 @@ Deferred deliberately, in rough priority order: - **Migrate Calendula and Agendula onto `core-prefs` + `core-di`**: tracked in the kit's roadmap, not here. - **Wear OS companion** ([#27](https://codeberg.org/jlmakiola/clockula/issues/27)): - unscoped. The part the issue describes, a watch that shows and controls the - phone's timers and next alarm, needs a phone-to-watch channel. The usual one - is Google Play Services' Wearable Data Layer (`play-services-wearable`), a - proprietary service that `docs/PRIVACY.md` ("no analytics, tracking, - advertising, crash-reporting SDK or third-party service of any kind") and the - F-Droid build rule out. Other channels (a Bluetooth link of our own through - `CompanionDeviceManager`) haven't been looked into. - Today a watch gets little: ring and timer notifications are ongoing, which - Wear OS doesn't bridge by default, and bridging itself goes through Google's - Wear OS app on the phone, so a degoogled phone gets none of it. Only the - "Snoozed until" notification reaches a watch on a Google phone. The options, - if this is picked up: + unscoped. A watch that shows and controls the phone's timers and next alarm + needs a phone-to-watch channel. The usual one is Google Play Services' + Wearable Data Layer (`play-services-wearable`), a proprietary service that + `docs/PRIVACY.md` §2 ("no analytics, tracking, advertising, crash-reporting + SDK or third-party service of any kind") and the F-Droid build rule out. A + channel of our own (a Bluetooth link run by both apps) would avoid it, at the + cost of building the transport. Today the ringing alarm and timer + notifications are foreground-service notifications, which Wear OS doesn't + bridge, so a watch doesn't get the ring. The options, if this is picked up: - **Standalone watch app**: its own timers, stopwatch and alarms on the watch, - no Play Services and no sync. Not blocked by anything; it just doesn't - control the phone. - - **Play-only companion**: the Data Layer confined to a Play Store flavour, so - F-Droid builds stay free. It means two flavours with different features and - a privacy policy that has to describe the difference. - - **Bridge the ring**: let the ring and timer notifications reach a watch - (not ongoing, or a separate bridged notification), keeping in mind that a - dismiss challenge makes Dismiss open the phone's ring screen. + with no sync. No Play Services, but it doesn't control the phone, and there + is no F-Droid for watches, so it would ship through Play or sideloading. + - **Play-only companion**: the Data Layer confined to a Play Store flavour. + `PRIVACY.md` §2 would then need per-flavour statements. + - **Bridge the ring**: a separate, non-foreground notification for the ring + that Wear OS can bridge. A dismiss challenge would need a decision there. From fe1c2a3d489b82522163287fc9a914aacaa9ec34 Mon Sep 17 00:00:00 2001 From: Jean-Luc Makiola Date: Thu, 22 Oct 2026 11:05:53 +0200 Subject: [PATCH 04/10] docs(roadmap): reduce the Wear OS note to the decision it needs Any phone-to-watch channel sends data off the phone, which the privacy policy rules out today, so the entry now states that decision and the standalone alternative without speculating about notification bridging. Refs #27 --- docs/ROADMAP.md | 22 +++++++--------------- 1 file changed, 7 insertions(+), 15 deletions(-) diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index a8ad4f7..3463dca 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -619,18 +619,10 @@ Deferred deliberately, in rough priority order: the kit's roadmap, not here. - **Wear OS companion** ([#27](https://codeberg.org/jlmakiola/clockula/issues/27)): unscoped. A watch that shows and controls the phone's timers and next alarm - needs a phone-to-watch channel. The usual one is Google Play Services' - Wearable Data Layer (`play-services-wearable`), a proprietary service that - `docs/PRIVACY.md` §2 ("no analytics, tracking, advertising, crash-reporting - SDK or third-party service of any kind") and the F-Droid build rule out. A - channel of our own (a Bluetooth link run by both apps) would avoid it, at the - cost of building the transport. Today the ringing alarm and timer - notifications are foreground-service notifications, which Wear OS doesn't - bridge, so a watch doesn't get the ring. The options, if this is picked up: - - **Standalone watch app**: its own timers, stopwatch and alarms on the watch, - with no sync. No Play Services, but it doesn't control the phone, and there - is no F-Droid for watches, so it would ship through Play or sideloading. - - **Play-only companion**: the Data Layer confined to a Play Store flavour. - `PRIVACY.md` §2 would then need per-flavour statements. - - **Bridge the ring**: a separate, non-foreground notification for the ring - that Wear OS can bridge. A dismiss challenge would need a decision there. + needs a phone-to-watch channel, and the usual one, Google Play Services' + Wearable Data Layer, is a proprietary service that `docs/PRIVACY.md` and the + F-Droid build rule out. Any channel, ours or Google's, would also send data + off the phone, which the privacy policy currently says never happens. So + scoping this starts with a privacy decision, not with code. A standalone + watch app with its own timers and alarms and no sync avoids the question but + doesn't control the phone. From 99c052f94c602151227ca59ea691fe27b82613b6 Mon Sep 17 00:00:00 2001 From: Jean-Luc Makiola Date: Thu, 22 Oct 2026 11:07:07 +0200 Subject: [PATCH 05/10] docs(roadmap): state the Wear OS blocker against the policy as written PRIVACY.md already documents Auto Backup and crash reports as ways data can leave the phone, and there is a single build rather than an F-Droid one. Say that, and call the entry blocked rather than unscoped. Refs #27 --- docs/ROADMAP.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index 3463dca..d83c8c7 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -618,11 +618,13 @@ Deferred deliberately, in rough priority order: - **Migrate Calendula and Agendula onto `core-prefs` + `core-di`**: tracked in the kit's roadmap, not here. - **Wear OS companion** ([#27](https://codeberg.org/jlmakiola/clockula/issues/27)): - unscoped. A watch that shows and controls the phone's timers and next alarm - needs a phone-to-watch channel, and the usual one, Google Play Services' - Wearable Data Layer, is a proprietary service that `docs/PRIVACY.md` and the - F-Droid build rule out. Any channel, ours or Google's, would also send data - off the phone, which the privacy policy currently says never happens. So - scoping this starts with a privacy decision, not with code. A standalone - watch app with its own timers and alarms and no sync avoids the question but - doesn't control the phone. + blocked on a privacy decision. A watch that shows and controls the phone's + timers and next alarm needs a phone-to-watch channel. The usual one, Google + Play Services' Wearable Data Layer, is a proprietary dependency that + `docs/PRIVACY.md` §2 rules out and that would ship in every channel, since + there is one build and no flavours. A channel of our own avoids the + dependency but is still a new way for data to leave the phone, which + `PRIVACY.md` would have to document next to Auto Backup and crash reports. + A standalone watch app with its own timers and alarms and no sync avoids the + question, but doesn't control the phone and has no F-Droid route onto a + watch. From da16ab23ccae7c735a525fa284d7332b669469c2 Mon Sep 17 00:00:00 2001 From: Jean-Luc Makiola Date: Thu, 22 Oct 2026 11:08:53 +0200 Subject: [PATCH 06/10] docs(roadmap): quote the policy and list the AlarmClock route for Wear OS Cite PRIVACY.md's own wording, name F-Droid's non-free-dependency rule, and note that third-party watch apps can already drive Clockula through the AlarmClock intents. Refs #27 --- docs/ROADMAP.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index d83c8c7..2a2bf9b 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -618,13 +618,15 @@ Deferred deliberately, in rough priority order: - **Migrate Calendula and Agendula onto `core-prefs` + `core-di`**: tracked in the kit's roadmap, not here. - **Wear OS companion** ([#27](https://codeberg.org/jlmakiola/clockula/issues/27)): - blocked on a privacy decision. A watch that shows and controls the phone's - timers and next alarm needs a phone-to-watch channel. The usual one, Google - Play Services' Wearable Data Layer, is a proprietary dependency that - `docs/PRIVACY.md` §2 rules out and that would ship in every channel, since - there is one build and no flavours. A channel of our own avoids the - dependency but is still a new way for data to leave the phone, which - `PRIVACY.md` would have to document next to Auto Backup and crash reports. - A standalone watch app with its own timers and alarms and no sync avoids the - question, but doesn't control the phone and has no F-Droid route onto a - watch. + blocked on a privacy and distribution decision. A watch that shows and + controls the phone's timers and next alarm needs a phone-to-watch channel. + The usual one, Google Play Services' Wearable Data Layer, is a "third-party + service" that `docs/PRIVACY.md` §2 rules out, and with one build and no + flavours it would also be a non-free dependency in the build F-Droid makes. + A channel of our own (Bluetooth, since there is no INTERNET permission) + avoids the dependency but adds permissions and a new way for data to leave + the phone, which `PRIVACY.md` §5 currently says only crash reports do. + Two routes need no channel in Clockula: a third-party watch app can already + drive Clockula through the `AlarmClock` intents (ARCHITECTURE §17), and a + standalone watch app with its own timers and alarms doesn't touch the phone, + though it has no F-Droid route onto a watch. From dc23618c560529f59a2166f0011e15a707bd2293 Mon Sep 17 00:00:00 2001 From: Jean-Luc Makiola Date: Thu, 22 Oct 2026 11:10:38 +0200 Subject: [PATCH 07/10] docs(roadmap): drop the AlarmClock route from the Wear OS note MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit AlarmClock intents only reach apps on the same device and can't read state, so they are no route for a watch. Cite PRIVACY.md §4 and §5 together and say "no product flavours" precisely. Refs #27 --- docs/ROADMAP.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index 2a2bf9b..51b0f26 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -621,12 +621,10 @@ Deferred deliberately, in rough priority order: blocked on a privacy and distribution decision. A watch that shows and controls the phone's timers and next alarm needs a phone-to-watch channel. The usual one, Google Play Services' Wearable Data Layer, is a "third-party - service" that `docs/PRIVACY.md` §2 rules out, and with one build and no - flavours it would also be a non-free dependency in the build F-Droid makes. - A channel of our own (Bluetooth, since there is no INTERNET permission) - avoids the dependency but adds permissions and a new way for data to leave - the phone, which `PRIVACY.md` §5 currently says only crash reports do. - Two routes need no channel in Clockula: a third-party watch app can already - drive Clockula through the `AlarmClock` intents (ARCHITECTURE §17), and a - standalone watch app with its own timers and alarms doesn't touch the phone, - though it has no F-Droid route onto a watch. + service" that `docs/PRIVACY.md` §2 rules out, and with no product flavours it + would also be a non-free dependency in the build F-Droid makes. A channel of + our own (Bluetooth, since there is no INTERNET permission) avoids the + dependency but needs Bluetooth permissions and is a new way for data to leave + the phone, beside Auto Backup and crash reports (`PRIVACY.md` §4 and §5). A + standalone watch app with its own timers and alarms avoids all of this but + doesn't control the phone. From b8968f5e19e13632a49793f8630865ba24fcd4b3 Mon Sep 17 00:00:00 2001 From: Jean-Luc Makiola Date: Thu, 22 Oct 2026 11:12:18 +0200 Subject: [PATCH 08/10] docs(roadmap): settle the Wear OS note on what the docs say MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Keep §5's own claim that only crash reports leave the phone, say the dependency would ship in every channel, and keep the standalone app's distribution caveat. Refs #27 --- docs/ROADMAP.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index 51b0f26..865acbc 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -621,10 +621,9 @@ Deferred deliberately, in rough priority order: blocked on a privacy and distribution decision. A watch that shows and controls the phone's timers and next alarm needs a phone-to-watch channel. The usual one, Google Play Services' Wearable Data Layer, is a "third-party - service" that `docs/PRIVACY.md` §2 rules out, and with no product flavours it - would also be a non-free dependency in the build F-Droid makes. A channel of - our own (Bluetooth, since there is no INTERNET permission) avoids the - dependency but needs Bluetooth permissions and is a new way for data to leave - the phone, beside Auto Backup and crash reports (`PRIVACY.md` §4 and §5). A - standalone watch app with its own timers and alarms avoids all of this but - doesn't control the phone. + service" that `PRIVACY.md` §2 rules out, and with no product flavours it + would ship in every channel, F-Droid included. Any channel of our own would + need new permissions (`PRIVACY.md` §7) and would be a way for data to leave + the phone, which §5 says only crash reports are today. A standalone watch app + with its own timers and alarms needs neither, but doesn't control the phone + and has no F-Droid route onto a watch. From 292758560827b182cf119df778f66e9ec5dc6b04 Mon Sep 17 00:00:00 2001 From: Jean-Luc Makiola Date: Thu, 22 Oct 2026 11:13:55 +0200 Subject: [PATCH 09/10] docs(roadmap): name both data paths and F-Droid's real response Refs #27 --- docs/ROADMAP.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index 865acbc..4ce1f5e 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -622,8 +622,8 @@ Deferred deliberately, in rough priority order: controls the phone's timers and next alarm needs a phone-to-watch channel. The usual one, Google Play Services' Wearable Data Layer, is a "third-party service" that `PRIVACY.md` §2 rules out, and with no product flavours it - would ship in every channel, F-Droid included. Any channel of our own would - need new permissions (`PRIVACY.md` §7) and would be a way for data to leave - the phone, which §5 says only crash reports are today. A standalone watch app + would be in every APK, so F-Droid would refuse or flag the app. Any channel + of our own would need new permissions (`PRIVACY.md` §7) and would be a new + data path: §5 calls crash reports the only one, and §4 covers Auto Backup. A standalone watch app with its own timers and alarms needs neither, but doesn't control the phone and has no F-Droid route onto a watch. From bdcf78002858f559c70ef353ae149dbb232c9b63 Mon Sep 17 00:00:00 2001 From: Jean-Luc Makiola Date: Thu, 22 Oct 2026 11:15:52 +0200 Subject: [PATCH 10/10] docs(roadmap): rewrap the Wear OS note Refs #27 --- docs/ROADMAP.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index 4ce1f5e..1c4926a 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -617,13 +617,14 @@ Deferred deliberately, in rough priority order: notification surface is known (`PLAN.md` §3). - **Migrate Calendula and Agendula onto `core-prefs` + `core-di`**: tracked in the kit's roadmap, not here. -- **Wear OS companion** ([#27](https://codeberg.org/jlmakiola/clockula/issues/27)): - blocked on a privacy and distribution decision. A watch that shows and - controls the phone's timers and next alarm needs a phone-to-watch channel. - The usual one, Google Play Services' Wearable Data Layer, is a "third-party - service" that `PRIVACY.md` §2 rules out, and with no product flavours it - would be in every APK, so F-Droid would refuse or flag the app. Any channel - of our own would need new permissions (`PRIVACY.md` §7) and would be a new - data path: §5 calls crash reports the only one, and §4 covers Auto Backup. A standalone watch app - with its own timers and alarms needs neither, but doesn't control the phone - and has no F-Droid route onto a watch. +- **Wear OS companion** + ([#27](https://codeberg.org/jlmakiola/clockula/issues/27)): blocked on a + privacy and distribution decision. A watch that shows and controls the phone's + timers and next alarm needs a phone-to-watch channel. The usual one, Google + Play Services' Wearable Data Layer, is a "third-party service" that + `PRIVACY.md` §2 rules out, and with no product flavours it would be in every + APK, so official F-Droid would refuse to build it. Any channel of our own + would need new permissions (`PRIVACY.md` §7) and would be a new data path: §5 + calls crash reports the only one, and §4 covers Auto Backup. A standalone + watch app with its own timers and alarms needs neither, but doesn't control + the phone and has no F-Droid route onto a watch.