feat(android): no text messages backup, and one build again

READ_SMS sits behind restricted settings outside a store and Play
keeps it for the default SMS application: not worth a second build.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 14 insertions, 26 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index ae7f8fc..d6240c7 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -3743,13 +3743,13 @@ object — absent, not refusing (§11.3).
 under a **Phone** heading of the side menu (`android-sync-page.js`), shown only
 where `platform.phoneSync` exists. Settings holds what the account prefers on
 every client; this page holds what one phone sends: photos, contacts (§9.13),
-and the kinds to come (messages, calendar, files).
+the calendar, chosen folders and WhatsApp's.
 
 **The personal profile only.** Every backup is of the phone's personal
 profile, never of a work profile: a copy of the application installed inside
 a work profile is offered none of them (`Profiles.kt`; the bridge objects are
 absent, so the page shows no Android Sync). In the personal profile each
-source reads that profile alone, since MediaStore and the contacts, SMS and
+source reads that profile alone, since MediaStore and the contacts and
 calendar providers answer for the profile they are asked from; none of the
 cross-profile `ENTERPRISE_*` URIs is used. An account added to the personal
 profile is part of it, whatever its use.
@@ -3833,7 +3833,7 @@ only once the node has that file, so a run cut short sends them with the next
 one. Restoring puts each photo back into its album and each file back under
 its own name and date; merging onto a phone that already has some of them
 compares hashes without downloading anything. Photos, videos and files have
-one; contacts, calendars and messages are each one file that describes
+one; contacts and calendars are each one file that describes
 itself. What the manifest cannot bring back is a photo's location, removed
 before it left the phone.
 
@@ -3856,10 +3856,10 @@ foreground service (`BackupService`) and the WebView reported visible, like a
 cast (§11.3). Android 15 limits that type to six hours a day; the service stops
 when told and the run carries on at the next opening.
 
-### 9.13 Contacts, calendar, messages, files and WhatsApp backup (Android)
+### 9.13 Contacts, calendar, files and WhatsApp backup (Android)
 
-The Android application sends a copy of the phone's **contacts**, its
-**calendars** and its **text messages** to a folder of a group, on the photo backup's terms (§9.12): a client
+The Android application sends a copy of the phone's **contacts** and its
+**calendars** to a folder of a group, on the photo backup's terms (§9.12): a client
 feature over the upload path, additive, once a day, the page doing the sending
 and the phone handing one file over by token (`/phonesync/<token>`,
 `phonesync/` in the Android package, `phone-sync.js` on the page). Each kind is
@@ -3889,16 +3889,6 @@ organizer and attendees come along; each event names its calendar in
 `X-MESHBAY-CALENDAR`, which importers ignore. Like contacts it is sent when
 its SHA-256, taken without the DTSTAMP lines, differs from the last copy.
 
-**Messages.** `<folder>/<account>-messages/YYYY/sms-2026-10-10-0900.xml`: the
-SMS added since the last file the node took (the marker is the highest
-provider `_id` sent; ids only grow, so a message restored onto the phone later
-is sent too), the first file holding the whole history. The format is the
-`<smses>` XML that SMS backup applications restore, so a copy goes back onto a
-phone with tools that exist; `SmsXml.kt` writes it, keeping line breaks as
-character references and leaving out the characters XML 1.0 cannot carry.
-A contact name is filled in only when the person also allowed contacts. MMS
-are not included.
-
 **Files.** `<folder>/<account>-drive/<chosen folder>/…`: the files of the
 folders the person chose through the system's picker
 (`ACTION_OPEN_DOCUMENT_TREE`, a persisted read grant per folder, no storage
@@ -3934,17 +3924,15 @@ increments: once anything in that set was sent, the manifest gets a
 `restore-set` line naming, for each file of the set as it is now, the copy
 on the node that goes with it.
 
-**Two builds.** Play's policy gives `READ_SMS` to the default SMS application
-only, so the APK has a `store` dimension: `full`, distributed directly, and
-`play`, which has neither the permission (`src/full/AndroidManifest.xml`) nor
-the code that reads messages (`SmsSource.kt` is in `src/full`; `Flavor.kt`
-answers null in `src/play`). The bridge offers `messageSync` only where the
-shell has a message source (`MESSAGES` in its prelude), so the Play build shows
-no Messages section rather than one that refuses.
+**No text messages.** They are not backed up. Play gives `READ_SMS` to the
+default SMS application only, and Android keeps it behind "restricted
+settings" for an application installed outside a store, which the person must
+lift by hand in the system's settings; for an occasional restore that was not
+worth a second build of the application.
 
-**Unlike photos**, these run on any network: a contacts or calendar file is small, and a
-history of text messages is megabytes, not the gigabytes of a camera roll.
-`READ_CONTACTS`, `READ_CALENDAR` and `READ_SMS` are asked for when the person
+**Unlike photos**, contacts and calendar run on any network: their files are
+small, not the gigabytes of a camera roll. `READ_CONTACTS` and
+`READ_CALENDAR` are asked for when the person
 turns each on, never at start.
 
 ## 10. Filesystem portability