feat(intents): open .ics/.vcs handed over as application/octet-stream (#74)

Mail clients, browsers and file managers frequently label a calendar
attachment as a generic download (application/octet-stream) rather than
text/calendar, so the MIME-typed VIEW filter missed them. Add a dedicated
filter that matches those by .ics/.vcs extension via pathPattern — kept
separate so the path constraint can't narrow the reliable MIME-typed filter.
The import handler already ignores the declared MIME, so a let-through file
imports normally. Best-effort: reliable for file:// and content:// whose path
carries the name; nameless content:// URIs still fall back to the MIME filter.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -38,6 +38,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   didn't advertise — so it was left out of the chooser, and if it was your only
   calendar app the save silently did nothing. It now accepts that form, plus the
   `INSERT_OR_EDIT` action, and opens the new event prefilled for review ([#74]).
+- Opening a `.ics`/`.vcs` file now works even when another app hands it over
+  mislabelled as a generic download (`application/octet-stream`), as some mail
+  clients, browsers and file managers do — Calendula recognises it by its file
+  extension instead of relying on the declared type ([#74]).
 
 ## [2.16.0] — 2026-07-17
 

app/src/main/AndroidManifest.xml

@@ -112,6 +112,28 @@
                 <data android:mimeType="text/x-vcalendar" />
                 <data android:mimeType="application/ics" />
             </intent-filter>
+            <!-- Same .ics/.vcs data arriving mislabelled as a generic download —
+                 application/octet-stream — the way many mail clients, browsers and
+                 file managers hand off attachments. Matched by file extension, so
+                 this stays a separate filter: a pathPattern here must not narrow
+                 the MIME-typed VIEW filter above (that one has no path and must
+                 keep matching regardless of name). The import handler ignores the
+                 MIME type, so a let-through octet-stream .ics imports normally.
+                 Best-effort: pathPattern is reliable for file:// (and content://
+                 whose path carries the filename); content:// URIs that expose no
+                 name still fall back to the MIME-typed filter above. -->
+            <intent-filter>
+                <action android:name="android.intent.action.VIEW" />
+                <category android:name="android.intent.category.DEFAULT" />
+                <category android:name="android.intent.category.BROWSABLE" />
+                <data android:scheme="content" />
+                <data android:scheme="file" />
+                <data android:host="*" />
+                <data android:mimeType="application/octet-stream" />
+                <data android:pathPattern=".*\\.ics" />
+                <data android:pathPattern=".*\\.vcs" />
+            </intent-filter>
+
             <!-- Receive a .ics/.vcs shared from another app (same MIME set). -->
             <intent-filter>
                 <action android:name="android.intent.action.SEND" />