diff options
Diffstat (limited to 'docs/MESHBAY_DESIGN.md')
| -rw-r--r-- | docs/MESHBAY_DESIGN.md | 40 |
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 |