dtourolle/DarkRoom
1
0
Fork 0
Code Issues 39 Pull Requests Actions Packages Projects Releases 20 Wiki Activity

Take the photograph another app hands over, and hand an export back

Browse Source 
FR-PLAT-AND-6 asks for two things this app did neither of: be a receiver for
image view and share intents, and share exported results out through a
FileProvider. The manifest declared one activity with one MAIN/LAUNCHER filter,
so nothing on the device ever offered DarkRoom for a photograph, and there was
no route out at all — Android has refused file:// URIs between apps since API
24, and a content:// URI needs a provider to be behind it.

Inbound. Three filters now: VIEW for a gallery or a file manager, SEND and
SEND_MULTIPLE for the share sheet, all on image/*. `android_main` reads the
launch Intent before it gives `app` away to Slint, and what comes back is
passed to `dr_ui::run` exactly as argv is on the desktop — `startup_action`
already treats a non-empty list as "the user asked for these specifically",
which is what a share is.

The URIs are copied into the cache before the viewer opens, and that cost is
real: a shared raw file is written once, in full, on the startup path. A
content:// URI is a handle into another app's provider, not a path, and the
decoders take paths; the alternative is teaching the whole read path about
URIs, which is FR-PLAT-AND-1's SAF connector and is not built.

Outbound. ExportProvider serves one directory — getFilesDir(), which is the
same path `internal_data_path` gives the Rust side — and refuses everything
else by canonicalising the request and checking it is inside that root, so
`../` and a planted symlink fail the same test. Not AndroidX's FileProvider,
because AndroidX is a Maven artefact and this build has no resolver; what it
does is a hundred lines and they are here.

The share half has no caller. The provider, the URI grant and the chooser are
all in place, but the control that would invoke them belongs in `ui/dr-ui`, and
wiring it needs an `AndroidApp` the interface can reach. It is documented as
unwired and deliberately not tagged as covering the requirement.

`launchMode="singleTask"` comes with the filters and is not decoration: another
app can now launch this activity while it is running, and the default mode
answers that by creating a second NativeActivity in the same process — a second
android_main, a second Slint backend, a second wgpu device. The cost of the
fix is stated in the manifest: a share arriving while DarkRoom is already open
brings it forward without opening the image, because onNewIntent has no route
through android-activity's event stream.

The Java is Java because Android constructs it: a ContentProvider is
instantiated by the system from its manifest entry, and getIntent() exists only
on an activity object. Both directions live there rather than in JNI so that
what crosses the boundary is two method signatures instead of forty, each of
which is a string checked at run time and nowhere else.

What a test can hold: the declarations. Nothing about an Intent or a
ContentProvider is reachable from `cargo test`, but an intent filter that is
deleted takes the app out of every "open with" menu silently, and an authority
that stops matching its class raises a SecurityException inside somebody else's
app. The tests in lib.rs read the manifest and ExportProvider.java through
`include_str!` and hold both to that, on the host, which is the only place in
the workspace that looks at either file from Rust.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
dtourolle
2026-08-29 23:32:48 +02:00
co-authored by Claude Opus 5
parent 24bf5be574
commit 09dddde594
7 changed files with 1075 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
apps/darkroom-android/android/AndroidManifest.xml
+101 -1
View File
@@ -7,6 +7,12 @@
here is a distribution manifest yet. Only network access is declared: file
access needs no manifest permission because the library grid reads through
SAF, which grants per-tree at runtime (ARCH §6.9).
Minimal is not the same as empty, and the entries below that are not the
activity are the difference. A manifest is the only place a component can be
declared: an intent filter is how the system learns this app is worth
offering for a photograph, and a provider is how it learns the class exists
at all. Neither can be moved into code (FR-PLAT-AND-6).
-->
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="paris.tourolle.darkroom">
@@ -51,10 +57,30 @@
<!-- NativeActivity rather than a Kotlin Activity: android-activity's
glue loads libdarkroom.so and calls android_main. `android.app.lib_name`
is how it learns which library to load, and must match [lib].name. -->
is how it learns which library to load, and must match [lib].name.
`singleTask` because a second instance of this activity is not
survivable. The intent filters below mean another app can now
launch it while it is already running, and under the default
launch mode that starts a *second* NativeActivity — in the
caller's task, in this same process, calling android_main again.
Two Slint backends and two wgpu devices in one process is not a
degraded experience, it is a failed second launch on top of a
working first one.
What it costs, stated plainly: a share that arrives while DarkRoom
is already running brings it forward without opening the image.
The Intent goes to `onNewIntent`, and android-activity's event
stream has no variant for it (MainEvent in 0.6 stops at Destroy),
so nothing native ever sees it. Reading it would mean a Java
Activity subclass forwarding it across JNI — the same shape of
change FR-PLAT-AND-5 declined for onTrimMemory, and for the same
reason. Launched from cold, which is the ordinary case for "open
this photograph", the Intent is on getIntent() and is read. -->
<activity
android:name="android.app.NativeActivity"
android:exported="true"
android:launchMode="singleTask"
android:configChanges="orientation|keyboardHidden|screenSize|screenLayout|density|uiMode"
android:windowSoftInputMode="adjustResize">
@@ -66,6 +92,80 @@
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
<!-- FR-PLAT-AND-6, inbound. The traceability tool reads .rs,
.slint, .wgsl and .yaml, so this is a reference and not a
tag; the tag that counts is on the test in lib.rs that
asserts these declarations are still here.
Opening a photograph from a gallery, a file manager or a
download. `android_main` reads the launch Intent through
`Intents.receive` and the named images become the browsing
list, exactly as paths on the desktop command line do.
`image/*` and not a wider match, even though it misses raws:
a provider that does not recognise `.CR3` reports it as
`application/octet-stream`, and claiming that type would put
DarkRoom in the chooser for every unidentified binary on the
device — an APK, a database, a partial download. Being absent
from one gallery's menu is a smaller failure than being
present in all of them. DNG, which providers do know as
`image/x-adobe-dng`, matches here already.
BROWSABLE is what lets a browser's finished download and a
link hand the file over; without it those routes silently do
not list the app. -->
<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:mimeType="image/*" />
</intent-filter>
<!-- The share sheet, one photograph or a selection of them.
SEND_MULTIPLE is declared because the sheet offers this app
for a multi-selection only if it says it accepts one, and a
culling tool that can be sent a single frame and not a burst
is the wrong way round.
ACTION_EDIT is deliberately not here. It is a promise to write
the result back to the URI it was handed, and nothing in this
app does: an edit lands in a sidecar beside the original
(FR-CAT-8). Registering for it would put DarkRoom in the "edit
with" menu and lose the user's work every time. -->
<intent-filter>
<action android:name="android.intent.action.SEND" />
<action android:name="android.intent.action.SEND_MULTIPLE" />
<category android:name="android.intent.category.DEFAULT" />
<data android:mimeType="image/*" />
</intent-filter>
</activity>
<!-- FR-PLAT-AND-6, outbound. Android has refused file:// URIs
between apps since API 24 — handing one out raises
FileUriExposedException in *this* process — so an exported JPEG
reaches the share sheet as a content:// URI or not at all.
Not AndroidX's FileProvider: that is a Maven artefact, and this
build has no Gradle and no dependency resolver (docker/android/
README.md). ExportProvider does the same hundred lines against one
fixed root.
`exported="false"` with `grantUriPermissions="true"` is the whole
security model, and the two halves are not redundant. Exported
false means no app may address the provider on its own account;
the grant flag means a URI this app puts in an Intent carries a
read permission for that one file, for the lifetime of the
receiving task. Without the grant flag the share sheet opens and
every target fails with SecurityException; with `exported="true"`
instead, every app on the device could read the app's private
directory. The authority must equal ExportProvider.AUTHORITY — a
mismatch is a SecurityException in somebody else's app, so a test
in lib.rs compares the two strings. -->
<provider
android:name="paris.tourolle.darkroom.ExportProvider"
android:authorities="paris.tourolle.darkroom.exports"
android:exported="false"
android:grantUriPermissions="true" />
</application>
</manifest>